I can find no reference to it in the help documentation.
Will it be possible to make AD register which display is active when using dual display, in Directory Opus? As it is now, it only works for the left/upper display, no matter which one is selected/active.
I did it this way with Total Commander.
"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd Go "C:\Program Files"
If no Opus windows as open then it will open a new one showing the folder; otherwise, it will send the most recently active window to that folder, also respecting the active side of a dual-file-display window.
I am not sure how AutoDialogs is currently telling Opus to change folders, but it seems to open a new Opus window sometimes or and change folders in the existing window at other times, with no clear pattern that I can see. Using the command above will also solve that problem.
(When it triggers the folder change, AutoDialogs doesn't seem to be running any exe/command-line, so I'm not sure how it is sending the change to Opus right now. If it's sending a private window message then that isn't ideal as the private messages and their arguments are subject to change between Opus versions. On the other hand, the command above is part of the published API and should always work.)
Note that the command uses dopusrt.exe not dopus.exe itself. dopusrt.exe is a small helper app for sending commands to the main Opus process. It will always be in the same location as the main dopus.exe.
To cope with different install paths, as well as USB-exported versions of Opus, please don't hardcode the exe path. Instead, I suggest looking up the dopus.exe path via the window handle (GetWindowThreadProcessId -> OpenProcess -> GetModuleFileNameEx -> CloseHandle) and then changing the name from dopus.exe to dopusrt.exe.
It is really good that they support command line now! Currently AutoDialogs uses navigation in the tree, which sometimes fails, especially on 64-bit systems.
I tested the command line tool and found a bug - if you have only 1 lister window open, it correctly switches it. Otherwise if you have 2 or more listers, it always opens a new Lister window.
Can you please contact Directory Opus developers to ask them to fix it? I will change AutoDialogs to use this method shortly.
Seems to work fine now in XP 32 / DOpus 9 & 10. Thanks for the update!
Thank you very much for describing the command-line tool method!
Opus always has. :) (Although I think the info about how to use the command-line may have been difficult to find until the new manual was written. It's in the reference part of the manual now, though.)
> Currently AutoDialogs uses navigation in the tree, which sometimes fails
Ah, so presumably the old method didn't work when the tree was turned off, which is another bonus to the new method.
> I tested the command line tool and found a bug - if you have only 1 lister window open,
> it correctly switches it. Otherwise if you have 2 or more listers, it always opens a new
> Lister window.
I haven't been able to reproduce that so far. The only time a new window opens is if I hold Shift down when I click, which I presume tells AutoDialogs to open a new window for the folder. (When I do that, it looks like it is doing a ShellExecute on the folder, since it opens in Explorer instead if I turn off Opus's Explorer Replacement option.)
However, I noticed a slightly different problem. Opus file displays can be in three modes: Source, Destination or Off. When "dopusrt.exe /cmd" is used, it tries to find a Source lister to send the command to, but that may not be the lister that was active when you invoked AutoDialogs. (e.g. If you have two single-display listers open, one Source and the other Dest, if you click on the Dest one and use AutoDialogs, the folder change will happen in the Source one.)
I don't think there is much that can be done about this right now, but I have written a change that should go into the next version of Opus where you can use "dopusrt.exe /acmd" (acmd instead of cmd) to send commands to the window which was most recently active. That should work better with AutoDialogs.
If you want to take advantage of the new /acmd while maintaining compatibility with older versions, you could look at the Product Version in the dopus.exe or dopusrt.exe resources and check that it is greater than 10.0.2.0. (10.0.2.1 will be the first version that understands /acmd.)
In the mean time, and for older versions, I think using /cmd is still better than the old method. The active window is almost always also the source window (or a dual-display window, which will always shave a source file display inside it).
> Can you please contact Directory Opus developers to ask them to fix it?
I forgot to say before that I am one of them. :) I'll be happy to help with anything if I can. I'll see if I can get a test version with the /acmd change so you can try it, but first I have to finish off some other changes that I also want to test.
Can you please test the new version:
The dopusrt.exe /acmd argument is now part of Opus 10.0.2.1 (beta), which can be downloaded here:
Just wanted to let you know that the "acmd" change is now in the latest "stable" release of Opus, 10.0.3.0:
(Previously it was only in the "beta" releases, which anyone could download & install but which were not pushed through the update-checker.)
All the best!