The reason for this is the following: Whenever XFolder starts a program object in the configuration folders (that is, when you select the respective menu item in a context menu), it can perform a few tricks on them.
The tricks are the following:
Take the default configuration again: the four command line objects have empty startup directories. This is why you can start command lines "in" the folder whose context menu was used.
If you wish to disable this behaviour, simply specify a startup directory in a program object
(e.g. "C:\"), and XFolder will leave it alone.
Instead, it will always use the startup directory which you have
specified.
This is used by the "Netscape" menu entry of the default configuration: this way, Netscape will display the contents of the folder which it was called from.
You can disable this feature completely in the &xwp; Global Settings.
If you wish to disable this behaviour for one menu item only (not all programs can handle directories as parameters), add a "%" sign to the "Parameters" list of the respective program object. XFolder will omit passing the additional parameter. This is the case, for example, with the four command line objects of the default configuration.
Examples: Putting only "%" in the parameters list will not pass any parameters at all; putting "text.txt %" in the parameters list will always pass "text.txt" without the folder name as a parameter.
I know this way of configuring XFolder's behaviour is not very intuitive, but I implemented
it for compatibility with the WPS's behaviour when calling context menu items that were added
with the "Menu" page in the settings notebook. I then found out that it works with Netscape as well,
so even better.
Example: Path and filename = "e.exe"; parameters = "%**C" will start the system editor, interpreting the contents of the clipboard as a file name.
Note that the contents of the clipboard will be truncated so that the maximum length of
the parameter list will not be exceeded. With &os2;, the maximum path length is 260 characters.
This limitation
avoids passing 64 K to the program, in the worst case.
Hint: If you are using the (outstanding) WPTOOLS by Henk Kelder, you should enter a valid program executable even with these separator program objects, or otherwise CHECKINI will keep complaining that the object is not valid. Even though an executable exists, XFolder will then only insert a menu separator.
Please note that XFolder only performs these described actions on "real" program objects in the configuration folders, not on shadows pointing to other program objects. I am not planning to implement this behaviour on shadows too, because I do not intend to modify objects which are situated elsewhere in your desktop hierarchy, ouside the configuration folders.
As a consequence, you ought to put copies of your program objects into the configuration folders, instead of creating shadows for them. Again: shadows of program objects are opened too, but without changing any settings.
Please consult the "Frequently Asked Questions" section
for a few more hints on creating program objects.