Weird,
I just downloaded 006 for XCode (I’m running XCode 3.0) and I can’t run any OF examples that have a data directory…the app doesn’t find the files. I drilled down and it seems to be creating the data path normally (…/…/…/data/) but still doesn’t work.
All non-data related apps work though. Any ideas? Should I update my version of XCode or something? Do I have some settings wrong?
curious – is this running the apps from within xcode or outside of xcode. debug and release?
one thing that happens sometimes with IDEs is that they change the default executing directory. I know this is a problem on VS, where we have to force it to run debug from within the bin directory (would normally not run it in the same place as release).
can you let us know about above qs ?
take care,
zach
I’m looking at the moviePlayerExample right now…
It seems to do it with both (running inside and out of xcode). At least, running the standalone app just crashes it, which I assume is due to the missing asset.
I get this error message in the debug pane:
OF_ERROR: FSPathMakeRef failed -43
OF_ERROR: Error loading movie
GDB then proceeds to run, also printing this:
Attaching to program: `/Users/grimus/dev/openFrameworks_v0.06/apps/examples/moviePlayerExample/bin/openFrameworks.app/Contents/MacOS/openFrameworks
which indicates the path of the binary it’s trying to run in any case
The “data” dir is now in the “bin” directory, right?
It used to be at the app root level I think. Anyway, I copied the data folder to the root level as well but it made no difference.
Oh and the problem occurs in both Debug and Release…
Ok I got the apps running by opening up a console and running the app from within the app package. Double clicking the app from within Finder didn’t work. This is def. a working directory problem.
Using “get info” on the exectutable, I can see that the working directory is set to “Build Products directory”…is this ok?
I upgraded to the latest XCode (3.1.3) and re-extracted the of_“preRelease_v0.06_xcode_FAT.zip” package…and I’m still getting this…very frustrating.
Has this data dir stuff been modified recently?
I downloaded the zip from: http://www.openframeworks.cc/download
Ok so if I place the data dir three levels above the Build Products directory (which in my case is /Users/grimus/dev/of_preRelease_v0.06_xcode_FAT/apps/examples/moviePlayerExample/bin)
This is of course due to the OSX data dir calculation which is …/…/…/data/
So basically running from within XCode works if I put all data in the OF apps directory. Weird…
but I still can’t run the app from Finder (well something like the polygonExample works because it has no data).
I must have a cursed set of XCode preferences 
After some investigation…when I double click the app from Finder, it sets the working directory to be “/”, i.e. the unix style root directory. Very strange.
sorry for all the noise, but I’m trying to get to the bottom of this…
I found a couple of articles that explained some stuff to me:
http://stackoverflow.com/questions/5162-…-in-xcode-c
http://forum.soft32.com/mac/XCode-curre-…-47167.html
however, I’m still puzzled that, if XCode sets the current working directory to be the build directory, how is the “…/…/…/data” path setup working for anyone? If I set it to just “data”, I can run apps from within XCode.
By the way everything used to work for me a while back (I was using 0.03)…so some update on my system must have changed things…
Hey Pierre,
That is strange - I think I have seen this issue before though.
Can you try the attached zip file? It has the movie player example and should play the movie when you double click it.
If the movie plays then you have a build/xcode problem.
If it doesn’t than it might be a permissions/finder problem.
theo
Hey Theo,
thanks, I ran the app, and just like in all my tests it crashed.
This is no doubt due to the fact that it’s not finding the data path, and in the moveplayer example the app will carry on and try to iterate through pixels even though the pointer is NULL.
This is sort of a bug in the example I guess, there should be a check for a NULL pointer.
In my tests, the working directory is set to “/”, just like in one of the articles I posted above. I did this check by calling getCwd() early in ofToDataPath() and passing the string back to the main app to display it in the window (is there a way to run app packages in the Finder in a terminal window?).
I’m happy to try other things, but for the moment I’m stumped…and I have no solution really, because although I can get apps running in XCode by changing the data path, I still can’t run them from the Finder.
I’m running a Mac Mini core 2 duo with OSX 10.5.7 btw…
You can run an OF app from the terminal.
cd myFolder/openFrameworksDebug.app/Contents/MacOS/
./openFrameworksDebug
You can also running the gcc debugger from terminal
gdb myFolder/openFrameworksDebug.app/Contents/MacOS/openFrameworksDebug
then type: run
I am going to upgrade to 10.5.7 and 3.1.3 I am currently on 10.5.6 and 3.1.2
It could be that you have a strange disk permissions problem - try opening Disk Utility ( Applications/Utilities ) and checking the disk permissions of your OS volume.
Theo
ps a worst case scenario - you can always add the files to your xcode project (drag the movie files into xcode sidebar). This copies them to the openFrameworks.app/Contents/Resources folder which is seen by the app to exist at the same level of the internal executable.
Then in testApp::setup you can do:
ofSetDataPathRoot(""); or ofSetDataPathRoot("./");
That might work??
Theo
I’ve just tried the latest OS and latest xcode without problem loading data files.
but I did notice that on the preferences of each app you can say wether or not you want them to “use curent working directory” and maybe that’s selected (on my mac no apps have this selected, and if you do, you won’t load properly via ofToDataPath).
here’s screenshot of that preferences window:
hope that helps —
zach
Brilliiant! That’s it!
Yes that makes sense now, the working directory as different depending on the context.
I’d never actually seen those preferences before…it that the only way to access them (i.e. run a glut application)?
yes – I’m not sure how to access them myself from xcode or c++ code (but it might be possible).
I did have this exact same problem when I brought over an application from an older xcode into a newer one, ie, I had a project on mac 10.5.4 (xcode 3.1.2) and brought it over to the latest osx / xcode (will edit the post with the latest numbers on my imac later today).
these are very useful if you need to fix horizontal span issues or other things about the app. but, your app has to run and for some that load media (like mine) and I wound up having to throw a “return;” at the top of update and draw not to crash, so the app could run, and I could set it back to non use current working directory 
Once set, recompiling etc is fine and it preserves those settings.
I did not however have this problem when I unzipped a new OF version – ie, virgin xcode project.
what about you? I’ll experiment a bit more today.
take care,
zach
Honestly I don’t know how that box got to be ticked if in general it isn’t. I had successfully used 0.03, then did not develop on Xcode until I installed 0.06 recently, but have updated software on the mac over that time. Anyway at least the problem is solved, I was worried I was going to have to reinstall or something.
the preference checkbox didn’t fix it for me.
putting this code into the main function before the app starts running did what i wanted (set the current working directory to be the one the main app bundle is in) taken from http://stackoverflow.com/questions/516200/relative-paths-not-working-in-xcode-c/520951#520951
#ifdef TARGET_OSX
CFBundleRef mainBundle = CFBundleGetMainBundle();
CFURLRef bundleURL = CFBundleCopyBundleURL(mainBundle);
CFURLRef containingDir = CFURLCreateCopyDeletingLastPathComponent(NULL,bundleURL);
char path[1024];
if (!CFURLGetFileSystemRepresentation(containingDir, TRUE, (UInt8 *)path, 1024))
{
cout << "error" << endl;
// error!
}
CFRelease(bundleURL);
CFRelease(containingDir);
chdir(path);
#endif
this seems a little kinky to me. is there a better way for this?
i’m not sure if i have grasped the problem of all of this correctly.
but since i started developing on mac i always have built just executables,
no app bundles (so i don’t know too much about them, except that they hide all the needed files inside in predefined directory structure).
then on a project using Ogre3D i found this valuable snippet:
#ifdef __APPLE_CC__
#include <cassert>
#include <string>
#include <CoreFoundation/CoreFoundation.h>
// This function will locate the path to our application on OS X,
// unlike windows you can not rely on the curent working directory
// for locating your configuration files and resources.
//
// NOTE: use getcwd() or get the environment variable PWD with getenv()?
static std::string macBundlePath()
{
char path[1024];
CFBundleRef mainBundle = CFBundleGetMainBundle();
assert(mainBundle);
CFURLRef mainBundleURL = CFBundleCopyBundleURL(mainBundle);
assert(mainBundleURL);
CFStringRef cfStringRef = CFURLCopyFileSystemPath( mainBundleURL, kCFURLPOSIXPathStyle);
assert(cfStringRef);
CFStringGetCString(cfStringRef, path, 1024, kCFStringEncodingASCII);
CFRelease(mainBundleURL);
CFRelease(cfStringRef);
return std::string(path);
}
#endif
i used it in combination with preprocessor definitions
std::string fileName("data/blah.dios");
std::string filePath;
#ifdef __APPLE_CC__
filePath = macBundlePath() + "/" + fileName;
#else
filePath = fileName;
#endif
it might not be the most elegant solution, but it always works.
hope this helps,
didi
Hello
I am new to Mac OsX and to Xcode
I compiled my project in debug mode and worked ok
However as I try to compile for the release version “10.4 | Realease| i386” , it crashes trying to open files in the data folder…
the debug version works without any problems…
any parameters that i have to change for the release version?
thanks
For the release version
I changed the filename to
“…/…/…/data/”+filename
and it works!! 