PRB: GetActiveWindow Behaves Differently Under Windows NTLast reviewed: March 4, 1996Article ID: Q129852 |
The information in this article applies to:
SYMPTOMSIf a Visual Basic version 4.0 application running under a 32-bit operating system such as Windows NT calls the GetActiveWindow() API function and a window of some other application currently has the focus, the handle of that window is not returned; instead, a NULL is returned.
CAUSEIn Windows NT, each thread of execution can set or get the focus for only those windows created by the current thread. This prevents applications from interfering with each other. One application's delay in responding cannot cause other applications to suspend their response to user actions, as often happens in Windows 3.x. Consequently, the following API functions also work differently under Windows NT:
GetCapture (VOID) GetFocus (VOID) ReleaseCapture (VOID) SetActiveWindow (HWND) SetCapture(HWND) SetFocus (HWND)These functions now return NULL when the target window is owned by an application other than the one that calls the function. Therefore, it is important to test the return value of these functions before using it. For example, if you call GetFocus and another thread's window has the input focus, then instead of returning the handle of a window that belongs to another thread, the function returns NULL. Similar considerations apply to GetCapture and GetActiveWindow. The Set functions can only specify a window created by the current thread. If you attempt to pass a window handle created by another thread, the call to the Set function fails.
RESOLUTIONYou can use the functions GetForegroundWindow and SetForegroundWindow instead of GetActiveWindow and SetActiveWindow respectively, to manipulate windows created by another thread. Note that these are "32-bit only" API functions.
STATUSThis behavior is by design.
MORE INFORMATION
Steps to Reproduce Behavior
|
Additional reference words: 4.00 vb4win vb432
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |