0

I have an interesting (but frustraring) problem. I have an application which uses the full screen (this is meant to simulate a third-party fullscreen POS application).

My application displays a sequence of modeless dialog boxes on top of the full screen application. It shows one, hides it, then shows the next, hides it etc. After the 3rd show, the Windows taskbar appears about 1 second later. I can't figure out why.

I've stripped my code right back to see if its something I'm doing in my OnNcActivate handler (which I use to draw my skinned window) but I don't think it is as the problem appears to be timing related. I've tried running Spy++ as well as dumping messages in m WindowProc myself and I still can't see anything odd that would give me any clues.

There are some messages with ID 0x36e in my logs but I can't find out what they are supposed to be. I've checked various message ID lists and can't find them. They shouldn't be any message IDs of my own since WM_USER doesn't start until 0x400.

I know I could get around this problem by auto-hiding the taskbar but I can't ask our customers to configure their taskbars to auto-hide to get round my problem.

Any ideas why the taskbar would appear in relation to my modeless dialog boxes?

EDIT: I completely stripped out my self-drawn GUI code and I still have the same problem. I could be wrong but it would seem that when I call ShowWindow( SW_HIDE) first, Windows tries to activate "another Window" (as it says in MSDN). I think in this case its activating the taskbar rather than the POS application. If on the other hand I open my second window before calling ShowWindow( SW_HIDE ) on the second, then it seems to behave itself.

Cheers Sparky

SparkyNZ
  • 6,266
  • 7
  • 39
  • 80
  • Exactly. Focus needs to go *somewhere*. To make Windows pick your main window, set it up as the owner of the modeless dialog. This article is about modal windows and enabling, but the principle is the same. http://blogs.msdn.com/b/oldnewthing/archive/2004/02/27/81155.aspx – Raymond Chen Sep 02 '11 at 03:55
  • That makes a lot of sense but what if you don't actually own the "main window" - in my case the POS application. Our software can run on a number of different POS applications so I don't really have a means of finding out what the window handle is of the POS. I know how to do that for a specific POS, but I won't be able to predict future POS application behaviour etc. – SparkyNZ Sep 05 '11 at 03:05
  • Surely there must be a way to disconnect an application from the desktop? I do actually have a main dialog window which is also modeless. All the pop-up dialog boxes that I am complaining about have the (hidden) 'main dialog' window as their owner. However, if I press my hotkey to display the main dialog, sure enough - the taskbar appears as well as the main dialog window - every time. Surely its possible to create modeless dialog boxes that have no association with the taskbar/desktop?? – SparkyNZ Sep 05 '11 at 03:15
  • It's not like Windows knows "Hey, this POS window is special and should get focus when there is no obvious place to put focus." *Somebody* needs to say "this window should get focus next." And that person is you. Intuitively, how do you identify the POS window? Maybe you recognize it as the window that had focus before you displayed your dialog. Maybe you recognize it as the topmost fullscreen window. Maybe you recognize it as the only visible window that belongs to POS.EXE. Whatever your method is, covert it to code. – Raymond Chen Sep 05 '11 at 03:27
  • The window manager looks for a window and picks some non-fullscreen window. The taskbar says "Since focus is not on a fullscreen window, I will appear." You window isn't "associated with" the taskbar. The taskbar simply follows its rules. If you want to dissociate from the desktop, you can create your own desktop, but you'll find this is far more complicated than it's worth. – Raymond Chen Sep 05 '11 at 04:01
  • Thanks Raymond. I would be more than happy to determine a) the last window that had focus before my dialog.. or b) identify the last full screen window. How would I go about doing either a) or b) ? I would assume that a) would be the easiest..? Once I somehow get a handle to the last window that had focus, is it simply a matter of calling SetFocus() on that handle when I call DestroyWindow? – SparkyNZ Sep 05 '11 at 04:15
  • I'll leave finding the window as an exercise. You should put focus back on that window before you destroy yours. That you never destroy the focus window and therefore the window manager never needs to guess where to put focus next. – Raymond Chen Sep 05 '11 at 04:23
  • OK.. so I would 1) call hwndPrev = ::GetForegroundWindow() to determine what the user was last working on 2) Pop up my dialog 3) Put focus back to hwndPrev using SetForegroundWindow() ? I really appreciate your help - I have been pulling my hair out on this problem for days and I'm pretty stressed out here at work. – SparkyNZ Sep 05 '11 at 04:26
  • ..and 4) DestroyWindow on my modeless dialog – SparkyNZ Sep 05 '11 at 04:35
  • Unfortunately my steps 1) thru 4) are not working. :-( – SparkyNZ Sep 05 '11 at 04:42
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/3159/discussion-between-sparkynz-and-raymond) – SparkyNZ Sep 05 '11 at 04:56

1 Answers1

0

Following a long discussion I come to the conclusion that DestroyWindow was not the problem. I found in the end that displaying a dialog.. clicking on the POS, then clicking back on the dialog that sometimes the taskbar would appear. I have spent an entire week trying to find reasons for all of this but to no avail. I thought that assigning the POS window as the owner would solve the problem - it didn't. In the end the solution for my problem was to determine if the taskbar is obscured completely before showing my dialog. If it is, I hide the taskbar for the duration which my dialog is displayed (set its placement to SW_HIDE) and then set it to SW_SHOW when I close my dialog. The task bar doesn't pop up and annoy people anymore. Not a fantastic solution for other peoples' applications perhaps, but perfect for our customers.

SparkyNZ
  • 6,266
  • 7
  • 39
  • 80