Geoff Chappell - Software Analyst
VOID InitCommonControls (VOID);
The function itself does nothing in any known COMCTL32 version.
Nor, it turns out, does this function itself do anything even in the 16-bit COMMCTRL.DLL from Windows for Workgroups 3.11. If the ordinal numbering of functions in that release is credible as a chronological record of development, then some inferences seem plausible. The common controls were first designed such that each has its own exported function for creating the control. See in particular CreateStatusWindow (ordinal 6), CreateToolbar (ordinal 7) and CreateUpDownControl (ordinal 16). This design may have been thought unwieldy as new controls were developed, prompting the present scheme in which COMMCTRL registers window classes and leaves each client to create each control directly as a window with a known class name. Though the window classes can be registered automatically as COMMCTRL initialises, this scheme has the problem that the client must do something to ask that COMMCTRL be loaded. A client who wants COMMCTRL only for its common controls might have no COMMCTRL functions to call. The scheme works for all only if every client is instructed to load the common controls library explicitly or is given a function to call (or reference to import), even if the function is implemented trivially.
This 16-bit history persists for COMCTL32, such that InitCommonControls (ordinal 17) is a dummy function provided as sufficient means for ensuring that COMCTL32 gets loaded, and thence that the window classes for the common controls get registered. Calling this dummy function is unnecessary in practice, though not for conforming to the design, if any other COMCTL32 function is imported. For the indirect purpose of ensuring that COMCTL32 gets loaded, it works just as well to import the function’s address as data or to load COMCTL32 explicitly by calling LoadLibrary.
In recent versions, InitCommonControls cannot safely be relied on as an indirect means of registering the window classes for any controls. Versions 5.82 and higher vary signficantly in their choice of common controls whose window classes get registered automatically at process attachment. In the following summary, the controls that get registered during initialisation are described in terms of the applicable InitCommonControlsEx flags.
|up to and including 5.81||ICC_WIN95_CLASSES (0xFF)|
|5.82 from Windows XP||all documented controls (0x3FFF)|
|5.82 from Windows Server 2003 and higher||if running in 16-bit process||ICC_WIN95_CLASSES (0xFF)|
|6.0 from Windows XP||all documented controls (0xFFFF)|
|6.0 from Windows Server 2003, and higher||if running in 16-bit process||all documented controls (0xBFFF) except ICC_STANDARD_CLASSES|
Note in particular that some of the later versions do not register any window classes unless executing for a 16-bit process.
The InitCommonControls function is exported by name from COMCTL32.DLL in all known versions (3.50 and higher). It is reliably exported as ordinal 17.
This function has always been documented, though not always as being trivial.