I discovered one flaw in using CommanderInstance.dll inside wincmd.ini, possibly due to my loading the dll via the Autorun.wdx plugin.
To illustrate the flaw, I added this redirection to wincmd.ini
Code: Select all
[lefttabs]
RedirectSection=left[%COMMANDER_INSTANCE%].ini
The idea is for each instance to have its own left tab ribbon by automatically saving each [lefttabs] section in its own file named "left[1].ini", "left[2].ini" and so on.
In early testing this seemed to work with one minor caveat: file left[N].ini must exist before instance N starts.
If the file doesn't exist then TC picks "left[1].ini" even when, i.e., COMMANDER_INSTANCE = 3. I tested this by executing menu entry Configuration>Save Settings from TC instance #3: TC saved the left tabs into "left[1].ini" instead of "left[3].ini". Curiously, if you don't execute Configuration>Save Settings but simply exit instance #3, the right file name is created as "left[3].ini' BUT it's empty (no tabs saved). At this point you can restart instance 3, which will then behave correctly, by saving the tabs to "left[3].ini", since instance 3 found file "left[3].ini" existing when it started.
I have no evidence of the following, but I suspect that when TC calls CommanderInstance.dll the dll can only report 1 as the instance number, perhaps because it isn't yet fully loaded. Then after TC has displayed the instance UI the dll can return the real instance number.
edit: after some more testing I see that regardless of the instance number, each instance reads its initial state from "left[1].ini", if it exists. Of course this makes saving exit state into "left[N].ini" pointless.