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;
hInstance = ShellExecute (0, 0, exe.getFullPathName().toWideCharPointer(),
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!