Solve the problem that the list control program cannot be run by adding a list control program to the Win32 SDK program.

Problem description:

The Win32 SDK is used for programming. The dialogbox () function is used in the main window. After the list control Control is added to the window,ProgramExit as soon as you run the command. After the list control Control is deleted, the program can run normally.

Solution Process:
Debugging found that after list control is added to the dialog box, the returned value of dialogbox is-1, while the returned value of getlasterror () is 0, and a breakpoint is added to the message processing function of the dialog box, after dialogbox () is called, the message loop is displayed. After the list control is deleted, the program runs normally. Why? Alas, in distress ......

Solution:

Add initcommoncontrols () before the dialogbox () function. Do not forget to add # include <commctrl. h>!

Knowledge extension:

Because public controls are separated from the core of the operating system, you must initialize the DLL containing public controls before using any public controls. In all Windows versions, including Windows CE, you can call void initcommoncontrols (void) to load the dynamic library and register many public control classes. This call does not initialize the calendar control, Time Selection control, up/down control, IP address control, and other public control updates. To initialize these controls, use the bool initcommoncontrolsex (lpinitcommoncontrolsex lpinitctrls) function, which allows the application to load and initialize only selected public controls. This function is easy to obtain in Windows CE, because loading only the required controls can reduce the impact on memory. The unique parameter of this function is a structure containing two fields. This structure has a dimension field and a field containing the flag set. The flag set is used to indicate which public controls need to be registered. The following table shows the available labels and corresponding controls.
The identifier of a public control.

Flag	Control classes initialized
Icc_bar_classes	Toolbar
	Status Bar
	Trackbar
	Command bar
Icc_cool_classes	Rebar
Icc_date_classes	Date and Time picker Month calendar Control
Icc_listview_classeS	List View Header Control
Icc_progress_class	Progress bar Control
Icc_tab_classes	Tab Control
Icc_treeview_classes	Tree View Control
Icc_updown_class	Up-down control
Icc_tooltip_classes	Tool tip Control
Icc_capedit_class	Cap Edit Control

Once the public control DLL is initialized, these public controls can be treated like any other controls. Each widget has a customizable style flag set to configure the widget's appearance and behavior. Messages sent to each control are used to configure and manipulate the control and allow the control to execute certain actions. One major difference between standard Windows controls and public controls is that event notifications or service requests are sent through wm_notify messages, while standard controls are sent through wm_command messages. This technology allows a notification to contain more information than a notification sent using a wm_command message. In addition, this technology allows each control that uses this notification to expand and adapt wm_notify messages.

The wm_notify message carries a pointer to the nmhdr structure in the lparam parameter. The definition of nmhdr is as follows:
Typedef struct tagnmhdr {
Hwnd hwndfrom;
Uint idfrom;
Uint code;
} Nmhdr;

Hwndfrom is the window handle for sending notification messages. The property page is the property page window. If the control sends a notification, idfrom is the Control ID. The last code field contains the notification code. Compared with wm_command messages, although this basic structure does not contain any more information, it is almost always scalable and can be extended using an additional domain. The notification code indicates what additional domains are appended to the notification structure.

Another difference in public control programming is that most of the messages sent to the public control related to the control have predefined macros. These macros are used to send messages, which looks like the application is calling functions. Therefore, you do not need to use the lvm_insertitem message as follows to insert an item to the List control, as shown in
Nindex = (INT) sendmessage (hwndlv, lvm_insertitem, 0, (lparam) & LVI );
Instead, you can easily use nindex = listview_insertitem (hwndlv, & LVI.

There is no functional difference between the two statements. It is clear to use the macro advantages. Macros and definitions required in other public control programming are located in commctrl. h. One problem with using these macros is that the compiler cannot perform type checks on the parameters. If the macros are real functions, they should be executed. This problem also exists in sendmessage technology. In sendmessage mode, parameters must be of the wparam and lparam types, but Message Type check is also common. In general, macro routines provide better readability. An exception to the macro system is when macro calls are performed in the command bar control and command Belt control. In addition to a large number of macro-encapsulated messages, there are actually many real functions in these controls. Generally, the messages I call are real messages, not their corresponding macros. This will help distinguish messages or macros from real functions.

References:

<Programming Microsoft Windows CE. net, Third Edition>Douglas boling