Owned window errantly made a topmost window.

I work on a set of applications where there is one main application that is
the owner window of the windows for the other applications. Everything works
fine initially, however, an interesting bug occurs when: I minimize the main
application (which minimizes the owned window application also as expected),
close the main application (which closes the owned applications as expected),
and restart the main application (which restarts the owned applications as
expected). At this point, the owned window becomes a topmost window and
doesn't minimize when the main window is minimizes. This becomes a problem
because any of the popups displayed by the owner window (and all other
applications that are not topmost) are hidden behind this topmost owned
window. This state persists no matter how many times you open or close the
main application, which does close the owned window applications, too. If you
restart the machine the state of the windows returns to normal. Here's the
real kicker on this unusual behavior: the window states return to normal if
any other application's window is restored from being minimized while the
problem application is not running.

What does all this mean? This is most definitely a bug with Windows Vista
and how it handles owner and owned window relationships. I had found another
location on the MSDN where a Microsoft representative admitted that there was
an issue with owner and owned windows with Alt-TAB on Vista. The really wierd
part of all this is that it only occurs with on subsequent instantiations of
the application after the application was minimized.

Finally, we're testing our software on 2 machines. A set of panasonic
toughbook CF-18's and Dell D620's. The toughbooks only meet minimimum
requirements because we put more memory in them. The Dell is "Window Vista
Capable". The bug does NOT occur on the toughbooks and does occur on the Dell
D620's. Even worse, the bug didn't occur with one of the three Dell D620's
and build release 5728.

I've determined that this issue only occurs with windows Aero. In fact, if
the system is in a bad state when Aero is turned off, the system never leaves
the bad state. If the system is in a good state when Aero is turned off, the
system won't enter the bad state.

Thanks for the reported issue, Chris!
We are currently working with Chris offline to get reproduce the problem in
our lab.

Ivo


"Chris Rehfeldt" wrote:

> I've determined that this issue only occurs with windows Aero. In fact, if
> the system is in a bad state when Aero is turned off, the system never leaves
> the bad state. If the system is in a good state when Aero is turned off, the
> system won't enter the bad state.

Chris,
I sent you a couple of emails today, but I think your email server rejected
them, so I am pasting my email here:

--------------

Hi Chris,
There are tools in the OS that allow capturing some system information, but
in this particular case I think we would a repro application in order to be
able to investigate the problem.

So let me see whether I understand the repro steps correctly:

Steps to reproduce the problem
1. Let’s call the two rocesses PA and PB.
2. You run PA
3. PA creates window A (CreateWindow)
4. PA starts PB (CreateProcess)
5. PB creates window B, passing the HWND of window A as the hWndParent of
window B (in the CreateWindow call for window B)

Result
If you repeat these steps, you end up in a situation where window B becomes
a topmost window


Is my understanding correct?

Thanks:
Ivo