Visual Studio 2010及其MFC应用程序向导 [英] Visual Studio 2010 and its MFC Application Wizard

问题描述

如果我的问题和评论看起来很幼稚，请原谅我;我还没有获得使用Visual Studio的丰富经验，尽管我确实拥有使用直接调用WinAPI构建GUI的丰富经验。



我正在使用Visual Studio的MFC应用程序向导，用于为软件工程工具的图形用户界面创建框架。 GUI具有MDI功能。 MFC应用程序向导成功生成GUI框架的源代码。构建的可执行文件包括菜单，基本编辑功能等。最初，我对向导的功能印象深刻。但是，我遇到了添加实现计划的GUI功能所需的程序逻辑的问题。修改菜单，添加工具栏和对话框并不困难，但我发现很难找到这些问题的答案，



o哪个组件应该是一个事件处理程序添加一个给定的菜单项，需要什么样的程序逻辑？ ;



o我怎样才能找到源代码中的位置，应用程序向导为其创建的默认菜单放置了事件处理程序（有些似乎已从视图中隐藏）？ ;



例如，我添加了一个菜单项，可用于选择文本文档的字体。很容易调出字体对话框并检索所做的选择，但是应该使用哪些MFC类（以及如何）来影响文档文本的显示。 CFont似乎是一个自然的选择（仅基于名称），直到我发现这个类中没有足够的能力来完成所有需要完成的工作。 Visual Studio的帮助工具提供了对其类及其方法的描述，在我看来，它们太简洁，在构建应用程序时非常有用，因为字典是在写一本小说。



我购买并阅读了文本，检查了Microsoft提供的示例代码，并花了几个小时进行实验。这不应该是困难的。我相信，MFC的一个主要失败是MFC类功能没有得到充分解释，并且MFC应用程序的程序控制不够明显（透明度太高）。



它现在似乎有更多的批评性评论，而不是我的预期和更少的问题需要回答。有人愿意就如何引导我更积极的观点提出建议吗？我想我会把这个问题全部交给你们。

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.

推荐答案

MFC遵循由应用程序，视图和数据组成的3层模型。相关的类是CApplication，CView（几个选项）和CDocument。从访问角度来看，您可以在任何这些类中为任何UI事件放置处理程序，但从架构的角度来看，您应该将UI事件处理程序放在View类中，并将最小视图控件放在app类中。您的CDocument类不应与CView或CApplication类接口。我不能在这里画一幅画，但访问应该去CApplication - > CView - > CDocument。



一般来说，如果你有一个有东西的类，那么包含的类应该是那个发出请求并控制东西的类。 。如果你想从UI控制与字体相关的东西，那么视图类应该包含一个CFont对象（直接或在CDocument对象中），并且视图类应该向CFont对象发出更改请求。 />


可以说CFont对象可以在CView或CDocument中，但我认为你会发现大多数人会把它放在CDocument中（...但不是CApplication）。

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).

这篇关于Visual Studio 2010及其MFC应用程序向导的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！