ForegroundLockTimeout not consistent

[Heinz Biermann]

When I had a problem with a login window popping up behind other
windows, I searched Goggle Groups and found a reference to the registry
entry ForegroundLockTimeout. Setting it to zero solved my problem, so it
seemed.

Unfortunately, the next day the window popped up behind again, even
though ForegroundLockTimeout was still zero! Some testing turned up that
the window came to the front as desired until I used my Visual Studio
..NET (2003) environment for debugging and hit a breakpoint. Afterwards,
the login window started staying behind again. (Debugging alone, without
hitting a breakpoint, did not cause this change in behavior.)

To me, this indicates that the registry entry ForegroundLockTimeout is
not the main entry that determines if a window can steal the focus or
not. Even with ForegroundLockTimeout set to zero, a reboot does not
help. I have to use regedit to change the value to 0x30d40, immediately
change it back to zero, then log off and back on again. Could it be that
the act of changing ForegroundLockTimeout from non-zero to zero triggers
the change of another key? Has anybody seen a similar behavior?

Thanks,
Heinz

 

[Dave Patrick]

Logon for what?

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect


:
| When I had a problem with a login window popping up behind other
| windows, I searched Goggle Groups and found a reference to the registry
| entry ForegroundLockTimeout. Setting it to zero solved my problem, so it
| seemed.
|
| Unfortunately, the next day the window popped up behind again, even
| though ForegroundLockTimeout was still zero! Some testing turned up that
| the window came to the front as desired until I used my Visual Studio
| .NET (2003) environment for debugging and hit a breakpoint. Afterwards,
| the login window started staying behind again. (Debugging alone, without
| hitting a breakpoint, did not cause this change in behavior.)
|
| To me, this indicates that the registry entry ForegroundLockTimeout is
| not the main entry that determines if a window can steal the focus or
| not. Even with ForegroundLockTimeout set to zero, a reboot does not
| help. I have to use regedit to change the value to 0x30d40, immediately
| change it back to zero, then log off and back on again. Could it be that
| the act of changing ForegroundLockTimeout from non-zero to zero triggers
| the change of another key? Has anybody seen a similar behavior?
|
| Thanks,
| Heinz

 

[Heinz Biermann]

Logon for what?

It's a logon for a document management system. My program references
some third-party dlls, and first thing you have to do is log on. One of
the logon options is to bring up a dialog box for the user to
interactively fill in the info.

On some machines, this box pops up in front, on some it stays hidden
behind other open windows. To test this, I started my program from a
shortcut, then quickly gave focus to another open window (Windows
Explorer, in this case) that covered a large part of the screen. With
the default setting of 200000 for ForegroundLockTimeout, the logon
always stays behind the focus window. I was able to consistently bring
the window to the front by setting ForegroundLockTimeout to zero. So far
it behaves like advertised.

But things get weird when I hit a breakpoint during debugging in VS.NET.
As I said earlier, afterwards the window stays hidden behind other
windows even though ForegroundLockTimeout is still zero.

 

[Dave Patrick]

Maybe you can do something equivalent to AppActive. Better to ask them in
one of the programming groups.

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect


:
| It's a logon for a document management system. My program references
| some third-party dlls, and first thing you have to do is log on. One of
| the logon options is to bring up a dialog box for the user to
| interactively fill in the info.
|
| On some machines, this box pops up in front, on some it stays hidden
| behind other open windows. To test this, I started my program from a
| shortcut, then quickly gave focus to another open window (Windows
| Explorer, in this case) that covered a large part of the screen. With
| the default setting of 200000 for ForegroundLockTimeout, the logon
| always stays behind the focus window. I was able to consistently bring
| the window to the front by setting ForegroundLockTimeout to zero. So far
| it behaves like advertised.
|
| But things get weird when I hit a breakpoint during debugging in VS.NET.
| As I said earlier, afterwards the window stays hidden behind other
| windows even though ForegroundLockTimeout is still zero.