Translation Description: I have never used the use of the window. I have recently used the VC to do some concepts of window classes. This time I saw an article when I turned MSDN, telling some of the basic concepts of the window class. , In a hurry, translate it out when learning notes, there may be some details of the details, please bear with me. Put it online, if you feel worth a reference, look at it.
In the MFC programming, the concept of window classes has been relatively small. At least one WndClass (EX) class RegisterClass (EX) is required at the SDK program. But the window class is in Windows, although it is not very deepest, understand the details, the individual feels good to programming should be good.
VcBear Translation vcbear@163.com
Explore WIN32 System Window (Window Classes in Win32) Kyle Marshmicrosoft Developer Network Technology GroupMSDN Technical Group
Summary
This article mainly introduces the operation and use mechanism of window classes in the Win32 system, exploring some details, making the information of Win32 window classes more clear.
In this article, "Class", "Window" These two terms are equivalent to the C classes, but the collection of information related to the window.
Introduction
The style of the window class determines the appearance and style of the window. All windows belong to a window class. Before creating a window, you must register a corresponding window class. 32-bit Windows operating system classes can register the window classes used by all programs in the system.
Most developers think that the window class is a trouble, and they are multi-copy a registerclass function from example or other code, modify some of the parameters. This seems to be a little despised, and there is no role in the window. This article will explore this and describe how the window class is optimized.
The topic of our discussion includes:
What is a Windows Classes system globally, an application is globally, and the application branch class has information about how this information affects how to use window information.
One: Type of window
The Window system provides three types of window classes.
System Global Classes Application Global Classes Application Local Classes
1. System global classes (System Global Classes)
Windows itself registers several system global categories for all applications, including the following common standard window controls
Listbox (List Box) ComboBox Scrollbar Button (Button) Static (Static Tag) Edit (Edit box)
And others less common controls such as TabCtrl, etc.
and also:
Menu Window Desktop Dialog Window Task Table Window Top Tape Icon Window Combolbox: ComboBox Control Downlink List Window MDICLIENT: MDI Style Window
Windows has added DDemLvent classes for DDEML (Dynamic Data Exchange Management Library, because DDEML features have been incorporated into user. Windows 95/98 is not registered # 32772, because it does not use the headband icon style window (because I use the Win2K operating system, this is not try)
All Win32 applications can use a system global class, but you cannot add or remove one such class.
Applications can change the properties of the system global classes via "Subclassing). In Win32, application subcategory a system global class only affects the performance of the window in this process without affecting another process or application. This is a progress in the WIN16 era of other windows compared to the corresponding operation.
In Win32, MS encourages the behavior of "subclass" system classes. Because this technology can change the performance of the window very effective and convenient. For example, if the application wants to limit the input and editing behavior of the Edit control, you can implement the Subclass EDIT class and set a new window process (WindowProc) to handle processing keyboard operations. After subclass, the EDIT control created in this app will use the new window process instead of the standard Edit control window process.
System global window
The current Win32 platform makes the system class and 32-bit processes, and how the system class does not directly affect the application. This section will describe the implementation of the system class, of course, skip this section does not hinder the reading and understanding of the full text.
Implementation in Win9x
The system global class is implemented in WIN9X and WIN3.1. When the system is started, the USER module creates a system class. Win9x and Win3.1 are: When an application subclass is found, Win9x will work as follows:
If you run in debug mode, a Warning message is displayed on the debug screen to copy information of a subclass of window. Fill a copy of the new class to the application's "private" system class list. In the Win9x system, the system maintains such a list for each process to secure the system storage system global class cloning information. All subcatenified window instances in the mandatory process use this system class copy. But this does not affect the existing window, the window is the information using the class information that has been copied to the window instance data in advance, which is not directly using the information saved in the process. Subcale only updates the information of the classes in the process of the process, without updating the class in the window instance.
16-bit applications share the same process space. In Win9x, 16-bit program performance is the same in Win3.1.
WinNT implementation
Winnt has a lot of differences. Winnt includes two Win32 subsystems: a service process and a dynamic connection library (DLL) running in each Win32 process. Take the EDIT class as an example, Winnt exports and registers the Edit class from the DLL in each process space. In this way, the code to process the EDIT control can exist in the DLL, which is in each process space. No system allocation partial process call is required to process the EDIT control, the application caused by the frequent invoking of the control is also avoided. Since the EDIT control instance is only operating in each process space, the impact of the robustness of the system is reduced.
The service process manages the information of each Win32 application, including the public and private window classes of the application. When creating a Win32 thread (ie, a thread calls a function of the USER module or GDI module), the USER module checks if the thread is the first thread of the process, if yes (generally the main thread), the USER module is This process registers system class. When registering a class for any process (except the service module process), the class will be added to the public or private list of the process. In order to improve efficiency, Windows registers system classes for each process and stores the copy of the class information in the application space. This increases robustness, but increases the memory you need to use than Windows95. WindowsNT has also achieved higher performance because Winnt does not need to redistribute memory and copy classes as WINDOW95 as a system class. In Winnt, 16-bit applications still share the same process and share all system global classes. The 16-bit program is always the origin of unstable factors.
2. Applications all class.
Application global class is a class that specifies the CS_GLOBALCLASS flag when registering (this flag has subsequent narrative).
16-bit systems such as Win3.1 Applications "Global" class is true "global", a DLL or application registration application full class, all DLLs and applications in the system can be used. An application all class is consistent in the "global" sense and the system global class, but it is created by the application instead of the system creation.
Win32's application system is different from: Application global classes are just "global" within the process. What does it mean? A DLL or .exe can register a class that allows you to use in the same process space. If a DLL registers a non-application global window class, then only the DLL can use this class, the same, .EXE's non-application global classes apply this rule, that is, this class is here. Valid in EXE.
As an extension of this feature, Win32 has a technology that allows a third-party window control to be implemented in the DLL and then loads this DLL into and initializes to each Win32 process space. The details of this technique are to write the name of the DLL to the specified key value of the registry:
HKEY_LOCAL_MACHINE / SOFTWARE / Microsoft / Windows NT / CurrentVersion / Windows / Appinit_DLLS
This way when any Win32 application is loaded, the system also loads the DLL to the process space (this may be too extra extravagant because many Win32 programs do not necessarily use the control). DLL registers the application all class when initialization, such a window class can be used in each process space. EXE or DLL. This technology is based on this feature of Win32 system: allows automatic (also forced) to load specific DLL in each process space (in fact, this is also a way to break the process boundary, and put your code into other processes. ).
3. Application Listing
Win32 Application Bureau is a class that uses the most frequent class (most of the applications registered with the main window of the main window), which is used in the application module or DLL itself in the statement and registration. Registering an application branch class and application global class is that the local class does not include a CS_GLOBAL CLASS flag.
Second: The information and role of window classes
What information about the window class contains? Let us see the following window structure.
The WNDCLASS structure contains information about the general window class
Typedef struct tagwndclass {
Uint style;
WndProc lpfnwndproc;
Int cbclsextra;
Int Cbwndextra;
Hinstance hinstance;
Hicon Hicon;
Hcursor hcursor;
Hbrush Hbrbackground;
LPCSTR LPSZMENUNUNAME;
LPCSTR LPSZCLASSNAME;
} WNDCLASS;
Members describe the combination of STYLE group logo. Definitions such as window position, device context (DC) allocation, double-click processing. lpfnWndProc points to the address of the window process, which is responsible for processing the window message corresponding to the window class Cbclsextra indicates an additional amount of memory that requires additional allocation. The unit is byte, the system is allocated for the specified number of additional memory CbWndextra indicates the amount of memory that requires additional allocation. , The unit is BYTE, the system assigns the window instance of each class to reserves the specified number of additional memory Hinstance IDs Register the DLL or application instance of this class. HiCon is minimized when a window belonging to this class is minimized. Icon. HCursor belongs to the pointer displayed in the window of the mouse HBRBackground Definition When the program opens or redraws a window that belongs to this class is, the color and style of the population window client area lpszMenuname If there is no dominant definition menu, the default window Menu LPSZClassName string class name
The specific significance of each member is discussed in detail below:
Class Styles (Style)
STYLE members determine the style of the window created from the class, one or several combinations of the following value can be used.
CS_BYTEALIGNCLIENT, CS_BYTEALIGNWINDOW
If you use these two signs, the customer area of the window or the entire window is aligned on the "byte boundary", that is, the level of the system adjusts the horizontal position of the window, the left coordinates of the client area or the entire window are 8 times. The Win32 SDK document says that these two flags affect the width of the window, but actually does not find this phenomenon, this flag only affects the horizontal position of the window (left).
See how the system placed a window width of 4:
Original Window Location Placement with CS_BYTEALIGNWINDOW PLACEments with CS_BYTEALIGNCLIENT 0, Y 0, Y 4, Y 1, Y 0, Y 4, Y 2, Y 0, Y 4, Y 3, Y 0, Y 4, Y 4, Y 8, Y 4, Y 5, Y 8, Y 4, Y 6, Y 8, Y 4, Y 8, Y 4, Y 8, Y 8, Y 12, Y 9, Y 8, Y 12, Y 10 , Y 8, Y 12, Y 11, Y 12, Y 12, Y12, Y 13, Y 16, Y 12, Y 14, Y 16, Y 12, Y 15, Y 16, Y 12, Y 16, Y 16, Y 20, Y
These two markers are invalid in the following two cases:
If the display device uses 8 or more bits of each pixel, the byte alignment does not bring any benefits. In this case, the system ignores the two flags of CS_BytealignClient and CS_BytealignWindow when creating and movement. If you use the SetWindowPos function to change the location of the window, this function ignores the location defined by the CS_BYTEALIGNCLIENT and CS_BYTEALGNWINDOW flags of the window. In the Win32 SDK documentation for a description of WM_WINDOWPOSCHANGEING's confusing, it says: "For a window and WS_THICKFRAME WS_OVERLAPPED style of speaking, DefWindowProc function WM_WINDOWPOSCHANGING response message, and sends a message window WM_GETMINMAXINFO process is to verify that the message window New position and size, forcing window acceptance CS_BytealignClient and cs_bytealignwindow Limited "In fact, after DEFWINDOWPROC accepts the WM_WINDOWPOSCHANGINGING message, it does send a WM_GETMINMAXINFO message, but does not force the window to accept byte alignment, in order to ensure the byte alignment, the application must Calculate the horizontal position by calculation
The existence of CS_ByteAlignClient and CS_BytealignWindow is to optimize the performance of the program, especially in the 3.0 version of the Windows system. At that time, all system font widths were fixed, and the system can align the display of the font by aligning the window byte. This has been ignored in Window after 3.0.
If the program uses the Bitblt function from one window to another window, or copy pixels from a rectangular area from the window, or can be achieved by setting the CS_ByTealignClient flag. If the client area is byte alignment, the program can also ensure that the Bitblt operation occurs in the rectangle of the byte alignment, and the Bitblt operation will be faster than the operation in the rectangle that occurs in non-byte alignment. Of course, the byte alignment is only the left boundary of the window. If further improvement is to be further improved, the width should be connected to the byte alignment.
In fact, for video cards or displays that can be displayed 256 and above, the demand for bytes has been slightly micro. The 256-color display has implemented bytes aligned. In fact, some 16-color display is also byte alignment. On the most display, it does not see the influence of byte alignment to the window position. In a word, the byte alignment flag has no important role.
When using CS_BytealignWindow, it is also equivalent to containing the cs_bytealignclient; dialog box, itself already contains a CS_BYTEALIGNWINDOW flag
CS_OWNDC, CS_CLASSDC, CS_PARENTDC
These markers determine the default DC of the window
If you use a CS_OWNDC flag, a window instance that belongs to this window has its own DC (called private DC), and private DC only belongs to the window instance, so the program only needs to call a getDC or beginpaint to get DC, the system initializes one DC, and save the program to change it. ReleaseDC and EndPaint functions are no longer needed, as other programs cannot access and change private DC. When the CS_OWNDC is selected, the program must be careful when the Mapping Mode is selected, and when the background of the window is erased, the system assumes that and the default is MM_Text. If the private DC is not the same, the window is erased will no longer be visible.
The role of the CS_OWNDC flag is also different from WinNT and Win9x. There is the same address space (4GB) in the WinNT, Win32 subsystem, and other NT processes. The application uses 2GB in this address space. Each CS_OWNDC flag window instance takes up 800 bytes, under NT, there is no problem. Win9x retains 64K local piles for GDI. After the DC enters this heap, even if other GDI object data is released, the DC is still there. This means that each CS_OWNDC window takes up 800 bytes in this valuable memory space. So, the program written for Win9x is best to use the CS_OWNDC to use this flag. Win9x's revision is intended to solve this problem, but the effect is not obvious (and Win9X has started micro) If you use a CS_CLASSDC flag, all window instances belonging to such a class share the same DC (called class DC). There are some private DCs. The advantage, while more saving memory (because there is no need to assign 800 bytes of DC space for each window instance). Each window instance is obtained by getDC or BeginPainTDE, if there is no other window to need this DC, it is not necessary to call ReleaseDC or EndPaint Release DC. On a window instance, get DC through getWindowdc, getdc, getdcex, beginpaint, and change some of these parameters, the changes are made in addition to all other window instances in addition to the shear area and device itself (Device Origin). It is vaild. As with CS_OWNDC, it is necessary to ensure that the image mode is also mm_text, otherwise, the background being erased by the system will no longer be visible.
The program written for NT is best not to use this flag, because the benefits of "savings" are not obvious. For Win9x, it is useful because of the Savoring space significance for Win9X's 64K GDI.
If you use a CS_ParentDC flag, you belong to this class using the handle of its parent window. Similar to the CS_CLASSDC, multiple windows share a DC, which is different, which is not required to belong to the same window class in this multiple windows (although there is a parent and child relationship and sharing DC).
Under Win9x, all standard window controls have a cs_parentdc flag. Under WinNT, there is this sign in addition to the window control other than ComboBox. Therefore, such as the EDIT control and ListBox controls share their parent windows (such as dialog box) DC
(Note: This section is that I add my own understanding according to the original text, not necessarily the right :) The benefits of cs_parentdc bring a word: Speed. The Win9x system reserved 5 DC buffers for each thread. If a window (such as a dialog) is more than 5 words, such as 6 or more edit boxes, each sub-window has If your DC, the DC buffer has lost its effectiveness, and the system has to reinitialize a DC according to the shear boundary and device attribute, which is not stopped in the DC buffer, which cannot be ensured in the buffer. I was accessed. And if each sub-window is shared with the parent window, when the DC is frequently accessed frequently, the DC is that the chance to find in the DC buffer is clearly high, so that it can be accessed by high speed, which has improved the speed, so it is general For standard window controls, share DCs with the parent window. Winnt can have more than 5 DC buffers, so it may provide sufficient DC buffer - but is not guaranteed.
Another effect using CS_ParentDC is that the sub-window can be painted freely in the customer area of the parent window, just like painting in your own client area. The CTL3D library responsible for expressing the 3D effect around the EDIT control and ListBox control is to use this feature. . Note If the program needs to change the image of each sub-window, it is best not to use the CS_ParentDC flag, otherwise it will easily cause confusion of the seed window image mode because all sub-windows use the same DC. If you do not specify CS_OWNDC, CS_CLASSDC, or CS_PARENTDC these flags, such windows use a general DC and placed in DC buffer for use. The general DC is acquired before use. When the use is released, the context in the DC is initialized by the default value, unless the DC is already in the DC buffer in the window (such as no call ReleaseDC or Endpaint release DC). The cut boundaries and device properties of the DC need not need to be re-test, which can save some time.
In WinNT, the DC buffer has no determination. If all DC buffers are in use, the program calls GETDC and BeginPaint, and NT is allocated a buffer.
For Win9X compatibility, Win32 programs are best limited to 5 or less, and release DC as quickly as possible.
If you want to ignore the default DC of the window determined by the flag when you created, the program can use the getDCEX function, specify the DCX_CACHE flag, completely ignore the CS_OWNDC and CS_CLASSDC flags and return a general DC from the buffer.
ScrollWindow and SCROLLWINDOWEX functions have different ways to process DC:
ScrollWindow uses the default DC default DC. Therefore, if the window uses the CS_OWNDC or CS_CLASSDC flag, ScrollWindow uses the corresponding DC (window private DC or class DC, which is likely to be changed by the program, not mm_text). The coordinate value that passes to the scrollwindow must be used as the DC. Consistent. ScrollWindowEx uses system universal DC (this DC uses mm_text ", and ignores the flag of the window. The coordinate value passed to ScrollWindowEx must be a client zone coordinate value in mm_text image.
CS_DBLCLKS
The CS_DBLCLKS flag enables the window to detect double-click event. The details of the window responded are as follows:
If the window does not have a CS_DBLCLKS flag, the system sends the following message to the window:
WM_LBUTTONDOWN
WM_LBUTTONUP WM_LBUTTONDOWN WM_LBUTTONUP.
In fact, it is equivalent to two clicks.
If the window has a CS_DBLCLKS flag, the system sends the following message to the window:
WM_LBUTTONDOWN
WM_LBUTTONUP WM_LBUTTONDBLCLK WM_LBUTTONUP.
The second WM_LBUTTONDOWN in the first case is replaced by WM_LBUTTONDBLCLK.
Note that other one or some messages may be inserted in the middle of the sequence described above, so the two message sequences are not necessarily completely continuous.
In fact, when there is no CS_DBLCLKS flag, the program itself can also detect double-click event. See "Simulating Mouse Button ClickS" article in msdn Dr.Gut, but there are some techniques. In general, if you do not specify CS_DBLCLKs, WM_LBUTTONDBLCLK messages will not be obtained in the window of the window.
All standard window controls, dialogs, and desktop window classes have a CS_DBLCLKS flag. The third-party control is preferably added to this style to make it working properly in the dialog editor. CS_GLOBALCLASS
CS_GLOBALCLASS is the only sign that acts for the class itself instead of a single window. The system will contain such a flag as an application global class, so that the categories can be applied to all EXEs in the process of such class and DLL, when EXE or DLL exits or uninstall, or then call UnregisterClass to this class, this class is destroyed. All windows created from that class must be turned off before registering the program that is registered.
CS_HREDRAW, CS_VREDRAW
The CS_HREDRAW flag indicates that the entire window is heard when the horizontal dimension (width) of the window changes. CS_VREDRAW is a heavy blow to the entire window when the window is changed (height). Buttons and scroll bars have these two styles.
CS_noClose
If the CS_noclose flag is specified, the shutdown button on the window and the closing command on the system menu are invalid.
CS_SAVEBITS
Menu, dialog, drop-down boxes have a CS_SAVEBITS logo. When the window uses this flag, the system saves a window image of the window cover (or gray) in a bitmap. First, the system requires that the drive save image bit data is displayed. If the storage space of the drive itself is sufficient, the save operation is successful, and the Window system can also use these saved bit data. If not enough, the system saves bit data in a bitmap in the global memory, and assigns space for each window in the USE module, saving some transaction data (such as bitmap data buffering size). When the program disappears when the program disappears, the system can quickly recover the screen image from the memory.
The efficiency of CS_SAVEBITS is it difficult. CS_SAVEBITS improves the "temporary" window such as menus, dialogs, and drop-down frame performance. However, the overhead of the storage bit information is also very clear, especially when the system replaces the drive storage bit information, the system undertakes speed and storage overhead. The advantage of using CS_SAVEBITS is actually what happened to the area where the window covered. If the area is quite complex, you need to call a lot of effect, then store the area to be easier than you have to come, if it is, the area can Quite fast redraw, or often changes in the occlusion and vary significantly, the preserved solution has affected the overall performance.
The above is the optional flag of Style members.
The window procedure (lpfnwndproc)
The LPFNWndProc member in the WNDClass structure saves the window process address of the window class. All windows of the window class use the process address, for the window created from the class, the system handles all relevant messages to this window process. The window process implements the window's function, and the program can use the setClasslong function to change the window process of the window class. This operation is "subcatenation" (SUBCLASSIN). When the program changes the address of the process, the window that has been created before changing the original address, and the window created later uses the new process address.
When a program or DLL subclass is a window or setting window process function, the new window process must be output in the module definition file.
Extra class and window bytes (cbclsextra and cbwndextra)
CBCLSextra members indicate the amount of additional data for each window class, and the CBWndextra member is an additional amount of data assigned to each window instance. If the program does not need to allocate additional data, the values of these two members should be set to 0, so as to avoid uncertain numbers (such as a very large number) and make the system error allocation, if it is a negative number, the window class Will not be registered. In Win9x and NT, allocate 40 and below bytes, of course, developers can allocate additional data size as needed.
If you use a class declaration and register a dialog type window, the value of CbWndextra must be set to DLGWindowextra, and the system dialog manager requires so many additional data to manage the dialog.
Instance Handle (Hinstance)
Wndclass's Hinstance member identifies the module where the class is located. This member can be a process of Hinstance, or a DLL Hinstance, but it is not NULL.
Class icon (HICON)
WNDCLASS's HICON member identifies the icon of this window class. The program generally uses Loadicon, from the system standard icon library (such as idi_application) or user-specified icon resource to get an icon handle. If the value of the Hicon is NULL, the program gives the program's main icon when the system sends a WM_ICONERASEBKGND message.
Class Cursor (HCURSOR)
The HCursor member in Wndclass is a default mouse pointer belonging to this class window. When this value is set, when the mouse is moved in the window area, the system will make a pointer by the system default shape into the set pointer shape. Programs can get pointer sections from standard system pointer libraries (such as IDC_ARROW) or user specify pointer resources using the LoadCursor function. The program can change the pointer at any time via the setcursor function. If the value of HCursor is not set (set to null), the program must be set when the mouse pointer is moved into the window, otherwise the system default mouse pointer shape will be used.
Class Background Brush (HBRBACKGROUND)
The HBRBACKGROUND member variable in Wndclass represents the background color, the type HBrush, the GDI brush handle. It can be assigned to a brush handle (such as the system's built-in brush object handle, or the handle of the brush of the specified color and style) or the color value. If it is a color value to select a color value, you must use one of the following system standard colors.
COLOR_ACTIVEBORDER COLOR_HIGHLIGHTTEXT COLOR_ACTIVECAPTION COLOR_INACTIVEBORDER COLOR_APPWORKSPACE COLOR_INACTIVECAPTION COLOR_BACKGROUND COLOR_INACTIVECAPTIONTEXT COLOR_BTNFACE COLOR_MENU COLOR_BTNSHADOW COLOR_MENUTEXT COLOR_BTNTEXT COLOR_SCROLLBAR COLOR_CAPTIONTEXT COLOR_WINDOW COLOR_GRAYTEXT COLOR_WINDOWFRAME COLOR_HIGHLIGHT COLOR_WINDOWTEXT
When assigning a color value, it must be forced to convert to HBrush type: CLS.HBRBACKGROUND = (HBRUSH) (color_window 1);
If the HBRBackground member is set to NULL, the program must be responsible for painting on the response WM_PAINT. The program can also respond to the WM_ERASEBKGND message or determine if the value of the member ferease of the member feed in the PAINTSTRUCT structure fills when the BeginPaint function is called. Class Menu (LPSz GeneNuname)
The LPSzMenuname member in Wndclass represents the default main menu. You can use the MakeintResource macros to convert the ID number of the resource menu item into a continuous string value to assign it. If you use the CREATEWINDOW or CREATEWINDOWEX function to create a window from this class, you do not specify another menu resource in the function parameter, then the main menu appearing on each window is the menu specified by lpszMenuname. If LPSZMENUNAME is NULL, the window does not have the default main menu.
Class name (LPSZCLASSNAME)
The lpszclassname structure in Wndclass represents the name of the class. The local window class name must be unique in the process range, since only "unique in the process", for two different programs, where the window class names may be the same, for example, both programs may have their own "Main wnd" window. The name of the global window class must be unique in the global window class and system window type, for example, the program can register a local window class "edit", but it is not possible to register a global window class with the same name.
How to locate window classes
When the program needs to create a window according to a class, the system is positioned by the following steps.
1. The system is looking for classes with the same name in the local window class list of this process. If found, since the local window class belongs to a .exe module or DLL, the process instance handle (Hinstance) and the instance of this module should be consistent. Such a rule is to prevent the partial class or DLL discovery of a module or DLL in the process within the process.
2. If the system cannot find a local class of the same name, then the global class list of the search process is continuing, this search is not compared to the unique edition handle.
In Win9x, if you cannot find the same name class in the program full class space, continue to query the list of system window classes in the process.
If the system is still unable to find the same name window class, continue to search for a global system class list.
Winnt applies this process to all windows created by the program, including other windows created from the main window, such as dialogs, and messages.
Win9x also applies this process to all windows, except for the message box. When the program pops up, Win9x does not search for the local class list, but directly subsequent steps.
How to use window information for four applications.
Once a class is registered, in general, there is no thing that needs to be done in addition to using this class created a window. Of course, if you need to access this type of information, subcatenarization, or hypersanization, introduce some methods is useful.
Class Access Function
If you need to get and change the information, you can use the following functions:
GetClasslong, read from class information (for example, window processing address of window class) setClasslong writes a member of the class to a LONG type. For example, write the address of a new window process. GetClassWord reads back from class information to a word type value. For example, the amount of additional data is obtained:
Nclassextra = getClassword (hwnd, gcw_cbclsextra);
SetClassWord writes a value of a Word type to class information. For example, changing the window class icon.
GetClassName Gets the name of the window class. GetClassInfo gets all kinds of information other than class names and menus.
Specific call parameters and other related class functions can be found in the Windows Class Functions section in MSDN. Subclass: (SUBCLASSING)
The term "subcatenation" is described in replacing the original window process with a new window process. The term "instance form class" (ie, single window) refers to a window process that changes a window instance using the setwindowlong function. "Global Subcarization" (subclass of the entire window) refers to the use of setClasslong to change the default window process function of the entire class.
In the 32-bit Windows system, it may be difficult to get the window or window classes in another process. In general, the subclasses are happening in the same process ("breaking process boundary" related topics do not Involved).
Supercanization: (SuperClassing)
The term "superclassing" means a new class that uses an existing class window process, inherits the basic functions of the class, and can be extended on this basis.
For specific descriptions of subclassification and supercolarization, please refer to "Safe Subclasing In Win32" in MSDN
Conclusion: Win32 window classes bring a lot of useful information to developers, develop programs on the Win32 platform, it is best to pay attention to use some features compatible with WinNT and Win9x to ensure compatibility of the program.
