Fix a launcher menu that opens the program with no apps

Why does DSLaunch open with no applications when the command line matches?

The command line is only half of what a shortcut does: Windows also hands the program a working directory from the Start in field, DSLaunch fills its application list from the folder it starts in, and your Run menu entry never supplied that folder.

A desktop shortcut is a container for two settings, and a command line is only one of them. The Target value selects the program. The Start in value selects the folder the program runs from. A desktop icon carries both, so the icon loads the full application list every time. A Run menu entry that was filled in from the icon's command line carries only the path to DSLaunch.exe, so the same executable starts and comes up with nothing in the list. Supply the folder and the two launch methods behave the same.

What do Target and Start in do on the shortcut?

The Target field names the executable Windows starts, "C:\DirectSOFT5\Bin\DSLaunch.exe" in this case, and the Start in field names the folder the program runs from; a command line copied from the shortcut carries the first value and drops the second.

Both values sit on the Shortcut tab of the icon's Properties, Target on one line and Start in on the line below. Two settings, one dialog, and a launch behaves like the icon only when both travel together. The folder value appears nowhere in the command line, so the shortcut's properties are the only place the folder is printed in full.

Which symptom points to the working directory and which to the path?

An empty application list with the launcher window open points at the working directory, a launcher that fails to open at all points at the Target path, and the two checks separate them in under a minute.

Run down the list and stop at the line that matches your panel:

• DSLaunch opens, the application list is empty, the desktop icon loads everything. The Run menu entry is missing the working directory, and the fix in this article applies.
• DSLaunch fails to open, or Windows reports it cannot find DSLaunch.exe. The Target path is wrong: a typo, a lost quotation mark, or an installation that has moved. Correct the path before anything else.
• The Run menu launch works and the desktop icon is the empty one. Someone edited the shortcut's Start in folder. Copy the value from the Run menu entry back into the shortcut.
• Both methods show the list and an application itself fails later. The launcher has done its job; the fault has moved into the application, and these checks are finished.

How do you read the Start in folder from the working shortcut?

Open the desktop icon that launches DirectSOFT 5 correctly, right-click it, open Properties, and read both values from the Shortcut tab before you edit the Run menu entry.

1. Right-click the working desktop icon and choose Properties.
2. On the Shortcut tab, copy the Target value exactly as printed, quotation marks and arguments included. Here it reads "C:\DirectSOFT5\Bin\DSLaunch.exe".
3. On the same tab, copy the Start in folder exactly as printed, from the drive letter through the last folder. Here it reads C:\DirectSOFT5\Bin.
4. Paste both values into a .txt file so the comparison in the Run menu editor is character for character.

The folder is the value people skip, because the command line gives no sign of it. Reading it costs one Properties dialog and saves a round of guessing the Bin folder.

Where does the working directory go in the Run menu entry?

Keep the entry's command line exactly as it is and put the shortcut's Start in folder into the Run menu entry's working-directory setting, the field that does for the entry what Start in does for a shortcut.

1. Open the Run menu configuration in Lookout Direct and select the DirectSOFT entry.
2. Compare the entry's command field against the recorded Target. If the two match, leave the command field untouched.
3. Type the recorded Start in folder, C:\DirectSOFT5\Bin in this case, into the entry's working-directory field. Builds label this setting in their own way; it is the one asking for a folder beside the command.
4. If the editor offers no folder field, the equivalent is a preliminary change-directory command ahead of the executable, which puts the launcher in the recorded folder before it starts.
5. Save the entry, close any DSLaunch window that is already open, and launch DirectSOFT again from the Run menu.

Do not add a guessed command-line switch and do not move or copy installation files to make the empty list go away. Both edits create a second configuration to maintain while the mismatch stays put. Until the entry passes the checks below, the desktop icon stays the operators' route into DirectSOFT.

Example: what changes when the Start in folder is set?

On a shop PC running DirectSOFT 5.3, the working shortcut reads Target "C:\DirectSOFT5\Bin\DSLaunch.exe" with Start in C:\DirectSOFT5\Bin, the Run menu entry carries the same command with no working folder, and DSLaunch opens showing 0 applications.

The fix touches 1 setting. The entry's working directory becomes C:\DirectSOFT5\Bin, the folder the shortcut prints, while the 31-character Target path keeps every character it had. Two launches settle it. Launch 1 from the Run menu now lists the DirectSOFT 5 applications where it listed 0 before. Launch 2 from the desktop icon still lists them, which shows the edit changed one launch method and left the other alone. If launch 1 shows 0 applications again, compare the folder character for character, because C:\DirectSOFT5 against C:\DirectSOFT5\Bin is a one-folder difference that looks close and loads nothing. The Bin folder here is the example's value, and yours is whatever your own working shortcut prints; the arithmetic is the same either way: 1 field edited, 0 characters of the path changed, 2 launches checked.

How do you verify the fix, and what if the list is still empty?

Judge the fix by the application list: close any DSLaunch already open, launch fresh from the Run menu, and require the DirectSOFT 5 applications to appear before you call the entry fixed.

1. Close the DSLaunch window left over from the earlier attempt and start a fresh one from the Run menu. A window opened before the edit was launched under the old setting.
2. Launch once from the desktop icon and compare. Both methods should show the same list.
3. Still empty from the Run menu? Compare the folder value character for character, watching for a trailing space or a missing Bin folder.
4. Does the entry run as administrator? Test it without elevation. Windows has a documented case of an elevated command prompt shortcut ignoring its Start in folder, so elevation can defeat a value that is otherwise correct.
5. Start in matches exactly and the list stays empty? Stop editing files and switches. Take the shortcut's Target and Start in values, plus the Run menu entry's command and folder settings, to the software's own documentation or its support channel.

Recommendation: Keep the Target path exactly as the working shortcut prints it and set the Run menu entry's working directory to that shortcut's Start in folder. If the Run menu editor has no folder field, run a change-directory command ahead of the executable. Until the application list loads from the Run menu, let operators start DirectSOFT 5 from the desktop icon.

With the list loading again, the panel is back to ordinary programming work. The ladder-reuse practice in Reuse DirectSOFT ladder snippets without address conflicts starts from an open project, and the end-to-end walkthrough in How to program a Koyo SZ-4 PLC CPU with DirectSOFT picks up from there. When the fault turns out to be hardware, not software, Replace a failed PLC operator panel without a protocol mismatch covers the panel side. The same lesson reaches past Windows: a launch line that looks right can still miss its launch context, as the wayfire autostart line that never launches the kiosk browser shows on a Linux kiosk. If the same workstation also needs a floor-side status board, our shop-floor signage is the line built for that wall.

Questions