How to create a Notepad clone in Win32 for novice and intermediate Windows programmers - platform SDK independent, no code, just the theory, so also good for Vista.
This article is designed as a tutorial to help beginner and intermediate programmers become proficient with some basic Windows programming techniques. There is no code in order to keep the article platform and language neutral. This way, it should be equally applicable to Win32, Vista and even Win16 development. The following key Windows features are explored:
The Windows programming information gives enough information, along with other tutorials on this site, to create a simple Notepad style text editor.
The child window controls are one of the innovations that Microsoft provided Windows programmers over the original DOS environment. Although other GUI programmers had enjoyed the luxury of widgets and other programmable user interface objects, the PC was still tied to the separation between text and graphics mode. With the release of Windows, and in particular Win32, programmers were given a rich set of widgets to include in their applications - of which one is the Edit control.
So, the first task, when processing the WM_CREATE message, is to create the edit area, with a single call to CreateWindow, using the "edit" class in the first parameter. The remaining parameters can be defaults, but the reader might like to experiment with various combinations of WS_ and ES_ styles. The minimum will be:
We also want to be able to tie the size of the window to the client are of the parent. Subsequently, we can create the window with a position of 0,0 and size of 0x0. Then, when we process the WM_SIZE message of the parent, we can call:
Using this method, we can ensure that the edit control always fills the client area. First we call GetClientRect to determine the appropriate size, and MoveWindow to resize the edit control.
Menus are usually defined in the resource script. They are processed by handling the WM_COMMAND message sent to the parent window. We need to ensure that the standard Windows menu look and feel is respected, so we create a menu 'File', with the following children:
We should also add a 'Help' top level item to the menu, with the following child:
Each of these should, when defined, follow the accepted Windows standards, by hilighting the appropriate letter for use as an Alt-<key> combination. An example from a real resource script might be:
The ampersand sign shows Windows which letter to underline, and subsequently use as a shortcut rather than requiring the user to click with the mouse.
Since we have a file save and load option in the menu, we need to be able to read and write to text files. This is very easily managed : the Windows API provides plenty of file handling functions. However, novices will be happy to learn that the standard C file handling also works. For those wanting to use the API itself, the functions to look for are:
These functions allow for any kind of file to be handled, from mailslots to pipes, and are necessarily more complex than the standard C libraries.
To retrieve text from the edit control, we can use the functions:
The difference between them is that the GetWindowText fucntion requires a window handle, and GetDlgItemText requires the parent window handle and the ID of the edit box. In either case, if we want to determine the amount of text beforehand, we need to use the GetWindowTextLength function, which requires a window handle. So, it might be better to use that form for both calls; luckily we can obtain the handle using the function:
This takes the parent window and child ID and returns the handle that we can then supply to GetWindowText or GetWindowTextLength. The sister function, SetWindowText, can be used to set the text.
Finally, we should allow for two kinds of dialog box - a message box (when we need to tell the user something), and an About box. An example of the message box might be to alert the user that something they are about to do might cause loss of information. For example, exiting without saving the file. It can be set up to return a value according to whether the user has clicked a specific button, and so can be used to ask a question.
The About box is more complex. The programmer has to actually implement it in the resource script, and provide a message processing function to handle interaction with the user. While the About box is open, the messages for the application are all passed to that function, rather than the main application. Most Windows applications have a dialog box, opened with a call to the API function:
This function requires the name of the dialog box resource (from the resource script), the parent window and application instance, as well as the pointer to the function that will handle the messages; often known as the DlgProc or Dialog Procedure.
The above can be used as a blueprint for virtually any kind of application. They will usually all need a menu (following conventions), some interaction with the user, dialog boxes and file handling.