57

In Windows, what is the difference between foreground and active window? To be specific, under what circumstances can a foreground window not be an active window? If the 2 terms are referring to the same concept why there're 2 terms.

The msdn documentation here mentions "clicking a window, or by using the ALT+TAB or ALT+ESC key combination" makes a window active as well as foreground. There is nothing explicitly about the difference between the 2 terms.Check MSDN.

Community
  • 1
  • 1
JavaMan
  • 4,954
  • 4
  • 41
  • 69

2 Answers2

73

The active window (the result of GetActiveWindow()) is the window attached to the calling thread that gets input. The foreground window (the result of of GetForegroundWindow()) is the window that's currently getting input regardless of its relationship to the calling thread. The active window is essentially localized to your application; the foreground window is global to the system.

For example, if a window belonging to another process is the foreground, calling GetActiveWindow() from within your own process will return NULL.

I believe that it's true that being the foreground window implies being the active window, but the converse is not true. Also note that in modern Windows, applications generally cannot use SetForegroundWindow() to steal focus from another process (unless that process has explicitly given permission via AllowSetForegroundWindow).

jamesdlin
  • 81,374
  • 13
  • 159
  • 204
  • 4
    This is _the_ right answer. Also useful to read is [this blog post](http://blogs.msdn.com/b/oldnewthing/archive/2008/10/06/8969399.aspx). – Ruslan Mar 11 '15 at 11:47
  • 1
    It is not strictly true, that calling `GetActiveWindow` from a background thread returns `NULL`. A background thread's window can be activated, without making it the foreground window (e.g. by calling `SetForegroundWindow` without meeting the requirements, or if you switch to another application in between launching an application and the application showing its UI). You are almost right about the active window, though: The active window is virtualized per **thread** (or input-attached thread group), not per application, or process. – IInspectable Oct 14 '15 at 14:22
  • Waybackmachine link for blog post shared by @Ruslan https://web.archive.org/web/20150111083454/http://blogs.msdn.com/b/oldnewthing/archive/2008/10/06/8969399.aspx Title of the blog - "Eventually, nothing is special any more" – Sahil Singh May 05 '20 at 19:29
  • 1
    Annoying that MSDN moved all of its content without setting up redirects to the new locations. The current location is [Eventually, nothing is special any more](https://devblogs.microsoft.com/oldnewthing/20081006-00/?p=20643). – jamesdlin May 05 '20 at 19:31
14

I find the description in MSDN a bit confusing as well but here is my revised take:

First a foreground and background window have nothing to do with active windows, it has to do with threading, see below. So it is technically possible to have background window as an active window however it is confusing and the system doesn't do this for you, instead your app needs to call e.g. SetWindowPos to make the background window active.

The system can only have one active top-level window at a time, the system will activate the top-level window if you are working on a child window. All input is then directed to the active window and then normally passed to the child window.

/----------------------\
|                      |
|   FOREGROUND WINDOW  |--\
|                      |  |
\----------------------/  |
  | BACKGROUND WINDOW     |
  \-----------------------/

/----------------------\
|                      |
|    ACTIVE WINDOW     |--\
|                      |  |
\----------------------/  |
  | BACKGROUND WINDOW     |
  \-----------------------/

From MSDN

Active Window

An active window is the top-level window of the application with which the user is currently working. To allow the user to easily identify the active window, the system places it at the top of the z-order and changes the color of its title bar and border to the system-defined active window colors. Only a top-level window can be an active window. When the user is working with a child window, the system activates the top-level parent window associated with the child window.

Foreground/Background

Each process can have multiple threads of execution, and each thread can create windows. The thread that created the window with which the user is currently working is called the foreground thread, and the window is called the foreground window. All other threads are background threads, and the windows created by background threads are called background windows.

AndersK
  • 35,813
  • 6
  • 60
  • 86
  • Microsoft said that, a foreground window (belong foreground thread) is given more priority. In your 3rd case, Is ACTIVE WINDOW received same privilege? – pinichi Oct 15 '10 at 08:40
  • msdn's description of Active Window: *An active window is the top-level window of the application with which the user is currently working. To allow the user to easily identify the active window, the system places it at the **top of the z-order** and changes the color of its title bar and border to the system-defined active window colors. Only a top-level window can be an active window. When the user is working with a child window, the system activates the top-level parent window associated with the child window.* So is it possible to have the 3rd case given above? – JavaMan Oct 15 '10 at 10:32
  • 3
    Yes, it's possible. An Alway On Top window (has WS_EX_TOPMOST) can overlap an active window (title bar blur, select text not hightling, text cursor...though) – pinichi Oct 18 '10 at 12:31
  • @pinichi AFAICT always-on-top doesn't matter. (You alternatively can direct keyboard input to a window that isn't on top if you use focus-follows-mouse.) – jamesdlin Feb 21 '15 at 08:21
  • And this question really was about the difference between `GetActiveWindow`/`SetActiveWindow` and `GetForegroundWindow`/`SetForegroundWindow`, not about top-most or z-ordering. I'm surprised that this was accepted. – jamesdlin Feb 21 '15 at 12:20
  • 1
    **−1** These terms are about internally-in-process versus system global, as explained in [the other answer](http://stackoverflow.com/a/28643729/464581) and in [Raymond Chen's blog article](http://blogs.msdn.com/b/oldnewthing/archive/2008/10/06/8969399.aspx) linked to in [a comment](http://stackoverflow.com/questions/3940346/foreground-vs-active-window#comment46220151_28643729) on that answer. – Cheers and hth. - Alf Mar 16 '15 at 15:12
  • 1
    I'm afraid, this doesn't make much sense. The first half of your answer is completely off target, while the second part quotes the inaccurate MSDN documentation. The system does **not** change the color of the title bar of the active window, for example. It does so for the foreground window (which happens to be the active window of the foreground thread). In all, this answer leaves much to be desired, and doesn't really answer the question. This should not be the accepted answer. – IInspectable Oct 20 '15 at 11:50