Handle is that unique identification no. given by Windows at
runtime,whenever any control container (i.e form ,etc) are loaded. From
this Handle property (HWND) we can easily identify any control. If you
use object spy on any of the system controls displayed on desktop , you
can get the HWND property of that control. In the same way similar tool
is provided with Microsoft Visual Studio (Spy++) , which also displays
the detail properties of any control displayed.
We're so used to Windows working "out of the box" (until it crashes), that we rarely stop to think how do all the OS's everyday tasks work.
For example, when you click on the maximize button of a certain window, how does Windows know to maximize that specific window? Similarly, when pressing Alt+Tab to switch between windows, how does Windows connects the "icon" we've stopped on to the actual window it represents?
All these task are extremely complex, and they all relay on the ability to uniquely identify each window and control in the OS.
This is done mostly through the use of WHND - the window's handle. A simple way to think of a handle is as a unique arrow which points the OS to the exact window you're referring to.
This is what sometimes makes it a very good identification property within a specific test-run- it's guaranteed to be unique, and consistent through the window's life cycle. However, as a different handle is generated every time the window is constructed, it's not a very good property to relay on between test-runs.
The Microsoft Windows operating environment identifies each form in an application by assigning it a handle, or hWnd. The hWnd property is used with Windows API calls. Many Windows operating environment functions require the hWnd of the active window as an argument.
The handle returned by the hWnd property is assigned to the form at run time. Therefore, the handle might be a different value every time the form runs, but the value remains constant during the life of the form. If the same form runs multiple times, each instance of the form can have a different hWnd value.
hWnd is available in user-defined Forms and Toolbar objects and is read-only at both run and design-time.
We're so used to Windows working "out of the box" (until it crashes), that we rarely stop to think how do all the OS's everyday tasks work.
For example, when you click on the maximize button of a certain window, how does Windows know to maximize that specific window? Similarly, when pressing Alt+Tab to switch between windows, how does Windows connects the "icon" we've stopped on to the actual window it represents?
All these task are extremely complex, and they all relay on the ability to uniquely identify each window and control in the OS.
This is done mostly through the use of WHND - the window's handle. A simple way to think of a handle is as a unique arrow which points the OS to the exact window you're referring to.
This is what sometimes makes it a very good identification property within a specific test-run- it's guaranteed to be unique, and consistent through the window's life cycle. However, as a different handle is generated every time the window is constructed, it's not a very good property to relay on between test-runs.
The Microsoft Windows operating environment identifies each form in an application by assigning it a handle, or hWnd. The hWnd property is used with Windows API calls. Many Windows operating environment functions require the hWnd of the active window as an argument.
The handle returned by the hWnd property is assigned to the form at run time. Therefore, the handle might be a different value every time the form runs, but the value remains constant during the life of the form. If the same form runs multiple times, each instance of the form can have a different hWnd value.
hWnd is available in user-defined Forms and Toolbar objects and is read-only at both run and design-time.
