Windows 3.11 Window Focus and Mouse Clicks Explained

In Microsoft Windows 3.11, managing desktop window focus during a mouse click relied on a cooperative 16-bit architecture driven by a single system-wide message queue and a coordinated sequence of internal window messages. When a user clicked on an inactive window, Windows determined the target window through hit-testing, checked whether the window allowed activation, adjusted the visual Z-order, and shifted input focus while updating window decorations. Because Windows 3.11 lacked the preemptive multithreading and separate input queues of modern operating systems, this entire focus transition was handled synchronously and cooperatively across the operating environment.

The Single System Message Queue

Under the Win16 subsystem of Windows 3.11, all hardware events—including mouse movements and button clicks—were captured by device drivers and placed into a single, centralized system message queue. The operating system processed these events sequentially. When a mouse click occurred, Windows retrieved the event and began determining which window was positioned beneath the cursor coordinates.

Hit-Testing with WM_NCHITTEST

To identify the intended target of the click, Windows performed hit-testing from the top of the Z-order down to the desktop window. It sent a WM_NCHITTEST message containing the screen coordinates of the cursor to the candidate window:

  1. The window procedure (typically deferred to DefWindowProc) evaluated the coordinates against its non-client areas (title bar, borders, sizing handles) and its client area.
  2. The window returned a hit-test code, such as HTCLIENT, HTCAPTION, or HTBORDER.
  3. If the click fell outside the window, Windows continued evaluating windows lower in the Z-order until it found a match.

The Activation Handshake: WM_MOUSEACTIVATE

Once the target window was identified, Windows checked if it was already the active, top-level window. If the window was inactive, Windows initiated an activation handshake by sending a WM_MOUSEACTIVATE message to the top-level parent of the clicked window.

This message allowed the application to decide how it wished to handle the incoming focus shift. The application's window procedure returned one of four status flags:

  • MA_ACTIVATE: Activate the window and pass the mouse click message to the target.
  • MA_ACTIVATEANDEAT: Activate the window but discard (eat) the mouse click, preventing accidental clicks on controls inside the newly activated window.
  • MA_NOACTIVATE: Do not activate the window, but still process the mouse event.
  • MA_NOACTIVATEANDEAT: Do not activate the window and discard the mouse event entirely.

If the application did not explicitly intercept this message, DefWindowProc defaulted to returning MA_ACTIVATE.

Z-Order Reordering and Visual State Changes

If activation was confirmed, Windows updated the display hierarchy. The operating system adjusted the window's position in the desktop's internal linked list of windows, bringing it to the top of the Z-order.

Windows then orchestrated the visual transition:

  • The previously active window received a WM_ACTIVATE message indicating deactivation, followed by a WM_KILLFOCUS message directed at the specific control that held keyboard focus. Its title bar was redrawn in the inactive caption color (by default, white or light gray).
  • The newly selected window received WM_ACTIVATE indicating activation, causing its title bar to be redrawn in the active caption color (by default, dark navy blue).
  • A WM_SETFOCUS message was dispatched to the window or its child control, establishing the destination for subsequent keyboard input.

Event Dispatch to the Target

After the focus and activation routines completed, Windows evaluated whether the original mouse event was flagged to be passed along. If MA_ACTIVATE had been returned, Windows converted the raw input into the appropriate window message (such as WM_LBUTTONDOWN or WM_NCLBUTTONDOWN, depending on the hit-test result) and placed it into the application’s message loop to be processed by the appropriate client or non-client handler.