Zugg Software :: View topic - Auto-mapper "always on top" bug.

Newbie Joined: 14 Feb 2004 Posts: 7

Hello!

I'm running zMud maximized to the whole screen and I have auto-mapper window (not docked) in the upper right part of the screen with the "always on top" pin enabled (so that mapper is not covered by zMud output window).

Unfortunately in this configuration when I press "alt+tab" to switch to another application, quite often mapper would still remain on top thus covering part of the application I've switched to. So far I was unable to determine when exactly does it happen, but if you press "alt+tab" rapidly several time you are almost guaranteed to get this effect.

Needless to say, this behaviour is extremely annoying :) Is it a known problem and perhaps there's a known fix for it?

For the reference -- I am running Windows XP.

Enchanter Joined: 10 Oct 2000 Posts: 656 Location: USA

The on-top functionality is a windows thing, I doubt there is much, if anything, zugg can do about this. Hopefully in the future microsoft will enhance the on-top windows.

Newbie Joined: 14 Feb 2004 Posts: 7

In fact, I've done some additional testing and here's what I've found:

* It appears that each time when zMud application loses focus it does something -- at a guess it might be unsetting "always on top" flag for the auto-mapper.

This routine quite often works just fine, but not always. When it fails, there seem to be two possible effects:
a) auto-mapper window remains on top of the application that was switched to (as I've described originally);
b) the entire zMud remains on top. More specifically it looks like another application (the one we are switching to) gets on top and then immediatelly zMud redraws itself on top of this another application. Input focus, however, correctly remains on the application that we've switched to.

I've been able to reliably reproduce these problems by pressing "alt+tab" VERY quickly to switch from zMud to another application. However this problem does also occur during normal operation (when "alt+tab" is pressed normally).

Moreover, there's also another very strange problem that is seemengly related to the zMud's handling of the "always on top". I'm using ICQ and I'm using floating contacts that are "always on top". As soon as I launch zMud (with the auto-mapper in the "always on top" mode) and switch applications back and forth several times (using "alt+tab"), ICQ floating contacts disappear. Somehow their "always on top" status gets defeated by zMud :) I don't think I've ever seen it happen, except for zMud. So I do think that zMud does some weird things :)

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I think your right. Zugg states that Windows has problems with the on top and the Zorder which controls which window is above another. I am guessing that the on top and roll up buttons are a 3rd party component and they have bugs in them that Zugg can't do anything about. It is just a quirk we all have to live with.

Newbie Joined: 14 Feb 2004 Posts: 7

I have a friend who happens to know a thing or two about windows programming and he wrote a simple program that properly sets automapper window on top of the zMud window without resorting to any weird stuff... Here's the relevant code:
SetParent(hwndMapper, hwndZmud);
SetWindowPos(hwndMapper, hwndZmud, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED);

That works quite fine. Unfortunatelly, like I said before, zMud does weird things. As a result of all this, when auto-mapper window has focus and you do "alt-tab" zMud disappers from the task list completely.

Basically what I'm trying to say is that it is entirely possible to have "on top" functionality without resorting to the weird stuff that behaves strangely, so perhaps Zugg can please fix it?

Or alternatively I'm missing something -- if so, can somebody please explain why zMud "on top" functionality is implemented as it is now?

Posted: Sun Mar 07, 2004 12:11 am

Actually, the SetWindowPos code is the exact code that the 3rd party "On top" control uses to keep the window on top. You have to be careful with the SetParent line since the main zMUD window is NOT the parent of the Mapper window and this might cause other problems if you try to use docking or antyhing like that.

The problem is that this code doesn't work when you have multiple stay on top windows, and multiple parent windows like zMUD has (if you have multiple MUD windows open, for example, and multiple map windows). What works for you doesn't necessarily work for the general user. It's Windows itself that is getting it's Zorder messed up. I've tried many workarounds in the past and have never found anything that works perfectly. I'm running plenty of applications other than zMUD that have these similar problems, so I'm convinced it's a Windows issue and nothing I can do anything about. This is probably why "stay on top" is not a supported Windows property. This is on my BIG list of stuff I wish Microsoft would fix.

Newbie Joined: 14 Feb 2004 Posts: 7

Hmm.. I understand why SetParent is not a good idea for all uses...

Perhaps non-modal dialog windows can be used? They stay on top just fine and can be moved anywhere (including outside parent window area).

Posted: Mon Mar 08, 2004 11:26 pm

All of the zMUD windows are already non-modal. Modal windows force you to close them before you can do anything else (like a confirmation window or a window where you have to click OK or Cancel). All of the zMUD windows like the MUD Output, settings editor, mapper, etc are already non-modal meaning you can freely select any window or cycle between them.

Only when a window is DOCKED is the Parent of the window set to the main toolbar window. When a window is UNDOCKED, it doesn't have a parent. The ability to dock/undock windows and the ability to have MULTIPLE stay-on-top windows is what is causing the problem.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I think the problem isn't the on-top thing, it's the alt-tab thing.

Occasionally (and this has been from I dunno, Zmud 6.16, maybe even Zmud 5.55) when you alt-tab, the focus of the application changes to the correct app, but it doesn't bring that app to the foreground.

It doesn't happen that often, so I just give the focus back to zmud then alt-tab a second time and it works.

This happens with the main window as much as with any of the other windows, but for me that's maybe once a day. I guess it's something that I've lived with for many years so it's just reflex to refocus it as I said above.

And like I said before, it's been happening for years so it's not related to the new theme support or anything like that. I'm just not sure what it is related to...

Newbie Joined: 14 Feb 2004 Posts: 7

quote:
Originally posted by Zugg

All of the zMUD windows are already non-modal.

I apologize for not being 100% clear the first time around.

The keyword is dialogs. When you create window as dialog window (not as standard window), it would stay on top of its parent window and you'll be able to move it anywhere (even outside the parent window itself). The simpliest example -- "Find..." dialog in Internet Explorer (or any and all options screens in various apps).

Non-modal insures that you are still able to interact with the parent window when dialog is open.

My terminology above may not be 100% correct (I'm not very familiar with Windows programming), but I hope the idea should be clear.

quote:
Originally posted by Rainchild

I think the problem isn't the on-top thing, it's the alt-tab thing.

While you are correct in your observations of Alt-Tab problem, it doesn't happen as long as you are not using "always on top" feature. So apparently this is the problem with the "always on top" feature.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

A dialog window is just a normal window with some options turned on by default. If you create a non-modal dialog window, then you basically have once more a normal window with some other options set and the stay on top problem will not be resolved by this.

Newbie Joined: 14 Feb 2004 Posts: 7

quote:
Originally posted by Kjata

A dialog window is just a normal window with some options turned on by default. If you create a non-modal dialog window, then you basically have once more a normal window with some other options set and the stay on top problem will not be resolved by this.

Well, let me try to get this straight one more time.

If you SetParent for the window, it is guaranteed that this window will be always on top of its parent. This, for example, can be used to keep auto-mapper always on top.

However, if you do SetParent to a simple Window, then you cannot move this window outside its parent window area.

To solve this issue, you can use dialog window -- dialog window can be moved freely (even outside its parent area).

Obviously you'd also need to use non-modal dialogs.

Again -- to illustrate -- in Internet Explorer "Find..." dialog behaves exactly like I would like auto-mapper to behave.

What I'm trying to say -- it certainly should be possible "to fix always-on-top functionality". It might not be very easy though, depending on the functionality required.

Posted: Thu Mar 11, 2004 7:30 pm

So, I'm afraid you just don't understand Windows programming enough, or at least you don't understand the Windows terminology.

Trust me, I've been doing this for 10 years. The "stay on top" problem has been in zMUD for at least 5 of those years. I have spent a lot more time than you have working on possible solutions to this problem. It is not at easy as you think it is. You also don't have any idea how the Docking in zMUD works and how that interfers with this.

There is no difference between a "dialog" and a "window". *Everything* in Windows is a "window" (including buttons, etc). Basically, a "Window" is a memory structure with a "Handle". A "dialog" is just a "window" with certain options set. You can consult the Windows API on the CreateWindow function and the CreateWindowEx function to see all of the options that are available. The "SetWindowPos" function mentioned before is a way to change *some* of these options on-the-fly. Other options require the window Handle to be destroyed and recreated for them to get changed.

The Parent of a window controls more that just what window is below it. The Parent actually has nothing to do with the ZOrder of windows. When zMUD docks a window, it is setting the Parent. That forces a child window to be displayed "inside" of a Parent window. In order for a window to be freely moveable around the screen, like a Non-Modal "dialog" window, the Parent needs to be set to nil.

In your example, the IE "Find" window is a modeless dialog window, and actually has the same "window properties" as the zMUD mapper window. In fact, zMUD itself has a "find" window (hit Ctrl-F) that works the same way. But your example is not valid because in Internet Explorer you do not have *MULTIPLE* Find windows that cause the Windows bug regarding zOrder to appear. In zMUD, you can have the Automapper window set to be on top, and then the Settings Editor, and then the Find window, and then the Room Properties, etc. When you have MULTIPLE windows like this (as I have stated MANY TIMES), that is what causes the problem. You CANNOT just simply use SetParent.

Perhaps you have not used all of the layout features in zMUD to see the problem. I think you are viewing this from a narrow perspective of how you normally use windows. For example, let's say you UNDOCK all of your Windows. Now you have your MUD output window seperate from the main Toolbar window. Open the Automapper window. Now, which window should be the "parent" of the mapper window? You want the mapper window to be on top of ALL windows, not just it's parent. If you use SetParent to the MUD Output window, then the mapper will be on top of the MUD output window, but not necessarily the main toolbar window, or any other window that you might open. There is no single window that can act as the parent when you are using an undocked interface. As I said, SetParent does NOT control the ZORDER. There are other functions for that. And the bug in Windows is that when multiple windows try to use the ZORDER to force themselves to be "on top" then Windows messes up this ZORDER when you Alt-Tab between applications or Ctrl-Tab through other windows.

This bug can commonly be seen in MANY other applications. There have been many times when an application has popped up a dialog box (like for an error message), but then if you Alt-Tab away from that application and then come back, the error dialog can get hidden behind the main window. I've seen this happen with installer programs like InstallShield and Wise Installer. I've seen it happen with Delphi and with Microsoft's own Visual Studio when you have lots of source file windows open.

So, let's just let this issue drop. Unless you are someone who has been programming for Windows for many years or are from Microsoft and actually understand both the technical details of the issue as well as all of the different modes that zMUD can use to control the user interface (like docking, etc), then it's not going to be much help. Just speculating or asking a friend about this doesn't compare to the hours upon hours that I have spent dealing with low level Windows API code with this problem.

Beginner Joined: 13 Oct 2000 Posts: 14 Location: Denmark

This might be a 'windows' problem. But it doesn't seem like it at all.

Here is what I experience:
I use two monitors - though, the same would happen when I used one - I have my main zmud window on one monitor, maximized. And got map and database on other monitor, not maximized.

I also got stuff like a browser and mail program opened, 'underneath' map and database on second window. Note, nothing have been selected to be 'On Top'

If I have been doing something on the mud and want to switch to the browser for instance, either by clicking directly on the window, or by alt-tabbing, it will in most instances just blink up and then behind the zmud windows again.

This does NOT happen if I select the program in the task bar though.

What makes me believe this has nothing to do with windows, but zmud is this:
I can temparily fix this by setting any of the zmud windows "on top" and removing the setting again. (By using the little pin button on the title bar)
This will fix the problem, for the rest of the session. Next time I start ZMud though, the issue is back.
So it's like zmud forgets it shouldn't be on top, until I set it on top and then set it not to be on top.

Semi-related, I have noticed that when I use the mapper, and want to go from mapping mode to follow mode I have to click back and forth a few times before it actually moves away from mapping mode.