I've wondered about this for some time, and after doing searches in the forum, it would seem that it might have stared with version 9.
Specifically, when double-clicking on the desktop (Windows 7), a Lister will open in either the foreground, or, more frequently, the background.
So, when I open an application (or a fresh instance of it in this case), I expect it to open in the foreground in front of other applications I might have open so that I can use it. But the really weird thing is that Opus will often open a new Lister in the background, and I must click on either the Opus window itself or the icon on the task bar in order to bring it front (or to the foreground) so that I can use it.
There are times when I've got Word open and opening a new Lister actually brings the Lister to the foreground...but this is generally not the case. There are also times when I've got Word open and a new Lister will open in the background.
--I have Opus launch at startup.
--I also have it set to launch from the desktop with a double-click.
Go to /startup in Opus (should take you to the start menu startup folder), right-click the Opus startup shortcut and choose Properties.
Make sure it's set to Run: Normal Window.
Other than that, it could be caused by something not allowing Opus to become the foreground window when launched in that way. The Windows rules for this are quite fuzzy and can go wrong sometimes, in both directions (due to being retrofitted to an old API and also having to guess between user intent and what programs are trying to do).
UAC could also be blocking something, if you're running the whole dopus.exe process elevated from a desktop that is running at a normal non-elevated level. You'd see "ADMINISTRATOR" in all capitals in the Opus titlebar if that was the situation, in newer versions of Opus (e.g. 11.19).
[ul][li]Go to Settings / Customize Toolbars / Toolbars[/li]
[li]Expand User-defined Commands then double-click Add new User Command[/li]
[li]Give the new command a name like MyTestCommand[/li]
[li]Make the command run "Go NEW"[/li]
[li]Then go to the same Preferences page shown above and select MyTestCommand from the drop-down list.
(Quite long-winded. You can see why we changed this in 12. )
If you want to make sure your command is being run instead of the default action, make it run "Help ABOUT" instead of "Go NEW", and you should see the About dialog open when you trigger it. You can then change it to Go NEW (or any command you wish to run via desktop double-click).
I've tried this with Version 11.19 x 64, and if there are no active application windows present on the desktop, a new Lister will open in the foreground. However, opening subsequent Listers brings the first one to a layer in the background, and the new Lister opens up behind it, evidently in a background layer deeper than the original Lister. Opening more Listers places them in front of the second Lister, but still in the layer behind the original Lister, which remains in the background, presumably in the background layer just below the foreground. A rather exhaustive description; I wonder if you can duplicate this behaviour. I'll try this on my other computer, which is running version 12. Maybe I'll have better luck.
Leo, I think I found the reason for the odd behaviour.
After telling Opus to open the Go NEW command from the desktop, one must end the dopusrt.exe process after stopping the main application and then relaunch Opus. Your modification now works, at least with Version 11.19. I'll let you know about version 12 when I get the opportunity.
Scratch that last, Leo. After a Windows restart, it's back to its old tricks.
However, subsequently exiting Opus and then ending the dopusrt.exe process as described above and then relaunching Opus returns the desired behaviour. Maybe it's the order in which things start up that matters? Still in Opus version 11.19; will relate results with version 12 soon. As well, I actually prefer the way newly-launched Listers open in a cascade view, instead of directly over the previously-launched iteration when using the "Go NEW" command.
My guess is there's another tool which is also hooking mouse events on the desktop window, and doing the right thing by forwarding them on to other hooks if it doesn't use the events (else it would break our hook entirely), but perhaps in a way which prevents the ability to make things the foreground window.
Restarting dopusrt.exe /dblclk makes it the first hook in the chain.
Also of note is that the same behaviour holds true regardless of whether you've selected "Open the Default Lister" or "Run a defined User Command" ticked in the Preferences for Double-click on the Desktop in Launching Opus.
Would it be worthwhile to unload or even uninstall, one at a time, the little applets that load upon startup in the hope that I would discover the offending module?
I'm pretty sure it's not version specific, because for the last few versions, WordWeb Pro has had a Hot-Key feature which allows one-click lookup for words beneath the mouse cursor in applications like word or your favourite browser. I turned this feature off, and Opus' Lister-launching behaviour is what you'd expect.
I use WordWeb's lookup feature quite heavily, as I'm an author, so I'm reluctant to turn it off just for the sake of having Opus come to the fore when I open a new Lister. So, at present, my only semi-permanent work-around is the above described procedure...but at least I've found the reason for the problem!
I'm not having this problem (I don't use WordWeb Pro), but now that we know the culprit, would he need to restart dopusrt this way after his boot-up has "settled", thus forcing the system to make DOpus the first in the chain?
I'm guessing a simple DOS batch file could be written that he could double-click right for the desktop which would cycle dopusrt so it would be stopped and then restarted.
Then again, he could, perhaps, force DOpus to delay loading by one or two minutes so it could be loaded sometime after WordWeb Pro.
My apologies. I didn't see any mention of a DOS batch file to make this more convenient for him nor did I see mention of tools to help with startup management. (Although I did see those mentioned in another post.)
I still don't see them until I get down to my post.
Cool beans. I'd been reading the "unread posts" list in chronological order, so I didn't see the startup helpers until after I wrote this apply. I'm glad you cross-linked it.
Thank you scottj for pointing that out. Just signed up here to seek help after doing a fresh install of Win 10 Pro, and updated WordWeb while I was feeling all new and fresh. Just quit the task and now my default listers immediately started behaving normally again.
)