Theory:
WIN95 has several enhanced user interface controls relative to the win3x. In fact, these controls are in use before the WIN95 is officially released, such as: status bar, tool bar, etc. Programmers used to program them themselves, and now Microsoft has included them in Win9x and Winnt.
Toolbar---tool bar
TOOLTIP---hint text
Status Bar---State bar
Property sheet---Properties page list
Property Page---Properties sheet
Tree view---TreeView
List View---listing views
Animation---Animation
Drag List---can handle drag-drop listbox
Header---
Hot-key---Hotkey
Image list---image linked list
Progress Bar---process status bar
Right Edit---
Tab---Table of tabs
TRACKBAR---tracking bar
Up-down---scroll bar
Because the number of common controls is very large, it is wasteful to load them all into memory and register them. The executable code for other controls except the rich text editing control is placed in Comctl32.dll so that other applications can use them. The rich text editing control is also larger than other controls in RichedXX.dll because the control is very complex.
To load Comctl32.dll, you can call function InitCommonControls in your application. The InitCommonControls function is a function in a dynamic-link library comctl32.dll that, if referenced anywhere in your program, causes the Windows program Loader PE loader to load the library. The function InitCommonControls actually has only one instruction "ret", its sole purpose is to make the "introduce" in the PE header of the executable file of the application that called the function. The section contains Comctl32.dll so that whenever the application loads the library for you. So the real initialization work is done at the entry point of the library, where all the generic control classes are registered, and then all the generic controls can be created on these classes, just like creating other child window controls.
Rich text editing controls are different. If you want to use it, you must call the LoadLibrary function to load dynamically, and call FreeLibrary to unload dynamically.
Now we learn how to create these generic controls. You can use the resource editor to put them in a dialog box, or you can call the related functions yourself to create them manually. Almost all common controls are created by calling function CreateWindowEx or CreateWindow, where you pass the generic control's class name. There are some common controls that have special creation functions, but in fact these functions call CreateWindowEx in the interior, but the wrapped function is easier to use. The packaged functions are:
Createtoolbarex
Createstatuswindow
Createpropertysheetpage
PropertySheet
Imagelist_create
In order to create common controls you must know their class name, we rank the class in the following:
Class name Generic control
ToolbarWindow32 Toolbar
Tooltips_class32 Tooltip
Msctls_statusbar32 Status Bar
SysTreeView32 tree view
SysListView32 List View
SysAnimate32 Animation
SysHeader32 Header
Msctls_hotkey32 Hot-key
Msctls_progress32 Progress Bar
RichEdit Rich Edit
Msctls_updown32 Up-down
SysTabControl32 Tab
The property sheets, property pages, and image list controls have their own creation functions. The Drag list is actually a scalable listbox control, so it doesn't have its own class name. The class name above is provided by the VC + + resource Editor, and they are not the same as those presented in the Borland Company's WIN32 API guide, and Petzold's book programming Windows 95. To be sure, the class names listed above are absolutely accurate. These generic controls can have some style of common window classes, such as Ws_child. They certainly have other special styles, such as the tree view control has a tvs_xxxxx style, the list control has a lvs_xxxx style. The best way to find out about the WIN32 API function guide. Now that we know how to create a generic control, we can talk about how these common controls communicate with each other and with their parent windows. Unlike child window controls, common controls send wm_notify messages and parent windows when some state changes rather than by sending Wm_command. The parent window can control the behavior of the child window by sending a message. For those new generic controls, there are new message types. You can refer to your WIN32 API manual.
In the following example, we will experiment with the progress bar and the status bar.
Example code:
.386
. Model Flat,stdcall
Option Casemap:none
Include \masm32\include\windows.inc
Include \masm32\include\user32.inc
Include \masm32\include\kernel32.inc
Include \masm32\include\comctl32.inc
Includelib \masm32\lib\comctl32.lib
Includelib \masm32\lib\user32.lib
Includelib \masm32\lib\kernel32.lib
WinMain PROTO:D Word,:D Word,:D Word,:D Word
. const
idc_progress equ 1; Control IDs
Idc_status equ 2
Idc_timer equ 3
. Data
ClassName db "Commoncontrolwinclass", 0
AppName db "Common control Demo", 0
Progressclass db "Msctls_progress32", 0; The class name of the progress bar
Message db "finished!", 0
Timerid DD 0
. Data?
HINSTANCE hinstance?
Hwndprogress DD?
Hwndstatus DD?
Currentstep DD?
. Code
Start
Invoke GetModuleHandle, NULL
MOV hinstance,eax
Invoke WinMain, Hinstance,null,null, Sw_showdefault
Invoke Exitprocess,eax
Invoke InitCommonControls
WinMain proc Hinst:hinstance,hprevinst:hinstance,cmdline:lpstr,cmdshow:dword
Local Wc:wndclassex
Local msg:msg
Local Hwnd:hwnd
MOV wc.cbsize,sizeof wndclassex
mov wc.style, cs_hredraw or Cs_vredraw
mov wc.lpfnwndproc, OFFSET WndProc
MOV wc.cbclsextra,null
MOV wc.cbwndextra,null
Push Hinst
Pop wc.hinstance
MOV wc.hbrbackground,color_appworkspace
MOV wc.lpszmenuname,null
MOV Wc.lpszclassname,offset ClassName
Invoke Loadicon,null,idi_application
MOV wc.hicon,eax
MOV wc.hiconsm,eax