In what way has Directory Opus support been added in the latest version.
I can find no reference to it in the help documentation.
Best Regards
gjbth
I can find no reference to it in the help documentation.
Best Regards
gjbth
AutoDialogs will show its icon in the Directory Opus caption and you will be able to choose the folder to navigate in the program. Just like in Windows Explorer or Open/Save dialogs, etc.
Best regards,
Oleg Chernavin
MP Staff
Best regards,
Oleg Chernavin
MP Staff
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 am sorry, it is quite hard to find out which exact panel is active there from a 3rd party application. This is why I haven't implemented that.
Oleg.
Oleg.
I can understand that.
Thanks!
Thanks!
You are welcome! You may write to the authors of Directory Opus to add command-line support. They may add a parameter to switch the active panel to some specified folder. This way, it will be possible to do that task with AutoDialogs.
I did it this way with Total Commander.
Oleg.
I did it this way with Total Commander.
Oleg.
OK, maybe I'll try that.
Thanks!
Thanks!
Hi, Opus already has such a command. For example, to make the active window go to "C:\Program Files" you could run this:
"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.
"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.
Leo,
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.
Thank you!
Oleg.
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.
Thank you!
Oleg.
Please test the update:
http://www.metaproducts.com/download/betas/adsetup.exe
Oleg.
http://www.metaproducts.com/download/betas/adsetup.exe
Oleg.
Seems to work fine now in XP 32 / DOpus 9 & 10. Thanks for the update!
Great! You are welcome!
Leo,
Thank you very much for describing the command-line tool method!
Oleg.
Leo,
Thank you very much for describing the command-line tool method!
Oleg.
> It is really good that they support command line now!
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.
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.
It is great to talk with you! I added /acmd command support and check version as you instructed.
Can you please test the new version:
http://www.metaproducts.com/download/betas/adsetup.exe
Thank you!
Oleg.
Can you please test the new version:
http://www.metaproducts.com/download/betas/adsetup.exe
Thank you!
Oleg.
Sorry it's taken so long to get back to you; it's been a busy few weeks!
The dopusrt.exe /acmd argument is now part of Opus 10.0.2.1 (beta), which can be downloaded here:
http://blog.dopus.com/2011/11/directory-opus-version-10021-beta.html
The dopusrt.exe /acmd argument is now part of Opus 10.0.2.1 (beta), which can be downloaded here:
http://blog.dopus.com/2011/11/directory-opus-version-10021-beta.html
Hi again,
Just wanted to let you know that the "acmd" change is now in the latest "stable" release of Opus, 10.0.3.0:
http://blog.dopus.com/2012/01/directory-opus-10030-now-available.html
(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!
Leo
Just wanted to let you know that the "acmd" change is now in the latest "stable" release of Opus, 10.0.3.0:
http://blog.dopus.com/2012/01/directory-opus-10030-now-available.html
(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!
Leo