MFC的绘制标题

配景先容

其时预备做一个读取设置文件的进度条，用以体现读取进度。进度条是用一个dialog配上Progressbar和Static控件做的，团体是通过MFC框架构建。读取数据期间通过不绝向dialog发送消息来实现进度条的更新和文本变革。但是很奇怪的是，读到肯定水平之后（比如２０％）之后整个进度条不再更新进度，文本也不再发生变革．而且多次调试，发现每次都是从１％到２０％左右正常，之后就完全不动了，真让人瓦解．
标题分析

我起首猜疑是由于界面太忙无法正常相应,颠末多次调试我否定了这个想法,由于这里仅仅是读取文件,至多是IO,不涉及到绘制,而且打断点可以很显着的感受到整个步调完全正常,读取数据也没有卡顿.以是这里可以清除界面线程的标题.接着我猜疑是由于文件打开没关闭,由于读取的文件比力多,之前出现过文件未关闭,导致用户对象和句柄耗尽的标题,但是我认真审视了一遍代码,确信我在更新过程中未使用new来获取对象,那么是什么出现这个标题呢? 我以致猜疑是windows的机制,只相应肯定命量的SetWindowText,之后就不再相应了,于是我每读取一个文件强行UpdateWindow()一下,但是标题丝毫没有缓解,还是在20左右就不再更新了.真让人无语.
标题办理

着实没有办法了,我就把windows的资源管理器打开,并把全部的句柄,用户对象,GDI,CPU,内存等都调出来,比及软件调试时,观察这几项变革.这一观察就发现了标题.该进程的GDI在读取过程灵敏从0升高到10000,在GDI到达10000后,界面上的进度条也跟着不走了.这就很显着了,这就分析在读取文件过程中在大量申请GDI对象,但是我还没有绘制,那里会申请那么多GDI呢?
缘故起因分析

厥后在跟踪代码发现,每次读完数据之后我会创建一个对象,这个对象都会初始化一个通用对象.(整个体系架构是将全部对象放入doc类中,而通用方法(比如分割,数学运算等)放到一个通用类,而绘制画刷和画笔之类的原来在doc中,但是由于doc要存储各个绘制对象,各个绘制对象来调用doc的内容不方便,我将将这部门挪到通用类中了,而且其初始化放在了通用类的构造函数中),如许每new一个对象,就会向体系初始化一次这些画笔和画刷,如许没多久就将GDI给耗尽了,以是窗口想要更新界面时,已经无法从利用体系中获取GDI,导致后续的绘制失败,以是界面就不绝保持静止的容貌.
办理方案

知道了缘故起因,就很方便办理了.我的办理方法是将这些画刷和画笔变为通用类的静态成员变量,如许每个实例初始化时,只会申请一次.说实话,画笔和画刷的静态对象初始化并不方便,费了好鼎力大举气,这里就不细说了.这篇重要的目的是记载一下调试过程,分享给遇到同样标题的小搭档.渴望统统顺遂.