CMD.exe can only work on drives with letters assigned, it woud fail on UNC
paths, like \\live.sysinternals.com\Tools\DbgView.exe
CMD.exe can not work with Unicode filenames. Say, on my Rus windows, it would
not open file with Greece, Chinese or Japanese name
At last, this flickering black windows is just aint cute-looking :-)
"show in explorer" and "open with default application" are both user-
configurable in global settings dialog. They both execute a commandline. The
only way I know to open associated applications via a commandline invocation
is by using "cmd.exe".
> but for win* versin Native API would be better here...
::ShellExecute() doesn't really fit for a command line, but needs it split
into "lpFile" and "lpParameters".
> btw, why not wxShell then, if you anyway run via command line ?
wxExecute is slighly better than wxShell since it doesn't show the black
console dialog.
>::ShellExecute() doesn't really fit for a command line
Solved this problem by doing some cautious commandline parsing. v3.17 will be
using ShellExecute(), didn't find any problems in my tests so far.
"open with default application" is not to expect lpParameters, if to read by
title
if user to override default action - he may also override default title and
construct both parts of commandline by his choice.
wxExecute also shows 'black console dialog'. It closes it second later, but
still.
And since u use commandline shell, which might give any errors itself, showing
user those errors make no less sence, than deleting them with the dialog.
CMD.exe is prone to errors, how can user then understand what happened ?
>"open with default application" is not to expect lpParameters, if to read by
title
Both lpParameters and lpFileBy are required 'cause the input, as defined in
FFS->global settings is just a single command line. "open with default
application" is user-configurable, therefore I have no idea what's it doing
within FFS.
>wxExecute also shows 'black console dialog'.
wxExecute doesn't show a console dialog, but "cmd.exe" that is defined in the
command line does.
> CMD.exe is prone to errors, how can user then understand what happened ?
Again, except from shellExecute, using cmd.exe is the only way to open an
associated application as part of a user-defined command line.
