Click here to Skip to main content
14,977,910 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Forgive me if my questions and comments seem naive; I've not yet acquired much experience using Visual Studio, though I do possess a great deal of experience building GUIs using direct calls to the WinAPI.

I am using Visual Studio's MFC Application Wizard to create the framework for a graphical user interface to a software engineering tool. The GUI is to have an MDI capability. The MFC Application Wizard successfully generates the source code for the GUI framework. The executable built includes menus, basic editing functionality, etc. Initially, I was very impressed by the wizard's capabilities. However, I was then confronted with the problem of adding the program logic needed to implement planned GUI capabilities. Modifying menus, adding toolbars, and dialog boxes was not difficult, but I found it difficult to find answers to questions like these,

o In which component should an event handler for a given menu item be added, and what sort of program logic was needed? ;

o How could I find where in the source code the application wizard had placed its event handlers for the default menus created (some seem to have been hidden from view)?;

For example, I added a menu item that could be used to select a font for text documents. It was easy enough to bring up the Font Dialog and to retrieve selections made, but which MFC classes should then be used (and how) to influence the presentation of document text. CFont seemed like a natural choice (based on name only) until I discovered there was insufficient capability built into this class to do all that needed to be done. Visual Studio's Help facility provides descriptions of its classes and their methods, which in my opinion are too terse and about as useful in building an application, as a dictionary is in writing a novel.

I have purchased and read texts, examined the sample code provided by Microsoft, and spent hours experimenting. It shouldn't be this difficult. A major failing of MFC, I believe, is that MFC class functionality is insufficiently explained and that program control for MFC applications is insufficiently apparent (too much transparency).

It now seems that there is more critical review in this than I had intended and fewer questions to be answered. Would anyone like to give advice on how I might be led to a more positive view? I guess I'll let that be my single question to you all.
Sergey Alexandrovich Kryukov 25-Apr-13 15:35pm
First of all, do yourself a big favor: never use MDI.

1 solution

MFC follows a 3 tier model consisting of the application, view and data. The related classes are CApplication, CView (several choices), and CDocument. From an access point of view, you are allowed to put handlers for any UI events in any of these classes, but from an architectural point of view, you should put UI event handlers in the View class and minimal view control in the app class. Your CDocument class should not interface to the CView or CApplication classes. I can't draw a picture here but access should go CApplication -> CView -> CDocument.

Generally speaking, if you have a class that "has a" thing in it, the containing class should be the one that makes requests and controls the "thing". If you want to control something related to fonts from the UI, then the view class should "contain" a CFont object (either directly or in the CDocument object), and the view class should make the change requests to the CFont object.

It could be argued that the CFont object could be in either the CView or CDocument but I think you will find most people would put it in the CDocument (... but not the CApplication).
Espen Harlinn 25-Apr-13 18:38pm
H.Brydon 25-Apr-13 20:43pm
Thank you sir!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900