Hi all,
if you want to be able to move around your executable and be able to prees buttons etc. you should add that post-build step in one line for all your targets :
/Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -o $(<target>_OUTPUT_FILE) Carbon.r
Where <target> is DEBUG or RELEASE. Like this :
/Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -o $(DEBUG_OUTPUT_FILE) Carbon.r
or
/Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -o $(RELEASE_OUTPUT_FILE) Carbon.r
regards,
The wxWidgets team recommends using application bundles instead of resource forks, but you are right that either bundles or resforks are required for any wxWidgets application to start receiving events. Unfortunately.
This is now Bug #10747:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=10747&group_id=5358
Quote from: afb on March 28, 2007, 11:27:43 AM
This is now Bug #10747:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=10747&group_id=5358
In my own build, i did not need to do any of the two yet it works...
it might be worth checking if my system is just weird or if wxWidgets 2.8 fixed this
This is so that you can run /usr/local/bin/codeblocks from the command line, or use the "Run" command in CB after building the newly generated wxWidgets wizard project.
For real applications, it is recommended that you build an .app bundle with the proper structure and an Info.plist. But unless you do either, the application doesn't work.
Quote from: afb on March 28, 2007, 02:44:25 PM
This is so that you can run /usr/local/bin/codeblocks from the command line,
Yes that's what i'm doing... open a terminal, type 'codeblocks', it opens, it does receive events - and i didn't do any app nor resource fork.
Though for distribution a .app is needed, of course.
Hmm, maybe it really did change in wxWidgets 2.8 then ? Probably no harm in adding it anyway, since we seem to be stuck with wxWidgets 2.6 for some time.