Welcome back, my friend. This time we’re going to take an in-depth look at two of the most used tools that are integrated into Visual Studio. They make the life of an MFC programmer or developer much happier and easier. You are reading the second segment of this five-part article series presenting the MFC.
Contributed by Gabor Bernat Rating: / 3 March 05, 2008
First we will take a journey into the world of AppWizard. Every part of it will be clear to you as soon as you reach the end of that section. We will demystify it completely. The second tool is less complicated and not as packed with options, but its role is still important.
So I invite you to take a brief look at those settings that are asked for in the process of creating a new application. If this isn’t clear, please refer back to the first article of this series. Once we know what to do, we can decide whether the default settings suit us or if modifications are required. Note that some of the following options might not be in earlier versions of Visual Studio. But as they are present in the newer ones, they will be included here.
AppWizard
After you start up Visual Studio and create a new MFC application, the AppWizard will appear in front of you. After clicking on the first “Next” button, the Application Type related questions follow. Read below to see their explanations and descriptions.
Application Type:
Application Type:
Single Document - Allowing a single document/window to be opened at a time.
Multiple Document - If you want to fiddle with a multitude of windows inside your application, then choose this.
Dialog based – The main window will be a dialog like the Wizard’s window.
Multiple Top Level Document – Just like a Multiple Document, but now you can play with your windows in the outer portion of the main window too.
Document/View architect support - Makes it easy to support multiple views, multiple document types, splitter windows, and other valuable user-interfaces.
Resource Language – Quite self-explanatory.
Use Unicode Libraries – Unicode standard for encoding wide characters on Windows NT, Windows 2000, and Windows XP platforms.
Project Style:
Windows Explorer - Implements a Windows Explorer–like application
MFC Standard – Nothing fancy… just the standard.
Project Style:
Use MFC in a shared DLL - MFC libraries will be shared; it reduces the size of the final application, but you have to make sure that the end-user has this on his/her system.
Use MFC in a static library - You're going to get a bigger application size, but your application will work whether or not the end-user has the MFC libraries installed on his/her system.
The next tabs will hide the settings for the level of the compound and active document support. Please note that to do this, the Document/View architect is required.
Compound Document Support:
None
Container - Contains linked and embedded objects.
Mini server - Indicates that the application can create and manage compound document objects.
Full server - Indicates that the application can create and manage compound document objects.
Container/full server- Indicates that the application can be both a container and a server. A container is an application that can incorporate embedded or linked items into its own documents. A server is an application that can create automation items for use by container applications.
Furthermore, we come to the settings where we define the program’s file name, extension, etc.
Document Template Strings:
File extension - What extension you would prefer for the document created by the program.
File type ID – The label that will be assigned to the extension in the registry.
Language – Just a static text box showing the language that will be used; if you want a different one, go back to the Resource Language settings at the beginning.
Main frame caption – Change this if you want a different name to appear at the top of the main application frame (default is the project name).
Doc type name – Under which name do you want to group your files? For example, the documents with which MS Word can work are grouped under the MS DOC File Name.
Filter name – When you are opening/saving a new file, determines what kind of options will be at the filters place. For example, at our program, it will be MFC2008 type files with no extension (*.*) usage.
File new short name – The default name that will be assigned in case you create a new file type in your application.
File type long name - The file type name that will appear in the registry.
Picking a Database support level is what comes next. It is pretty understandable and straightforward. The options that aren’t mentioned and explained here are, simply put, beyond the article’s scope.
Database view without file support - Includes database header files, link libraries, a record view, and a recordset.
Database view with file support – Add a file support to the prior option.
At last, we go to a tab where we can choose some instantly visible options. We just have to choose whether or not we want them in our application:
User Interface Features:
Thick frame - Creates a window that has a sizing border. It's default and useful.
Minimize box - The little minimize button in the right-upper corner. Default.
Maximize box –The maximize box for maximizing the window. Default.
Minimized – Open the main window as minimized at the start.
Maximized -Open the main window as maximized at the start.
System menu – If you require its presence, then put an affirmative in the box. Default.
About box – A dialog that every window has under Windows, so if you aren’t making a dialog based program, this is a mandatory option.
Initial status bar – Do we need the status bar? Default.
Split window – It will provide a splitter window like the Windows Explorer.
Toolbars:
None – We don’t want a toolbar.
Standard docking – Just a plain standard docking toolbar will be added. Default.
Browser style – The Toolbar will get a more evolved, Internet-Explorer like toolbar.
Before reaching the end, we cannot forget that there are some advanced options. To understand this you may need some superior knowledge of MFC and this article series isn’t covering that. So this part will just be mentioned. However, for a more in-depth view on each of them, don’t neglect the power of Google.
f) Advanced Features
Context-sensitive help – Generate a help file. There are two types, a WinHelp and an HTML format, but the first one isn’t supported anymore.
Printing and Print Preview – Says it all, nothing to add.
Automation - Specifies that the application can manipulate objects implemented in another application or exposes the application to Automation clients.
ActiveX controls – Supported or not. Supported by default.
MAPI (Messaging API) – Stays for e-mail handling.
Windows sockets – This stays for network connection over TCP/IP. Only needed if you are creating network capable software.
Active Accessibility - Allows you to customize the user interface for better interaction with accessibility clients.
Common Control Manifest - Generates an application manifest to enable the new Common Control DLL shipped with Microsoft Windows XP.
Number of files on recent file list – Choose how many files you want to have on the most recently used list. Anything from 0 (or none, which removes the recent file list from the menu) to 16 will go.
We finally reached the last tab. It can be described in just a paragraph. This is the place where the created classes/files names need to be confirmed. If you read the previous part, you already know which is assigned to which.
Now you have reached the end and right away AppWizard asks you if you are satisfied with the files that are to be created. In most cases, the naming is correct and you only need to confirm it. You may change the name of the header file, the implementation file, and class name, or for more advanced users, the class from which the created classes are derived.
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.
Overriding the messages is an easy task -- nothing devilish. Just select the corresponding class from the Class View Tab, right click on it, and select the Properties. A new window will appear in which you can find the messages tab. It is located near the lightning-like icon. If you still have trouble finding it, glance over at the image below.
The image shows that the list will be populated by all the receivable messages in our class. In our case, that is the CMFC_exampleView class, so it has many messages in the list. Now if we want to complete a specific command at the pushdown of the left button in the client area, for example, we seek the WM_LBUTTONDOWN message and choose to override it. MFC will then complete several codes.
First it declares the message map in the header file:
The saga is completed by adding the function at the end of the implementation file and taking you (the cursors) there, so you can continue with coding the commands that you are going to need.
//TODO: Add your message handler code here and/or call default
CView::OnLButtonDown(nFlags, point);
}
After the TODO line, you may add all what you want after the pushdown of the left mouse button.
That’s all, in short. These few steps can be taken individually, if you know the corresponding message name and the fact that each function is preceded by the “On” prefix added for its message. If you want to follow this path, you can use the MSDN help files, because there you will find tons of information about each message and all of their possible implementation(s).
Now you can use the power of copy and paste to speed up this process. But why the heck should you write this in when, with a few clicks, you’ll get the same result? Also, near the message list in the Properties Window, you will find the possible events and overrides under the other tab.
Conclusions
Throughout this article, we demystified every aspect of AppWizard. We also learned how to respond to any message that we get from Windows. With this knowledge in your “pocket,” we can finally proceed to pure MFC coding.
The next article is dedicated to MFC syntax accompanied by the GDI related classes and commands. We'll start with a brief description of the Device Contexts. Text writing to the client area near the CPen and CBrush class will be presented and demonstrated as well.
The true adventure is only starting at this point; the MFC’s power will reveal itself to you. Until now, we have learned how it works, but have only seen minimal results. Not anymore, because the next article will be full of results, mostly visible ones, so you don’t want to miss it. Trust me on this.
As usual, have a fantastic day and stay tuned because the next article is coming up soon. It is going to be published here on DevArticles too. However, in the meantime, if there are any further questions or unresolved issues related to this article or IT in general, visit the friendly ever-growing community at the DevHardware Forums.
Introduction to MFC
