Recent Posts1
Script / Re: [SCRIPT] 'Pin To Taskbar' Using SysPin (Third-Party Tool (Freeware)) Win 7/8/10
« Last post by total_annihilation00 on Yesterday at 21:23:45 »Gemini 3.5 Flash AI generated::
The intermittent "works on the second try" bug you are experiencing is a classic symptom of how Windows handles process creation and Shell communication, specifically when using `cmd.exe` as an unnecessary middleman.
Here is the refactored, robust version of your MultiScript. Below it is a breakdown of exactly why your original script was misbehaving.
### The Robust MultiScript (Replace `"C:\\Path\\To\\syspin.exe"` with the actual full path to your `syspin.exe`. Do the same and modify the code to extend support across all remaining operational modes):
Here are the rest of the codes:
+--------------------------------------------------------------+
| Action | Code | Description |
+----------------------------|--------|------------------------------+
| Pin to taskbar | 5386 | Pin the file to taskbar |
| Unpin from taskbar | 5387 | Remove from taskbar |
| Pin to Start | 51201 | Pin to Start menu |
| Unpin from Start | 51394 | Remove from Start menu |
+--------------------------------------------------------------+
### What was causing the bug? (Under the Hood)
Your original script was doing this:
`MC.Run CMD="cmd.exe" ARG="/C \"\"C:\syspin.exe\" \"C:\file.txt\" 5386\"";`
There are two low-level mechanisms at play here that cause this to fail intermittently, requiring a second attempt.
#### 1. The `cmd.exe` Quoting Trap
When you invoke `cmd.exe` with the `/C` (terminate after execution) flag, you pass the command string into a notoriously complex parser. If the first and last characters of the argument string are quote marks, `cmd.exe` attempts to apply a heuristic to decide whether to strip them.
Depending on whether `$syspin` or `$filePath` contained spaces, `cmd.exe` might strip the outer quotes but fail to properly tokenize the inner ones. This often results in a malformed path being passed to the system, causing `cmd.exe` to quietly abort the operation without an error message. On the second click, the environment state or memory caching might shift just enough for the command to parse, or Explorer "catches up."
#### 2. Win32 Shell COM Interruption (The Real Culprit)
SysPin works by tapping into the Windows Shell API. It does not literally edit your taskbar registry keys; instead, it programmatically invokes an `IShellDispatch` Context Menu Verb (specifically the verb internally mapped to the ID `5386`).
This relies on COM (Component Object Model) Inter-Process Communication (IPC) to send a message to `explorer.exe`.
When you wrap SysPin inside `cmd.exe /C`, you are creating a transient parent process.
1. MultiCommander spawns `cmd.exe`.
2. `cmd.exe` spawns `syspin.exe`.
3. `syspin.exe` sends the COM request to `explorer.exe` to pin the item.
4. `cmd.exe` sees `syspin.exe` executing and often immediately begins its own tear-down process because of the `/C` flag.
If the console subsystem tears down the process tree *before* `explorer.exe` has fully finished handling the COM message across process boundaries, the taskbar pin operation is abruptly dropped. The first attempt "wakes up" the shell verb handler in Explorer, and the second attempt succeeds because the handler is now cached and responds fast enough to beat the `cmd.exe` shutdown window.
### The Fix
By changing `MC.Run` to target `syspin.exe` directly, you bypass the command interpreter entirely. MultiCommander uses standard Win32 `CreateProcess` to launch SysPin in its own stable, independent process space. SysPin can now cleanly send its COM message to the Windows Shell, wait for the acknowledgment, and exit gracefully without an artificial `cmd.exe` wrapper pulling the rug out from under it.
The intermittent "works on the second try" bug you are experiencing is a classic symptom of how Windows handles process creation and Shell communication, specifically when using `cmd.exe` as an unnecessary middleman.
Here is the refactored, robust version of your MultiScript. Below it is a breakdown of exactly why your original script was misbehaving.
### The Robust MultiScript (Replace `"C:\\Path\\To\\syspin.exe"` with the actual full path to your `syspin.exe`. Do the same and modify the code to extend support across all remaining operational modes):
Code: [Select]
```MultiScript
@var $filePath = GetSourceFocusPath();
@var $syspin = "C:\\Path\\To\\syspin.exe"; // Ensure double backslashes
// 1. Sanity Check: Prevent execution if no file is focused
if ( $filePath == "" ) {
return;
}
// 2. Format arguments cleanly without the cmd.exe syntax
@var $args = "\"" + $filePath + "\" 5386";
// 3. Direct Execution: Bypass cmd.exe completely
MC.Run CMD="{$syspin}" ARG="{$args}";
```
Here are the rest of the codes:
+--------------------------------------------------------------+
| Action | Code | Description |
+----------------------------|--------|------------------------------+
| Pin to taskbar | 5386 | Pin the file to taskbar |
| Unpin from taskbar | 5387 | Remove from taskbar |
| Pin to Start | 51201 | Pin to Start menu |
| Unpin from Start | 51394 | Remove from Start menu |
+--------------------------------------------------------------+
### What was causing the bug? (Under the Hood)
Your original script was doing this:
`MC.Run CMD="cmd.exe" ARG="/C \"\"C:\syspin.exe\" \"C:\file.txt\" 5386\"";`
There are two low-level mechanisms at play here that cause this to fail intermittently, requiring a second attempt.
#### 1. The `cmd.exe` Quoting Trap
When you invoke `cmd.exe` with the `/C` (terminate after execution) flag, you pass the command string into a notoriously complex parser. If the first and last characters of the argument string are quote marks, `cmd.exe` attempts to apply a heuristic to decide whether to strip them.
Depending on whether `$syspin` or `$filePath` contained spaces, `cmd.exe` might strip the outer quotes but fail to properly tokenize the inner ones. This often results in a malformed path being passed to the system, causing `cmd.exe` to quietly abort the operation without an error message. On the second click, the environment state or memory caching might shift just enough for the command to parse, or Explorer "catches up."
#### 2. Win32 Shell COM Interruption (The Real Culprit)
SysPin works by tapping into the Windows Shell API. It does not literally edit your taskbar registry keys; instead, it programmatically invokes an `IShellDispatch` Context Menu Verb (specifically the verb internally mapped to the ID `5386`).
This relies on COM (Component Object Model) Inter-Process Communication (IPC) to send a message to `explorer.exe`.
When you wrap SysPin inside `cmd.exe /C`, you are creating a transient parent process.
1. MultiCommander spawns `cmd.exe`.
2. `cmd.exe` spawns `syspin.exe`.
3. `syspin.exe` sends the COM request to `explorer.exe` to pin the item.
4. `cmd.exe` sees `syspin.exe` executing and often immediately begins its own tear-down process because of the `/C` flag.
If the console subsystem tears down the process tree *before* `explorer.exe` has fully finished handling the COM message across process boundaries, the taskbar pin operation is abruptly dropped. The first attempt "wakes up" the shell verb handler in Explorer, and the second attempt succeeds because the handler is now cached and responds fast enough to beat the `cmd.exe` shutdown window.
### The Fix
By changing `MC.Run` to target `syspin.exe` directly, you bypass the command interpreter entirely. MultiCommander uses standard Win32 `CreateProcess` to launch SysPin in its own stable, independent process space. SysPin can now cleanly send its COM message to the Windows Shell, wait for the acknowledgment, and exit gracefully without an artificial `cmd.exe` wrapper pulling the rug out from under it.
O.K. I can confirm the problem lies in making a new "Column Layout". If I stick to the "Default" column layout it works, maybe a new Column Layout with "AutoLoad on Path" is causing issues...