Windows managed to take over the world of personal computers in the last decade, but please don’t ask how it managed to do so. The fact is, the only possible threat for it is Linux, an operating system that still struggles to gain acceptance in the homes of average users. Whether you’re searching for a method to program an application or just want to give your console program a more stylish look, let me introduce you to the Microsoft Foundation Class library (MFC).
Contributed by Gabor Bernat Rating: / 8 February 27, 2008
Before we start you should know that in order to understand this article you will need previous knowledge in the area of OOP (object-oriented programming). If you lack this basic skill, then you need to stop reading this article and find one that teaches you OOP, because to be honest, that's beyond the scope of this article.
Also note that for developing an MFC application, Visual Studio C++ is needed. Any version will do, but don’t forget that the express edition (for 2005 and 2008) doesn't include the MFC libraries. I will use Visual Studio 2005, but there is not much of a difference if you choose any other. Now that we know we aren't going without weapons to a war, the article can begin.
This will be a five part series. The first part is dedicated to finding out and understanding how Windows works, and within it, the MFC. Also we will create our first application and make the first modifications to it. The second part is dedicated to the presentation of the instruments used when creating an MFC program, the AppWizard, and the message map handler, which is commonly known as the Properties Window.
Our story continues with an in-depth account of the GDI (Graphic Design Interface), like Input/Output, text, standard controls, common controls, and image handling. Finally, we are going to finish the saga with a knowledgeable analysis of the resources; Menus, Dialogs, and Toolbars will also be present here.
So sit back, relax, and start learning and exploring new lands. Note that we won’t explore every corner of the MFC throughout this article series. The five-part series is intended to help you understand the basics of an MFC application, so that in the future you can learn it without difficulty by using one of the huge online book collections presenting the MFC in-depth.
MFC was introduced back in 1992 with Microsoft's C/C++ 7.0, so you can see that it has been around for a long time. As the years passed, it was revised and newer versions were published. Starting with MFC 8.0, these libraries weren't included in the free version of Visual Studio (from the 2005 version). As for the future, Windows is currently developing MFCNext, which will include a new user interface like the stylish and modern “Ribbon” present in Microsoft Word 2007. Its release date is expected to be in the first half of 2008.
MFC stands for Microsoft Foundation Class library. In its core is a collection of libraries, a set of data types, functions, classes, and constants used to create applications for the Microsoft Windows family of operating systems. Thus it was created by Microsoft to make writing applications for Windows easier and also for spreading the popularity of the operating system.
To achieve this, the API (application programming interface) is encapsulated in it as an immediate result of the higher developing speed. But before we go further you must know how Windows works in its core and how it handles the applications. This is crucial knowledge for later on so you can “get the big picture.”
If your to answer the question of how Windows manages to control all the applications at once is "event handling," then you are on the right path and surely deserve the gold medal. However, there is another good response: message cycles. Windows monitors all user activities like the mouse, keyboard, and so forth. When a message (event) occurs that affects one of the programs, a message is sent to it. For example, if you push down the left click, then Windows notifies the application by dispatching a WM_LBUTTONDOWN message towards it. You get the picture, right?
Once this is completed, it is up to the software to decide what it should do with the received message. The decision is made in accordance with the message cycle in its interior. There are two options: first it may decide that an interior handling is necessary and call for the function assigned to take care of the respective message. Then the function executes all the code that we previously wrote in it.
The second option is to ignore the message, as in the case of the absence of a function assigned to it. Either way, a result will be sent back to Windows and the OS can take the next step. It will take care of future trouble according its own message map.
The power of MFC lies in the encapsulation of the message handling. An MFC application does the same thing that a Win32 (32-bit API for modern versions of Windows) application does. The distinction is that, while coding under Win32 demands its own message handling (and all the trouble that this implies), the developer under MFC doesn’t implicate itself in this; s/he can sit back and concentrate on pure code writing. All s/he needs to do is declare a message map through which informing the MFC system is possible, describing the way it should allocate the messages. The interior system of the MFC will take care of the rest.
This is indeed a great step forward, but wait… it’s even simpler. And some truly powerful extra instruments were created under Visual Studio that tend to make programming under MFC effortless. These are the AppWizard (for creating a new application) and the Properties Window (in the case of Visual Studio prior to the .NET platform, it is known as the ClassWizard – for handling the message map).
Now we are done with talking. The time has come to act, do something valuable, demonstrate something and not just discuss. Start up your Visual Studio and follow the path: File->New->Project... and click. You will get to the image below. Then choose according to the image (you may select a different path). We want to create an application for now with the name “MFC_example.”
Click OK and the AppWizard will appear. This is the utility that does all the nasty work for us.
We can now set up the main basic options for every application. This is what AppWizard offers: it creates the model, the so-called sketch for each application. We don't need to write the standard codes that all applications require to work properly over and over again. The AppWizard automates it.
At any point you can push the finish button, if you are sure that the default options fit your need(s). Go on with the default settings for now, since they will be okay. Modifying the options will be covered in the next article.
After the creation process ends, you can build and start up the program. Kudos, you’ve just finished your first application. It will work, but it won't be very useful. Just as a newly-built home needs to be decorated, our application must be extended by our code, to add some functionality to it.
Another thing remains unresolved. We need to grasp why each file was created and what they represent. The created file names depend on the chosen name of the application. I will note the parts that depend upon the aforementioned application name with the help of the italic font styling.
MFC_example.h – The main header file for the application; here the About dialog class is also defined.
MFC_example.cpp – The implementation file of the application. This class manages the New, Open, and Print Setup among the About dialog.
MainFrm.h – Yes, this exists under this name regardless of the name of the application. This defines the functions that will create the main window.
MainFrm.cpp – As you can predict, here we implement the upper header functions. This is the place where the main window is created, then the Status Bar, and the Toolbar or the splitter view, if that’s the case.
MFC_exampleDoc.h – Header file for opening, saving, and loading files.
MFC_exampleDoc.cpp - The implementation of the upper file. Here we manage the serialization process.
MFC_exampleView.h – This represents the header file for the window shown. An invisible territory (window) is positioned by MFC in the client area of the frame.
MFC_exampleView.cpp – This is the place where we manage the client area. If something needs to be updated, this class will be called. For example, if the client modifies something and the output date has to be updated, then these classes’ OnDraw function will be called. The Print command and the Print preview content is also placed in the default settings.
Stdafx.h – Include file for frequently used headers that aren’t changed often.
Stdafx.cpp – When we create a header we need to implement it, and this helps.
Resource.h – Here the resources are defined.
MFC_example.rc – The resource file containing the resources. For a start, it contains the status bar, toolbar, menu, about dialog box, and the icons of the application. For additional information on this subject I advise you to check out the third part of this series (as soon as it goes live, that is).
Now we will extend our application with some individual touches, so it’s the perfect time to demonstrate the way we can manage this. It’s all about modifying the parameters to which the window creation is called. For this we will venture into the Mainframe.cpp. Once in there, search for the following code snippet:
// TODO: Modify the Window class or styles here by //modifying
// the CREATESTRUCT cs
return TRUE;
}
Now you must know that the cs structure holds many parameters that will be transmitted forward when the window is created for the first time. It is safe to say that at the creation process when the message is sent, it’s time to create the window. This function will be called and a result will be returned carrying all the information that is required. So let’s alter theinitial cs settings. After the comments add the following:
cs.cx = 720; // width of the new window
cs.cy = 780; // height of the new window
cs.x = 100; // initial position of the window, on the x axis
cs.y = 200; // on the y axis
Save the file and run the solution. Congratulations, we are damn good; you can already see the results happening in front of your eyes!
Time is flying by way too fast. We already reached the end of this segment. Let's not get in too much of a hurry. The second part will continue exactly from the point where we left off. Until then, feel free to go over this article several times and run the code until you completely comprehend the current part.
In this first lesson (if you don’t mind calling it that), we started by taking a quick look at the history of MFC. Then we learned how Windows takes care of all those programs that are running under it. Once we understood that part, we advanced to creating our first application under MFC. Moreover, we made the first modification to it.
As I mentioned at the very beginning of this article, MFC isn’t about writing code from scratch. We got wiser and we are building upon things that already exist; we only need to modify the parts that are specific to our view, dialog box, etc.
In the next part we will go over the AppWizard. By the time we finish that, there won’t be a single unanswered question or secret about it. Furthermore, we will learn how to add and customize the message map on our own or with the help of Visual Studio. Knowing how to use these two tools within Visual Studio is crucial, as later on they will serve as foundations for fast and good coding.
Until we meet again, don’t hesitate to ask any question that might pop up in the friendly community at DevHardware Forums. Have a fantastic day!
An Overview of MFC, Part 1
