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:

1. If the startup directory of the program object is empty, XFolder will temporarily insert the directory of the folder whose context menu was used therein. This means that you can start the same program from all folders' context menus, but with a variable startup directory, being the directory of the folder whose context menu was used.

   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.
   

2. If the parameter list of the program object does not contain a trailing "%" sign, the directory of the folder you used will be passed as a parameter to the program.

   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.
   

3. You can append the contents of the clipboard to the parameter list of the clipboard by putting a "%**C" symbol into the parameter list. This can appear at any position of the parameters. This is case-sensitive; "%**c" (in lower case) will NOT work.

   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.
   

4. If the program title contains a "~" character (which you have probably inserted to add a keyboard shortcut, as described on the previous page), XFolder will remove it when starting the program. You can also switch off this behavior in the &xwp; Global Settings, where you will find additional help on this.
   
5. You can now (V0.51) insert a separator into a menu by specifying "---" (exactly, three dashes) in a program object's title. (A separator is a horizontal line to optically separate groups of menu items.) In this case, XFolder will ignore the program object's settings (such as the executable, parameters etc.) and simply insert a separator into the menu. This works for the main context menu as well as submenus.

   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.