软件下载 | 资讯教程 | 最近更新 | 下载排行 | 一键转帖 | 发布投稿
您的位置:最火下载站 > 电脑教程 > 编程开发 > C/C++开发 > 一个月学会VC++2010 3.我们动手吧!

一个月学会VC++2010 3.我们动手吧!

中国的文人,有个根深蒂固的传统:皓首穷经。

从三百千千,到四书五经,到诸子百家,诗词歌赋,琴棋书画,每个学子往往要经历漫长的十几年甚至三十年。所谓十年寒窗无人问,一朝成名天下知,是所有文人的潜藏情节。所以,有老实人说出了老实话:百无一用是书生。我一直觉得他们仿佛在学东方不败大侠,先对自己狠心点,然后闭门苦练,最后终于明白了万物滋生的大道,乃至所向无敌。

作为普通人,我们还是尽早动手为好。

第一项任务很简单,精确点描述是这样的:创建一个应用程序,使用两个Ribbon按钮,在两个窗体中切换。

是啊,用户做的第一件事情,就是找到功能,然后进入相应的界面,菜单、工具栏还有Vc++2010提供的Ribbon功能区方式,无论怎样,这都是首先要掌握的内容。

站在程序员的角度,你最经常遇见的可能是哪些场景呢?界面、读写文件、读写数据库、设计业务类,就这些,做得专业点,号称程序员就顺理成章了。我觉得各种知识的讲解很多,但如何在实际工作中,做到像模象样,好象没有多少这样的资料。因此,这个系列讲解的虽然只是一项不太复杂的功能,但会尽量的讲透,涉及到界面、性能、异常、用户体验诸方面。

因为是首次接触VC,那么我给自己定下的规矩很明确:学习阶段,绝不考虑重用性问题、绝不考虑扩展性问题、绝不考虑代码风格问题,尽量在第一时间将功能稳定的实现。在不熟悉语言的时候,你七七八八太多,那简直是在虐待自己的大脑。语言熟悉后这些东西你有精力再去玩,现在,还是老实点好。

那么,我们首先面临的问题是使用传统的菜单、工具栏形式,还是使用Ribbon界面。这种选择对于我来说,不是什么问题,喜新厌旧据说是男人的本能,嗯,照照镜子,我发现里面是一张男人胡子拉碴的脸。然后呢?我遇到的第一个问题,是文档视图结构。

这是一种延续了几十年的模式,换句话说,是一种古老的模式。大家看看记事本就知道了,处理一种后缀名为TXT的文件,打开、关闭、保存文件,将文件后缀在操作系统注册到记事本,简单的说,就是你创建的这种应用,将针对某种专用的格式,相关的一些处理工作,由文档视图结构预先的帮你做好,很贴心,是不是?

所谓文档视图结构,马上动手,用项目向导创建一个简单的单文档、单视图结构的应用,可以看到VS帮我们创建的一些代码,嗯,四个类:一个应用程序类,是整个系统的入口,然后创建MainFrame实例、后者将管理文档类和视图类。文档类负责处理对这种格式的文档的各类操作,视图类负责呈现、编辑这种格式的文档。

但是,两个问题:首先,我们现在已经很少敢于制定自己专有的文件格式,比如各类视频格式,都是几家恐怖的巨头在发布标准然后互相撕咬。一个可怜的程序员竟然做这种不合身份的事情,实在令人齿冷。其次,相对于专有格式而言,我们做桌面应用普遍还是以数据库应用居多。

所以我的想法很简单,文档类基本不用,放个空壳在哪里。视图类呢?首先我想找寻类似Wpf的窗体设计器,视图能不能直接的“画界面”?很沮丧,不能,我只找到了对话框设计器。接下来,我们知道,若视图继承于CFormView,则可以使用对话框设计器来设计界面。 但这样我们需要做多视图项目,

为了利用对话框的界面设计能力、同时保持整个程序的简单,浮现在我脑子里的,是一种古怪的想法:对话框有一种“子对话框”风格,我们在视图中直接打开这个对话框,则看起来是无缝集成的,我们就能自如的在两个对话框之间切换了。

嗯,有熟悉的程序员马上要问了:不是有基于对话框的应用程序向导吗?两个问题:首先我们希望的是处理多个窗体,但不要弹出,这个是木有办法的;其次,更重要的是,这时候你不能在应用程序向导中选择Ribbon方式,也许有“在对话框应用中使用Ribbon“之类的深入研究,但我确实很懒惰,不太愿意在这类事情上消耗时间。

接下来,我按照工作的步骤,简单的描述完成这项任务的过程。需要说明的是,这个系列的帖子是休闲贴,我不会一边做一边截图一边写,时间和精力不允许,所以很难做到step by step的方式,仅仅是列出步骤和基本的知识点,当然也包括初学者肯定会闹出的笑话。

1、创建项目:创建一个MFC应用,在配置向导中,注意勾上“功能区方式”,提供文档视图支持,单文档模式,其他无所谓。项目创建完毕后,运行一下。

2、简单的阅读一下生成的代码,次序是App类->MainFrame类->Document类->View类。不要深究,比如View中那堆很混乱的宏,只要从字面理解就行了:定义消息循环,不需要学究到一定要弄懂这堆宏究竟会转换成怎样的代码。读代码的方法,嘿嘿,这是秘籍:看看类结构,揣摩一下方法的名字,然后不要太关注每个函数内部的代码,会很快的。需要注意的问题,是我们经常见到的项目按文件夹组织的方式,这里没有,VC项目中叫做筛选器,仅仅将同一个目录下的文件分类,并不改变文件的物理位置。

3、我们将创建两个对话框,注意:style设为child,去掉确定和取消按钮,不要边框。仅仅放上一个静态文本字段,分别是“第一个”和“第二个”。

4、我们要为两个对话框创建类,这个不要傻乎乎的自己写代码:右键,为对话框生成类,就行了。为什么要有这个步骤?对话框以“资源”形式保存,仅仅保留了一个唯一的ID和控件类型、位置、大小等信息,我们毕竟要通过代码控制其工作,那么创建类绑定这个对话框就是必须要做的事情。

我不太喜欢用记事本写程序那一套,今后自然会理解:类向导自动的帮我们创建对应的对话框类,一般是继承自一个公用的基类,添加消息循环等代码片段,重写一些虚方法。

5、那么,我们在Ribbon设计器中,创建一个“面板”,然后放上两个按钮。

6、当然,需要为两个按钮创建“添加消息处理程序”,也是在Ribbon设计器中,右键,就能看到了。针对消息类型“Command"”和“Update_Command_UI”都要创建,前者是用户点击按钮后要做的事情,后者我们用来处理按钮是否可用的问题,当然,这两个方法添加到View类中。

7、我们现在有了四个消息处理函数,以Command为例,怎样在视图中显示一个对话框?

8、看看下面的代码:

void CSouGuView::OnButtonHome()
{

if (CurrentDialog) //如果已经有对话框打开了,干掉它。
{
CurrentDialog->DestroyWindow();
delete CurrentDialog;
}

CHomeDialog* dlg = new CHomeDialog(this); //创建对话框类的实例
CurrentDialog =dlg; //我们在View中定义的CDialogEx* CurrentDialog; 我们创建的对话框类都是从CDialogEx继承的,因此,这个指针用来表示当前显示的窗体。
CurrentDialog->Create(dlg->IDD,this); //这里创建窗体
CurrentDialog->ShowWindow(SW_SHOW); //显示窗体
CurrentDialog->CenterWindow(this);//将对话框在视图中居中,注意屏幕大小改变后,就不再居中,需要在OnSize事件中处理
CurrentDialog->SetBackgroundColor(RGB(255,255,255));//将背景色改为白色,马虎应付一下

}

9、然后看看消息循环中的代码:

BEGIN_MESSAGE_MAP(CSouGuView, CView)
ON_WM_CONTEXTMENU()
ON_WM_RBUTTONUP()
ON_COMMAND(ID_BUTTON_HOME, &CSouGuView::OnButtonHome)
ON_WM_SIZE()
ON_UPDATE_COMMAND_UI(ID_BUTTON_HOME, &CSouGuView::OnUpdateButtonHome) //注意这句,如果对应的对话框已经打开,则按钮不可用
ON_COMMAND(ID_BUTTON_QUOTE, &CSouGuView::OnButtonQuote) //注意这一句:如果用户点击这个按钮,执行OnButtonQuote方法。
ON_UPDATE_COMMAND_UI(ID_BUTTON_QUOTE, &CSouGuView::OnUpdateButtonQuote)
ON_COMMAND(ID_BUTTON_CHART, &CSouGuView::OnButtonChart)
ON_UPDATE_COMMAND_UI(ID_BUTTON_CHART, &CSouGuView::OnUpdateButtonChart)
END_MESSAGE_MAP()

10、当然,如果你打开了这个对话框,可以让这个按钮失效:

void CSouGuView::OnUpdateButtonHome(CCmdUI *pCmdUI)
{
if (CurrentDialog)
{
pCmdUI->Enable(CurrentDialog->GetRuntimeClass()!=RUNTIME_CLASS(CHomeDialog));
}
}

很显然,消息映射中ON_UPDATE_COMMAND_UI(ID_BUTTON_HOME, &CSouGuView::OnUpdateButtonHome),是对应这个的。

大致的意思:如果当前有对话框打开,那么:如果是CHomeDialog类的实例,这个按钮就不可用。已经打开了这个对话框,你还打开它干嘛?

11、另一个对话框也是一样,算起来我们创建了四个消息处理函数。代码就复制一下,运行,能够看到来回切换的效果就行。

12、存在的问题:

首先,VC的对话框的布局问题,很原始。原始的意思,就是你需要自己处理。当你改变主窗体大小、或者在不同分辨率的机器上,对话框的所有控件总显示在视图的左上角,界面是很丑陋的。这是以后的问题,我最后的解决方案是:多数情况下窗体比较小,保持居中显示就行了;少数情况下,比如显示K线图的时候,需要自动适应主窗体的大小,使用一套叫做EasySize的宏解决问题。

其次,这里虽然实现了对话框居中显示,但由于OnSize事件中没有处理,窗体大小改变的时候,对话框的位置将不再居中,这个此后再处理。

总结一下遇到的问题:

1、首先是所谓指针的概念:

其实这真是幼儿园级别的问题,往下看,五分钟差不多能够弄清了:我们假设内存有1000个字节(不用说2G了,只说1k吧,好描述),从0开始给每个字节编号,最后一个是999。这个编号就是指针,很显然,指针实际上是整数,表示内存的编号,也就是内存地址。我们常见的,32位操作系统的电脑,不能利用4G内存的事情,大家可以算算,32位也就是4个字节的整数,最大值是什么。

比如我们定义一个int 指针,怎么做?

int *p;

意思是我们现在有了一个int指针变量p

然后p=0,什么意思?指向内存0的位置。

你如果没有为指针分配空间,那么对指针的操作就是一种令人崩溃的游戏。

虽然指到了那个地方,但那里并没有你分配的一个整型的4个字节的空间,而很可能是另一个变量的位置。

所以第二步我们可以为其分配空间:

p=new int;

或者p=new int();

这个时候,你设置断点看看,p的值已经变化了。怎么回事呢?系统将从空闲的内存中画出四个字节给你,并将这小片内存的地址:也就是第一个字节的编号传给p。系统同时会给这部分内存做上标记,继续分配空间的时候,不要再拿出来献宝,

好吧,第三步:这片内存里的值是不可知的,为其赋值。

*p=10;

嗯,第四步,我想将p的值传给一个局部变量 int x;

容易:x=*p;看看,x现在也是10了。

注意x是局部变量,不是指针,那么背后发生了什么事情呢?p所指向的四个字节的内容,拷贝到x所占用的四个自己的内容,如此而已。

那么第五步,我们反过来,令x=100,想让p接管x所占用的四个字节,怎么办?

p=&x;

这就行了,&表示x的地址,再看看p,他的值显然发生变化了,指向另一片位置了么。

不过马上你面临第6步:

原来p的那四个字节呢?没主了,谁都遗忘了,它还在那里,不再能够使用。内存泄漏?一个函数可能短暂时间执行几千次,这样不断失去控制、不断丢失的内存就可能膨胀起来,最终的结果大家很容易想象。内存泄漏是很多大侠不断用来表达自己功力深厚的东西,其实不复杂是不是?

第7步,怎么避免呢?

容易,请在改变p之前,先delete p;先不说执行析构方法之类,我们简单的理解:将p指向的内存空间还给系统,那么,虽然p指向其他地方的话,这块地方也能继续分配给其他变量。

第8步,那么int类型的局部变量,是不是也要delete呢?不需要,堆的概念、栈的概念也不用多讲,一个函数结束的时候,所有局部变量都会自动的析构,不用我们操心。只有用手工方式分配内存的,比如new出来的,需要我们处理。我最初闹过这个笑话,自己在函数里创建一个对象,退出前自作聪明的运行其析构函数,程序运行时崩溃,因为析构方法执行了两次,第二次执行的时候那个对象已经不存在了。嗯,这种错误犯过两次,弄半天才找到原因,相当于在同一条沟沟里跌倒两次,所以我对自己的智商也委实不太自信。

第九步:int毕竟是简单的,你创建一个类的实例,用指针指向它,一切行为没什么不同,两个区别:1、你创建的对象可能需要更多的空间;2、p->访问对象的成员,对象x则用“.”这种符号。

需要一个月才弄清指针的概念吗?不需要,没有更多的知识了,指针的指针是什么?嗯,指向指针变量本身的指针而已;Void *是什么:指向一块不知类型的内存空间罢了。p++什么意思?指针越过其类型所占的字节,这里是加4。如果你刻意将这种概念弄得太精巧和复杂,要整出很多变态的用法,我要问问你为什么?你其实只需要这些知识就能轻松的做事,何必折磨自己的大脑。

第十步,我是怎样弄清这些的?知道内存,知道内存地址,知道指针是存放内存地址的变量,这么三句话之后,上面的这些不是很自然的理解了吗?

第十一步,有大牛说过,不解决内存泄漏的问题,C++无法做超大型的项目,怎么办?嗯,搜索一下“智能指针”,不过好象我们很少做超大型的项目吧?虽然这里有高手说起500万行以上代码的项目,但做那个的,我觉得和我们几乎是两个世界的人物,或者就是一帮精神病院的家伙。暂时就不要杞人忧天了,发现问题解决问题就是,仿佛一句流行的官话:“发现一起,查处一起”,当然,聪明人马上会想到:怎样才能发现?谁来监督你是否去想办法发现了?怎样查处?谁能知道是否真被查处了?查处了以后会不会马上就复出?中国语言的模糊性,注定了中国程序员的质地。

2、然后是头文件的问题:

对于习惯C#命名空间的人来说,头文件真是很无聊的东西,太古老、太原始,Too simple,some times naive。

我很快弄清了原因,为什么这个是需要的?.net 最终编译之后,保存了元数据,所以你使用一个dll,有反射机制可用。C++没这种东西。

在头文件中声明,在源文件中实现。

声明的意思是告诉编译器,我这里定义了一个类,编译器只需要知道,却不会将这些东西编译到obj或者dll中去。事实上,主要的作用,是编译器知道某个对象分配多少空间,相当于编译器使用的参数。

源文件中include “xx.h”

意思是将头文件全文复制到这里,然后一起交给编译器。

在这里我闹的笑话很简单,就是void CSouGuView::OnButtonHome()

看看这个符号“::”

表示这个类的方法,头文件里要声明,源文件里要实现。

如果没有这个呢?

最初我本能的在源文件中写int xxxx;

当然,不在任何函数内,用起来似乎也比较正常,但总是很奇怪,为什么这里改变了,在那里它也同样改变了。

直到后来出现问题。

甚至你这样自由的在源文件中定义不带“::”符号的函数

似乎也可以用,但却很奇怪为什么里面的智能感知失效了,用类的成员会出现编译错误。

噢,这种简单的问题是一周后才弄清楚的,不要笑话我,所有人都会碰到的,高手们不会讲解这种问题。

3、代码的坏味道:

极限编程、Scrum这类敏捷流派,耳熟能详的一句话是:“当你复制剪切的时候,就要嗅到代码的坏味道,啊,重构的时机来了。”

看看,两个Command消息函数、两个update的消息函数,是不是都是复制的?为了重用,这里显然要重构一番是吧?对不起,我现在没工夫,就这么对付了。要知道自己的目的,时间花在主要目的上,对于重构也好、对于怎样将代码设计的更柔韧也好,我相信自己比多数人都会强一些----可是我现在在干什么?尽快实现功能,熟练掌握Vc++。重构不需要时间吗?需要的,但这个阶段不能花这种时间。这个小的应用程序,总数不超过15个窗体,几秒钟就能复制粘贴一番,估计到项目结束之后才有空去考虑这个问题。

第二个坏味道,是View类必须知道每个对话框类的名字,当然,这也意味着有多少对话框就要include多少头文件。哇,设计模式发挥作用的地方到了,为每个类提供一个创建实例的方法,然后整个接口?创建一个对话框的基类?我说是吃饱了撑的,有闲的时候再做好不好?每个小时都很重要,你追求的是可扩展性,可是至少要等到你的产品做出来再说吧?或者今后就完全没有扩展的需要呢?或者今后接手的是个菜鸟呢?最优先考虑的肯定是如期完成项目,可扩展性服务的是程序员而不是用户,而大量使用各类设计模式,因为更抽象,所消耗的时间往往是简单实现的数倍以上,是一个工时和5个工时的区别。是否能够分清重点,是智商是否达到及格线的问题,不是技术能力问题。并不是某位高手说“我主要找写库之类的岗位”,那就更高人一等,虽然写库这种词听起来就有些别扭的味道。

做类设计的时候,多一个类可能意味着10%以上的理解难度、开发成本的增长,所以我的目标往往首先是用最少的类实现,只在会影响到实现、或者通用性考虑不足会加大开发成本的情形下,才考虑那些稍稍抽象的东西。我当然也经历过设计模式狂热的短暂阶段,以这种实用主义、直触本质的学习方法,武器显然是不缺乏的。最明显的例子,大家可以看看通达信的股票行情软件,这样以产品吃饭的公司来说,居然存在针对不同证券公司的多种版本,对于开发团队的维护、升级来说,这绝对是一个灾难:不同的公司显然会提出一些各自特色的要求,有些可以拒绝,不能拒绝的往往是公司很关注的部分,这要做好业务分析、精心抽象,并通过通用化的设计,进行单一版本的升级来向所有客户提供同样的功能,是否使用由客户自己决定。这种多样版本并存的情形,源代码管理、开发人员是否永远在公司、自动升级服务器的部署,复杂度和工作量完全是几何级数的增长。至于应用项目,短周期的情形下,则要尽可能回避复杂化的苗头。软件开发首先是生意中的一个环节,在保证交付、稳定运行的前提下,开发和维护成本该怎样控制、如何保证如期交付、如何保证符合合同规定的质量要求,其实是团队要重点平衡拿捏的,这种观念必须贯穿于软件过程的始终。简单的说:你是在工作,不是在研究。

所以按照前面说的,我理直气壮的忽略这些“代码的坏味道”,留待项目结束之后。

再总结一下这短短几行代码,我们逐渐嗅到了些什么东西,当然,谈不上熟悉:

1、消息循环:宏语句,不要探究细节,从字面上理解足够了。

2、类向导:能够用工具就不要手工写了,相当于代码生成器,多用。

3、头文件的问题:理解多数情况下,头文件仅仅是嵌入源代码的“声明部分”。

4、调试、断点设置之类,这个没什么变化。

5、指针:整数,记录某块内存的开始地址。

6、文档视图机制:当作阑尾吧,留着。

7、Ribbon界面的设计:操作问题罢了。

8、对话框的设计、创建类、在视图中显示子对话框。

9、this指针:和C#中一样,this指向是指向类的当前实例的指针,访问类的成员,不是我们习惯的“this.xxx”而是this->xxx,因为是指针么。创建对话框的方法中,this作为参数,意思是将目前的这个view对象的指针,作为参数传递进去。

可能都不是特别的清晰,但不停编码的过程中,不知不觉的你的理解会一步步增强。慢慢来,最终也不会超过一个月的,我们今后会遇到std、stl、各类字符串、unicode问题、多线程问题、Directx Api,发现一起查处一起,这项功能做完,由任务的驱动会逼着我们逐一弄清所有这些语法细节,这样比你主动的去看书强吧?到时候象我这样写几篇博客总结一下,思路能够整理得更为清晰、众多有如牛毛或者过江之鲫的高手们如果肯指出理解上的问题的话,又能够更上层楼,何乐而不为?

略微解释几句:

这个系列,由于是面向初学者的东西,主要是希望提供一个学习的路径图,因此内容相当的初级,也不会太过详细。这里还是希望高手们要么当作游戏之作,要么带点容忍异己的心态。当然,我说起高手,一般是当贬义词用的,这是习惯,很难改变。同时因为时间的关系,一篇帖子往往用不了半个小时,两分钟写个提纲,然后顺着往下胡侃,因此错漏之处必定也有很多,就内容挑毛病我是很欢迎的,也会尽量修改。至于对我的人品挑毛病的话,就看兴趣了:兴致高的时候我会争锋相对,练练嘴皮子,体验斗嘴的乐趣,对心态保持年青、养颜防老还是很有好处的。兴致不高的时候直接忽略,所以还请各位骂手体谅,不予还击并不是不尊重你的劳动,当然也不是看不到您鼻孔朝天一脸不屑的模样,而是此人正在沮丧中……非洲还有许多孩子没有校车呢。

关于侯捷,嗯,我还是强调一下:这个人真的很无聊。他的粉丝众多,也掩盖不了这种无聊。你可以喜欢他“滴人”,我也可以不喜欢他的方法,我不能勉强你,也希望你不要逼着我和你一起做粉丝,既然都那么博大精深,我也期待你们成为星星本身,呃,通过追星这种方式?偷偷说一句:我唯一喜欢的是他的表达方式,这是个人好恶的问题,无关其他。

继续预告:下一篇将将讲述怎样设计“导入日线对话框”的界面,如何获取对话框控件的值、处理相应的消息。

(作者:玄歌 本文来源:http://by1990.cnblogs.com/

    相关阅读
    网友评论