Hi Jules,
Command-line argument are supplied to the JUCEApplication instance with a single string containing the concatenated arguments, separated by a whitespace. The problem is that it does not handle arguments already containing a whitespace (for example a filename such as “foo bar.txt”): it would probably be more appropriate to use a StringArray ?
Well, that’s only true on unix - on windows, it gets the whole thing as a string. So the choice was to either concatenate the unix args, or to tokenise the windows args. I chose to concatenate because it seemed less likely to get things wrong than attempting to tokenise.
Surely you should be putting things like that in quotes, anyway? Or do you mean that the shell already stripped the quotes away?
Mmm true, I didn’t know windows was leaving the separation of arguments up to the application. However, they seem to also provide a function that does the tokenization: http://msdn.microsoft.com/en-us/library/bb776391(VS.85).aspx
On unix, this task is performed by the shell , calling:
./foo a b ‘c d’
will fill an argv with the strings {"./foo",“a”,“b”,“c d”} (quotes are removed by the shell)
In fact I don’t really need that feature, but for command line application that may have to deal with filenames containing whitespaces , using an array for arguments is really required.
Hmm. I didn’t realise that the shell was stripping the quotes.
A good compromise that won’t break anyone’s code would be to add a method to the application class that supplies it as an array.
[quote=“jules”]Hmm. I didn’t realise that the shell was stripping the quotes.
A good compromise that won’t break anyone’s code would be to add a method to the application class that supplies it as an array.[/quote]
Bumping this.
I need to be able to support multiple command line options, some of which may be quote enclosed.
On Windows this works great as I get the command string back as I’d expect. On Linux/OSX the quotes are lost when you reassemble the string. I.E.
someapp --option --option “a file path” “another file path”
produces a command line string of ‘–option --option a file path another file path’.
I can’t see any way around this without modifying JUCE.
Can you suggest a code change that’d do what you want? (I’m a bit too busy to give it much brain-power right now, but if you have a good suggestion, I’ll certainly add it…)
Why not storing the arguments in a StringArray member variable in JUCEApplication, and provide a getCommandLineArguments() member function that returns this array ? That way the current function prototypes would be unchanged.
This is what I’m doing in my local juce version.
To be honest I realized a few hours after posting that I’m stuck on 1.53 'cos I’m using a commercial license for this code, so JUCE source changes wouldn’t help me anyway. As such I just patched JUCE core to do what I need.
I agree with jpo though. It’s not ideal that the behavior of JUCE differs between Win and 'nix-alikes but since it’s been this way for years, not breaking existing code is more important than correctness.
So either a macro definition to switch behaviors, or more easily a string array of params. If you’re OK with a getCommandLineParametersAsStringArray() style addition to JUCEApplication() I’ll try to download JUCE 2 to my home system later and take a stab at a possible patch.
I’d like a “StringArray getCommandLineArguments ()”…I make use of command line args in my app to bring up a dialog box (by launching a second instance with the message box options as parameters)
Thanks chaps, this needed a bit of spring-cleaning, so I’ve refactored a bunch of stuff now, and added methods to JUCEApplication to get the strings as an array.
…not sure why having a commercial license would make a difference there, it won’t stop you moving up to 2.0… (?)
I don’t have the license agreement in front of me, but I could have sworn it said something about being valid until a major version increment. Which I have been meaning to ask about too.
Never mind, I was able to access the one at work, and the part about versions indicates the license is good thru version 2.x. 
[quote=“jules”]Thanks chaps, this needed a bit of spring-cleaning, so I’ve refactored a bunch of stuff now, and added methods to JUCEApplication to get the strings as an array.
…not sure why having a commercial license would make a difference there, it won’t stop you moving up to 2.0… (?)[/quote]
See cpr’s post below yours. I was under the same impression. I don’t have access to the actual licenses - they’re locked away with the people whose job it is to care about such things - but I vaguely recall the license being valid only for minor point upgrades. :?
Not being limited to 1.53 would be kind of nice since I’m finally moving back at least partially to C++ code.
You sillies! 
[quote=“haydxn”]You sillies!
[/quote]
Aye.
