Initialization of MFC common controls

This is a problem I accidentally thought of when I read a source code, I did some research and now I'm posting the results to help people who are interested.

InitCommonControls和InitCommonControlsEx

Starting with Win95, Windows provides a number of new Win32 controls, called generic controls. such as: Toolbar,status bar,tree view,list view,animation,hot-key,image list,tab and so on. The executable code for these controls is placed in the Comctl32.dll. To use a generic control, Comctl32.dll must be loaded.

You can call the function InitCommonControls or initcommoncontrolsex to initialize the control. Both functions are functions in the dynamic-link library Comctl32.dll, and the two functions are the following prototypes:

void InitCommonControls(VOID);
BOOL InitCommonControlsEx(LPINITCOMMONCONTROLSEX lpInitCtrls);

As you can see, InitCommonControls has no arguments to initialize all (actually most, see below) generic controls. And Initcommoncontrolsex can specify what controls to initialize.

The meaning of "initialization" here is explicit, which means registering the corresponding window class. For example, you can create a window for the control only if you register the SysTreeView32 window class beforehand.

Note that the Registration window class is valid only for the current process, because you must specify a window address when registering, and the address is valid only for a single process. Therefore, each process must be initialized before the generic control can be used.

The function initcommoncontrols is an empty function and does nothing. But if you call the function, the linker will link your program to comcl32.lib and then load the Comctl32.dll when the program starts. The real initialization work is done at the entry point of the library, where the generic control window class is registered, and then the application can create the control window just as you would create other child window controls.

Initcommoncontrolsex is a function that actually registers the control window class. It determines which control's registration code is invoked based on the content class of the parameter LPINITCTRLS->DWICC. The associated values are as follows:

#define Icc_listview_classes 0x00000001//LISTVIEW, header
#define Icc_treeview_classes 0x00000002// TreeView, ToolTips
#define Icc_bar_classes 0x00000004//toolbar, StatusBar, TrackBar, tooltips
#define Icc_tab_c lasses 0x00000008//tab, tooltips
#define ICC_UPDOWN_CLASS 0x00000010//updown
#define Icc_progress_class 0x0000 0020//Progress
#define ICC_HOTKEY_CLASS 0x00000040//HOTKEY
#define ICC_ANIMATE_CLASS 0x00000080//ANIMATE
#define Icc_win95_classes 0x000000ff
#define Icc_date_classes 0x00000100//month picker, DATE picker, Time picker, u Pdown
#define Icc_userex_classes 0x00000200//comboex
#define Icc_cool_classes 0x00000400//Rebar (COOLBAR) cont Rol
#define Icc_internet_classes 0x00000800
#define ICC_PAGESCROLLER_CLASS 0x00001000//page scroller
# Define Icc_nativefntctl_class 0x00002000//native font control

Note that icc_win95_classes equals all previous values or, so using the tag to invoke Initcommoncontrolsex initializes controls such as Listview,header,treeview.

When the process first loads the DLL, the system invokes the DllMain with the Dll_process_attach parameter. In Dynamic library Comctl32.dll, the initcommoncontrolsex is invoked at this time with the icc_win95_classes tag, so once the process has loaded Comctl32.dll, a series of common controls are registered.

When the process unloads the DLL for the last time, the system invokes the DllMain with the Dll_process_detach parameter. In the dynamic library Comctl32.dll, the call Unregisterclass cancels all the generic control window classes that have been registered at this time.

Attention:

For Windows 95/98/me, when a DLL is unloaded, all of the window classes registered in it are automatically unregistered. This is done automatically and does not require you to write down the Unregisterclass calling code.

For Windows NT/2000/XP, when a DLL is unloaded, the window class that is registered in the DLL is not automatically unregistered, so the unregisterclass must be called artificially in code in DllMain. Otherwise, once the DLL is unloaded and the control is created again (because the system thinks the window class is still valid because there is no registration), the control's window procedure points to an invalid address.