I'm not sure what the other platforms are like, but I know that the function windows uses for this (ShellExecute) has the ability to specify the working directory to be used in 'running' the file.
I currently have an issue where I actually need to be able to do this, and was wondering if it would be possible to add an optional working directory parameter to this function. I'd rather not have to manually call ShellExecute myself if possible :) !
Haven't time to write it myself, but it's something I'd be happy to add if you want to hack together a working version!
I can only currently implement this for windows (it'll be a while before I get a chance to look into it at home for OSX, and I don't have any linux systems for that)...
...but for windows at least it is as simple as this...
bool JUCE_CALLTYPE Process::openDocument (const String& fileName, const String& parameters, const File& workingDirectory)
{
HINSTANCE hInstance = 0;
JUCE_TRY
{
hInstance = ShellExecute (0, 0, exe.getFullPathName().toWideCharPointer(),
parameters.toWideCharPointer(),
workingDirectory.getFullPathName().toWideCharPointer(), SW_SHOWDEFAULT);
}
JUCE_CATCH_ALL
return hInstance > (HINSTANCE) 32;
}
i.e. just providing the extra 'directory' parameter to the call (and taking it in as a File with a default File::nonexistent value).
For now, I'm just doing it in a local free function instead.
Incidentally, it would be really nice if there were any easy way to include 'juce_BasicNativeHeaders.h' for cases like this (when you need to do something using OS API calls, and want to ensure that system headers are included with the same defines as juce uses). It's easy enough to do using an absolute path, but with the modules setup (and if it is a module which needs to use such includes) that's not really an option. Manually duplicating the defs and includes etc always seems a bit fragile to me (and in violation of D.R.Y.!). I know that platform specific stuff isn't exposed by juce on principle, but since this is just opening up the same door juce uses, it doesn't seem to be quite such a violation :)
The only practical way I can think of doing it though would be if the juce_core module could expose a second header for this (e.g. juce_core_native.h), but the introjucer doesn't allow more than one header per module.
Sorry that's a bit off the focus of the topic, wasn't sure it warranted its own thread!
Re: the native headers, if you have the juce_core code in a known place relative to your project, you can just include juce_BasicNativeHeaders.h from your own source files - I think I do that in some of my projects where I need to use a few system functions.
That's what I've done in the past, but since moving some code into a module, I'm not sure that is an option (since all I can guarantee my code has access to is the headers exposed by the required modules).
