These might be a frequently asked questions.

1. Does the foreground window of a thread need to be a top level
window? I was thinking not. But an experiment left me puzzled.

I have an application in which there is a main window started by the
main application thread (T1). This main window contains an ActiveX
control created in another thread T2. Now when I click on the control,
I find that GetForegroundWindow() reports the main window as the
foreground window. Going by the definition I was expecting the
foreground window to be "the window in the foreground thread that the
user is currently interacting/working with", which happens to be the
ActiveX control in T2, in my application. What might be going on?

2. Could someone also elucidate the differences between active window
and foreground window?

Thank you
Ranjit

On 28 nov, 02:35, Ranjit <ranjiti...@gmail.com> wrote:

GetForegroundWindow() is a global state, GetActiveWindow() is a per
thread state, stored in internal Thread Info structure of each thread.
(LISWatch in MSDN)

On Nov 28, 6:34 am, Christian ASTOR <casto...@club-internet.fr> wrote:
Thanks Christian,

I am however still having trouble understanding (From LISWatch)

"GetForegroundWindow, returns the handle of the window the user is
interacting with"

Am having difficulty understanding the "interacting with" part. Is
this the window with Focus?

In my example, I was "interacting" with the ActiveX control window
(created in Thread T2), which I found got the Focus once i clicked on
it, but the Foreground window got reported as the Main Window (which
was Active) owned by Thread T1.

-Ranjit

On Nov 29, 6:03 am, Ranjit <ranjiti...@gmail.com> wrote:

No, it is the main frame window that the user is
interacting with.

From the descriptiong of SetForegroundWindow() you find:

The foreground window is the window at the top of
the z-order. It is the window that the user is
working with.

Jussi Jumppanen
Author: Zeus for Windows IDE
http://www.zeusedit.com