AEN007 wrote:Any helpful replies/insights appreciated.
Relevant Disclaimers: We'll file this post under "Curious Insights"... as to how helpful it is, I'll leave that to your own sense of posterity.
Not using "wavpack", I decided to do my own experiments using Gimp and PNG's... I don't think the difference in application is relevant, as I tried the experiments again using TXT files and an editor, and the results were the same.
First off, it should be pointed out that trying to do so-called wildcard *.* batch operations invoked via a context menu call without explicit pathnames is a bad idea. The wildcard isn't parsed under x2, it's passed to the application as a literal string - in other words, the text editor kept trying to open/create a files named "...\*.TXT" and Gimp "...\*.PNG" - obviously resulting in filename errors. Curiously the path (if unspecified) defaults (in a fresh x2 process) to whatever the last "successful" directory access was... sometimes this was the x2 home folder (C:Program Files\zabkat\), sometimes it was the test folder... no real rhyme or reason to it, so I gave up trying to identify the source; there was no consistency.
Windows explorer, incidentally, did parse these things out, but rather kept opening multiple processes of the application rather than one instance with multiple tabs. Again, this had consistency problems as well, dependant upon the application. Not reliable.
So I took another approach.
I created a script (VBS) for the following:
Code: Select all
Set filesys = CreateObject("Scripting.FileSystemObject")
path = filesys.GetParentFolderName(Wscript.Arguments(0))
command = chr(34) & "C:\Program Files (x86)\GIMP-2.0\bin\gimp-2.6.exe" & chr(34) & chr(32) & chr(34) & path & "\*.png" & chr(34)
set objShell = createobject("Wscript.Shell")
objShell.Run command, 1, 0
The contents of the "command" string become the application path in literal quotes (chr 34), with the parent-folder + wildcard also in literal quotes separated by a space (chr 32).
Basically, this derives the parent folder of any selected file and opens the application from within the script with the "*.png" explicitly called to that folder. In other words, instead of passing "*.PNG" as an "assumed" path, it forces the call as "{Parent Folder}\*.PNG" -
this resulted in the desired behaviour every time. This script is referred in the menu caption as "Batch png" via the context registry (
HKCR\...\shell\Batchpng\command) as its own entry being:
Code: Select all
"C:\Windows\System32\wscript.exe" "C:\png_batch.vbs" "%1"
The %1 in this regard is only used to derive the parent folder and path, the literal selected item itself is disregarded.
So, what did I learn?
- A) This is stupid.
B) It's much easier to use x2 Professional with User Commands and a toolbar button.
- See '> "wavpack.exe $P\*.wav"'
C) Cigarettes don't help mitigate the fact that this is really really stupid.
D) See A and C again, and contemplate B. 
If you insist upon trying this in x2 without User Commands (as I suppose the Lite-version forces you to do), you can modify the above script for your own purposes and see what happens. I don't know how you reference your context menu batch commands in the registry - whether they're tied to just .WAV files, or whether you linked them to the context menus for folders as well (which would make sense, given what you're trying to achieve). If the latter, then you'll need to modify the script to derive the path from both selected files and/or folders, to get a seamless result. (I only set it up for files as differentiating filesystem objects in VBS per type gave me a headache.
And keep in mind that the script makes no checks or assurances that a file is actually selected, which is required to glean the parentfolder.)
I did say at the beginning that how "helpful" this might be is up to yourself to determine, but those are my "insights".
Now, there's Snooker on the telly, and I officially eschew messing around with context menus for the rest of the evening.
