AppWizard and More in MFC - Messages and the Properties Window (Page 3 of 4 )
The beauty of using the AppWizard for creating the application is that it will grant you access to the override messages option. Back in the old days, a separate wizard named ClassWizard that could be called quickly with the Ctrl+W keyboard combination existed for this. If you are using a version of Visual Studio prior to the .NET platform, then this still exists.
This option disappeared with the appearance of the .NET platform, and it was implemented in the properties tab of each class. But don’t think that the same thing can’t be done with each of them; it's just that they are located in different places. So the following part is useful for both kinds of users.
However, I will only present the .NET version because this is more popular. Now that we created the application, all that remains for us to do is to modify where it’s appropriate. No need to write unnecessary code; heck, we only modify the part that we want to change or which message we want to respond to.
In the previous part, I told you about the message list that we must declare and overwrite later, so here it is in real life. First, you must know that every part you see on the screen has its own class. Everything is derived from a class and has the ability to individually manage its own message list and decide what will be done with the incoming messages.
For example, if you create a dialog box, this will be derived from the CDialog class and it will have all the functions of a CDialog. All you need to do is extend it with the specific new functions that differentiate your Dialog box from an average one defined in the MFC libraries. The story is the same if you decide to split the views. To accomplish this, you create two individual classes from the CView class and by default it inherits the properties of a view. The individualization task remains the only task for you to do.
A view area or the dialog bar manages the messages on its own. Now when we want to modify the answer to one of the messages, we start by declaring that function in a message map. This way, in the future, at the occurrence of the message, the Dialog box’s message handler is going to know that near the standard tasks, some extra job has to be done. The message map is declared in the header file of each class; it should look something like this:
DECLARE_MESSAGE_MAP()
This will be followed by the declaration of the message map.
Next: Messages and the Properties Window continued >>
More BrainDump Articles
More By Gabor Bernat
