Forums Bug Reports /window -o behaving like /window -a

When creating a custom /window, I usually always use the -D switch to enable the option of desktop placement toggling. I also tend to default its setting to always-on-top in case I choose to move it to the desktop. However, even as an MDI window, the -o switch attempts to bring the window to the foreground as if the -a (activate) switch were used. This is true even if the -n (minimize) switch is used as well.

Solution: Don't activate the window when -o is used. Only set its on-top style when converted into a desktop window, but not as an MDI window.

Thanks for your bug report. I have not been able to reproduce this issue yet. Can you descibe a step by step method that reproduces this issue for you?

Any one or more of those, while any other window (eg, a channel or status window) is active, and typed either from the editbox or from a script event. The effect: @sanity becomes the active window.

Edit: In combination with -n, the window activates when called a 2nd or Nth time after having already been created. -n seems to only suppress (minimize) the window on its creation command.

I figure I'm just going to use if (!$window(@sanity)) window -Don2e2mizj100000 @sanity. Maybe somebody's using -o as -a somewhere. Not sure what the design intent is.

I can't reproduce either, none of these commands makes @sanity the active window here (on the latest beta, win7), my mIRC is maximimzed, so are my mdi windows.

Edit: Ok I can reproduce (wasn't so clear that you have to chain these commands):
/window -on @sanity first minimize the window and makes it on top, but a second call makes the window active.

Right, I remember this being discussed before. Since /window -o has always done this, ie. scripts have always been able to use it to force a window to the top, it has been left this way.

Khaled: The confusing part is that it would force a window on-top when that window is MDI. -o does not make MDI windows always-on-top, only desktop windows. So it follows that non-desktop windows should be utterly unaffected?

That's right, the Windows API call to set a window on top always moves a window to the top, regardless of whether it stays on top later or not.