As we saw before, writing all that code for a simple dialog is quite a lot of work. It is important that you know what is going on, however. But now we can see how we can make Wedit generate the code for us.
The code generator is not enabled by default. You have to do it by choosing the "Output" item in the resources menu. This leads to an impressing looking box like this:
This dialog shows you the files that will be generated or used by Wedit. Those that will be generated have a box at the right, to enable or disab 959i83j le their generation. The others are used if available, but only for reading. The last item is an additional path to look for bitmaps, icons and other stuff that goes into resources.
You notice that the first item is disabled. You enable it, and type the full path of a file where you want Wedit to write the dialog procedures. Notice that by default, the name of this file is <name of the project>.c. This could provoke that your winexample.c that we worked so hard to write, could be overwritten. Choose another name like "dialogs.c" for instance.
Now, when you save your work, all the dialog procedures will be written for you. But before, we have to tell the framework several things.
The first will be the prefix to use for all the procedures that will be used in this dialog box. We define this in the main properties dialog box obtained when you double click in the dialog title. At the bottom of that dialog, we find:
"Dlg400" is an automatic generated name, not very convincing. We can put in there a more meaningful name like "DlgSearch" for instance. We will see shortly where this name is used.
What we want to do now is to specify to the editor where are the events that interest us. For each of those events we will specify a callback procedure that the code generated by the editor will call when the event arrives. Basically all frameworks, no matter how sophisticated, boil down to that: a quick way of specifying where are the events that you want to attach some code to.
The events we can choose from are in the properties dialog boxes, associated with each element of the dialog box. You have the general settings for the dialog, associated with the dialog box that appears when you double click in the title, and you have the buttons properties that appear when you double click in a button.
Those dialog boxes have generally a standard or "static" part that allows you to change things like the element's text, or other simple properties, and a part that is visible only when you have selected the C code generation. That part is normally labeled "messages" and appears at the bottom. That label tells us which kind of events the framework supports: window messages. There are many events that can possibly happen of course, but the framework handles only those.
We see at the bottom a typical "messages" part: We have some buttons to choose the messages we want to handle, the function name prefix we want for all callback procedures for this element, and other things like the font we want to use when the elements are displayed.
We see again that "Dlg400". but this allows us to explain how those names are generated actually. The names of the generated functions are built from the prefix of the dialog box, then the prefix for the element, and then a fixed part that corresponds to the event name. We edit the prefix again, following this convention.
The "Selected" message is on, so the framework will generate a call to a function called DlgSearchOnOkSeelected().Happily for us, we do not have to type those names ourselves.
Without changing anything else we close the button properties and save our work. We open the c source file generated by the editor.
We obtain the following text:
/* Wedit Res Info */
#ifndef __windows_h
#include <windows.h>
#endif
#include "winexampleres.h"
BOOL APIENTRY DlgSearch(HWND hwnd,UINT msg,WPARAM wParam,LPARAM lParam)
break;
}
return(HandleDefaultMessages(hwnd,msg,wParam,lParam));
We have here a normal callback procedure for our dialog. It handles two messages: WM_INITDIALOG and WM_COMMAND. The callback procedures are in bold type. There are two of them: The initialization callback called "DlgSearchInit", and the one we attached to the OK button above, "DlgSearchOnOkSelected".
There are more things in there, but for the time being we are interested in just those ones, because they have to be written by you!
What you want to do when the dialog box has been created but it is not yet visible?
This is the purpose of the first callback. In our text search dialog we could write in the edit field the last searched word, for instance, to avoid retyping. Or we could fill a combo box with all the words the user has searched since the application started, or whatever. Important is that you remember that in that function all initializations for this dialog box should be done, including memory allocation, populating list boxes, checking check buttons or other chores.
The second callback will be called when the user presses the OK button. What do you want to do when this event happens? In our example we would of course start the search, or setup a set of results so that the procedure that called us will know the text to search for, and possibly other data.
Different controls will react to different events. You may want to handle some of them. For instance you may want to handle the event when the user presses a key in an edit field, to check input. You can use the framework to generate the code that will trap that event for you, and concentrate in a procedure that handles that event.
How would you do this?
You open the properties dialog of the edit control and check the "Update" message. This will prompt the editor to generate a call to a function of yours that will handle the event. The details are described in the documentation of the resource editor and will not be repeated here. What is important to retain are the general principles at work here. The rest is a matter of reading the docs, to find out which events you can handle for each object in the dialog, and writing the called functions with the help of the windows documentation.
But what happens if there is an event that is not foreseen by the framework? With most frameworks this is quite a problem, happily not here. You have just to check the button "All" in the dialog properties and the framework will generate a call to a default procedure (named <prefix>Default) at each message. There you can handle all events that the operating system sends. I have tried to keep the framework open so that unforeseen events can be still treated correctly.
Another way to customize the framework is to modify the default procedure provided in the library weditres.lib. The source of that procedure is distributed in the source distributions of lcc-win32 and is relatively easy to modify.
|
