In the early stage of development in the field of Windows programming, only API functions are supported by Windows programmers. In the hands of programmers, these functions are like "blocks". They can build a variety of interfaces and flexible applications. However, these functions are difficult to understand and are prone to misuse due to their complex structure.
With the continuous development of software technology, many excellent visual programming environments have emerged on Windows platforms, programmers can use the "WYSIWYG" programming method to develop applications with exquisite user interfaces and functions. These visual programming environments are easy to operate and user-friendly, such as Visual C ++, Delphi, and Visual Basic. These tools provide a large number of class libraries and various controls. They replace the mysterious functions of APIs. In fact, these class libraries and controls are built on Windows APIs, but they are easy to use and accelerate the development of Windows applications, so they are widely used by programmers. With these class libraries and controls, programmers can focus on the design of the overall function without having to focus too much on the details. However, this also caused a lot of programmers to "Sticky themselves" in front of the class library and have no idea about the powerful functions of the underlying API functions.
Actually. To develop more flexible, practical, and efficient applications, programmers must directly use API functions. Although the class libraries and controls make application development easier, they only provide general functions of Microsoft Windows. For some complex and special functions, it is difficult to use single class libraries and controls. You must use API functions to compile them directly. API functions are the cornerstone of building the entire windows framework. Only by fully understanding and using API functions can we go deep into windows and give full play to the powerful functions and flexibility of various 32-bit platforms, in order to successfully expand and break through the limitations of class libraries, controls, and visual development environments.
Win32 API is the application programming interface on the Microsoft 32-bit platform ). All applications running on the Win32 platform can call these functions.
Using Win32 APIs, applications can fully tap the potential of Windows 32-bit operating systems. All 32-bit platforms of Mircrosoft support unified APIs, including functions, structures, messages, macros, and interfaces. Using the Win32 API can not only develop applications that can be successfully run on various platforms, but also make full use of the features and attributes unique to each platform.
In specific programming, the differences in program implementation modes depend on the underlying functions of the corresponding platform. The most significant difference is that some functions can only implement their functions on a more powerful platform. For example, security functions can only be used in Windows NT operating systems. Another major difference is system restrictions, such as the range constraints of values or the number of projects that can be managed by functions.
Standard Win32 API functions can be divided into the following types:
Window Management
Universal window control
Shell features
Graphical Device Interface
System Service
International features
NETWORK SERVICE
A brief discussion on how to obtain the window handle and what functions are available! Applicable to VC and BCB.
First, let's get familiar with some Win32 API functions that get the handle, then briefly talk about their usage, and finally introduce the specific application.
Available Win32 API functions:
For details, see the new Win32 + API reference.
1. hwnd findwindow (maid, lpwindowname)
Hwnd find1_wex (hwnd hwndparent, hwnd hwndchildafter, lpctstr lpclassname, lptstr lpwindowname)
2. hwnd windowfrompoint (point & point)
3. bool callback enumchildproc (hwnd, lparam)
Bool callback enumchildwindows (hwnd hwndparent, wndenumproc lpenumfunc, lparam)
Bool callback enumwindows (wndenumproc lpenumfunc, lparam)
Bool callback enumwindowsproc (hwnd, lparam)
General purpose:
The first one is familiar to everyone. It is a conventional weapon for capturing handles. The findwindow brothers can accept the class name or window title of the object to be captured. As a parameter, an hwnd is returned. However, new programmers do not necessarily know the class names of all windows (including the title bar, buttons, and so on. For example, do you know the class name of the Windows desktop window? For window titles, the same title may appear in different windows. Now, let's move on to the next group.
The second group uses the point structure defined by Win32 (typedef struct tagpoint {long X;
Long y;} Point) to obtain the Windows hwnd at the current cursor position, which is the most intuitive weapon! The general operation is as follows: first obtain the cursor's point (bool getcursorpos (lppoint) function) and then use windowfrompoint. In this way, we can obtain the hwnd of any function with window opened! Then, we can obtain the Win32 API function (INT getclassname (hwnd, lptstr lpclassname, int nmaxcount) of the class name. We recommend that you use the character array address for the class name, nmaxcount is the size of the array. At the same time, this method solves the first problem! I can place the mouse anywhere! * ^_^ *
Group 3: these are super weapons used to list and process any window! By combining enumwindows and enumwindowsproc, enumchildwindows and enumchildproc, you can scan and process all windows on the desktop!
Task: Get the class names of all windows.
Solution 1: we first thought about the third group, which can start from the desktop window (which is the ancestor of all windows) and scan in sequence to get the coexistence of class names. It is a bit like Visual Studio's spy ++, or Borland's winsight32. The specific method is as follows: (BCB)
In the main program, call enumwindows and input the youenumproc function address as the first parameter. Do not forget to convert it to the wndenumproc type. The second parameter can be null. : Enumwindows (reinterpret_cast youenumproc, null );
In the yourenumproc function, if the first parameter hwnd = NULL, it will jump off (return false;) and it will end!
Then, prepare the class name array to get the class name and save it.
Returns the true value and continues the next scan.
It does not seem complicated. It is a function recursion.
Solution 2: simple and intuitive
First, prepare a clock, a memory class name method (tmemo is used here)
In the timer processing function:
1. Obtain the point position of the current cursor.
2. Use windowfrompoint again,
3. Get the class name and put it in tmemo.
In this way, you can use the mouse to get the desired window (including buttons), as long as you move the mouse in the window for a while.
Method 3: Actually, the findwindow and loop structure should also be available.
Summary: in fact, there are many methods to obtain hwnd. For example, if you know the window level, scan down in sequence... Let's talk about the third type! You can select the most direct and effective method as needed.
You are welcome to discuss this with me. For details about API usage, refer to msdn.
The following is an example from Microsoft. In this example, all windows are enumerated and a closed message is sent to the window.
# Include </P> <p> bool callback enumwindowsproc (<br/> hwnd, <br/> DWORD lparam <br/> ); </P> <p> // <br/> // enumwindowsproc must be called from a Windows </P> <p> // application on Windows 95. <br/> // <br/> int winapi winmain (<br/> hinstance, <br/> hinstance hprevinstance, <br/> lpstr lpcmdline, <br/> int ncmdshow <br/>) <br/> {<br/> // close all open applications. <br/> // <br/> enumwindows (enumwindowsproc, 0); </P> <p> // now do a regular logoff. <br/> exitwindowsex (ewx_logoff, 0); </P> <p >}</P> <p> bool callback enumwindowsproc (<br/> hwnd, <br/> DWORD lparam <br/>) </P> <p >{< br/> DWORD pid = 0; <br/> lresult; <br/> handle hprocess; <br/> DWORD dwresult; </P> <p> lresult = sendmessagetimeout (<br/> hwnd, <br/> wm_queryendsession, <br/> 0, <br/> endsession_logoff, <br/> smto_abortifhung, <br/> 2000, <br/> & dwresult ); </P> <p> If (lresult) <br/> {<br/> // application will terminate nicely, so let it. <br/> // <br/> lresult = sendmessagetimeout (<br/> hwnd, <br/> wm_endsession, <br/> true, </P> <p> endsession_logoff, <br/> smto_abortifhung, <br/> 2000, <br/> & dwresult ); </P> <p >}< br/> else // you have to take more forceful measures. <br/> {<br/> // get the processid for this window. <br/> // <br/> getwindowthreadprocessid (hwnd, & pid); <br/> // open the process with all access. <br/> // <br/> hprocess = OpenProcess (process_all_access, false, pid); <br/> // terminate the process. <br/> // <br/> terminateprocess (hprocess, 0 ); </P> <p >}< br/> // <br/> // continue the enumeration. <br/> // <br/> return true; <br/>}
After obtaining the window handle, we can obtain the Window environment parameters. In this way, we can obtain the device scenario handle and output the image to this device scenario. However, we cannot enable such a process in windows, and then obtain the handle of another process window. Then, the process controls another process.