I just saw another thread about Opus lister windows starting in the background, which reminded me that I have this issue, too. I don't think I have any non-standard desktop software that is interfering. My issue is that, when I start a new lister by right-clicking on the taskbar icon and selecting any of the items in the jumplist that appears, the lister opens in the background. It doesn't matter which item in the jumplist I click on; any one of my saved listers, or just clicking on "Open new lister" will open the lister in the background. However, if I simply click on the taskbar icon, the default lister pops up in the foreground as it should. Not a huge deal, but a mildly annoying little quirk.
Are you running Opus as administrator?
No.
I would like to revive this one, with some additional pieces of information: Interestingly, sometime around the end of last year, this issue went away, and Opus opened all of its listers nicely in the foreground as it is supposed to. I don't really know what "fixed" it, but I had installed some Windows updates, and also replaced my anti-virus (went from MSE to Avast).
Now, this morning all of a sudden the old behavior came back: Now listers again open in the background whenever I invoke them from the context menu that pops up when I right-click on my taskbar icon. The only exception to this is when I either directly click on the taskbar icon with no lister open at all, or, if there's already a lister open, right-click on the taskbar icon and click on "Directory Opus" will bring up the default lister in the foreground.
I know this isn't really much to work with, but maybe this description does ring a bell with one of the wonderful developers. Otherwise I guess I'll just have to live with Opus opening in the background, again...
A couple more experiments I did: I clicked on "Exit Directory Opus" to exit the background process, then right-clicked on the taskbar icon to open one of my layouts: Now (of course...) it opens in the foreground (after a brief delay). O.k., fine, let's close that lister and try again (while leaving the background process running, as usual): Lo and behold, now the lister opens in the foreground! Tried a couple more times, the lister opens in the foreground every time.
Great, so I think it has something to do with when/how the Opus startup process is launched. So I try to play around with preventing some other startup programs from launching to see if that has some effect, but it doesn't.
Alright, alright, I go back to my original configuration, click on "Exit Directory Opus" to exit the background process, then right-click on the taskbar icon to open one of my layouts: It opens in the foreground (after a brief delay), see above. Okay, one last time, let's close that lister and try again: Darn it, now the lister opens in the background again. Try as I might, if the background process is running already, I cannot open any of my layouts in the foreground anymore.
Summary: I simply don't understand what is going on here. Somehow whether or not Opus will open a lister in the background or in the foreground simply seems to be iffy, and determined by variables unknown to me.
Question: Is there any way to make this more reliable?
There might be something running in the background which is taking the focus (or taking the ability to take the focus, which only one application can ever have).
Using Process Monitor to see which processes other than dopus.exe have activity when you open the layout may reveal something.
Well, I can try and experiment some more, including watching process monitor. But, why would whatever is doing this only prevent a lister from getting the focus when it's started via right-clicking on one of the layouts in the taskbar context menu, but do no harm when I just click on the main "Directory Opus" item?
The two things launch (or reactivate) the windows in very different ways.
Any way to launch the Windows in the same way? I mean, why do they have to be different? Yeah, I know, maybe my question/suggestion is naive, but maybe not...
Update: I think I found the culprit: I use ObjectDock, which seems to not let Opus start those listers in the foreground. If I quit ObjectDock, the listers launch in the foreground, with ObjectDock running, the open in the background. Is there anything I could do about that, short of not using ObjectDock? I did go through all of the positioning options in ObjectDock, and none of those helped.
But, I'll still get back to my previous point: All my other programs, and even Opus when launched a certain way, open in the foreground, so why not my saved layouts? Any way to fix this behavior? Please?
We can't change the way jump lists execute commands. That is part of Windows, and doesn't cause problems on a normal machine.
I don't know what ObjectDock is doing but if it's interfering with AllowSetForegroundWindow or similar APIs when commands are launched via jumplists then that's something its authors would need to investigate/fix.
Well, here's the thing: DOpus is the only application I have here in my taskbar (and I have two dozen of them) that seems to be bothered by ObjectDock. So, yes, without ObjectDock the issue is gone, but on the other hand the issue seems to be exclusive to DOpus, which may warrant some attention, perhaps. Don't get me wrong, I understand very well that you may have more pressing issues to investigate, but simply pushing this off to StarDock (the guys who developed ObjectDock) may be a bit on the glib side, too...
Because of course StarDock software has never caused any problems before 
Oh yeah, no argument from me on this one! I am quite careful to try and always use their "last version that kind-of worked". They continuously break stuff in the process of "improving" it, so I keep using what I know works well. In this case this is version 1.90, build 535u (...) of ObjectDock. This and Fences (also a previous version) are the only software from StarDock I use.