C, C++, Obj-C

MFC控件CListBox调整大小时的高度注意事项

CListBox控件在进行调整大小时,默认是按照控件内item的高度进行高度变化递增的,也就是说,高度会是单个项高度的倍数,以便完整显示可见项。这样在父窗口OnSize时调整控件大小会出现高度和计算出的填充全客户区大小高度不一致的问题,显示上会有部分区域重绘错误。改变这种默认高度行为的方法就是在创建控件时,加上LBS_NOINTEGRALHEIGHT这个style bit。

用BCG Control Bar库的MFC程序中文字体过小问题的解决方法

这个问题和上一个转帖的VS2010 MFC文字过小问题如出一辙,但是那篇帖子里的解决方法只是一个临时的解决方法,对于应用BCG库后的MFC程序,尤其是应用了部分主题以后,即使修改了字体,也会由于UI部分很多地方会调用BCGPGLOBAL_DATA的UpdateFonts导致修改后的font被默认字体覆盖。
其实用源码跟踪了一下后发现,导致中文字体难看的原因其实是Segoe UI这个字体,于是修改了Bcgglobals.cpp中
static const CString strOffice2007FontName = _T(“Segoe UI”);
这行为
static const CString strOffice2007FontName = _T(“Tahoma”);
使用Tahoma字体就可以了。

开启Visual Studio下C++的注释TODO自动列表到TaskList窗口功能

用Eclipse写JAVA时已经习惯了在注释里写TODO,然后Tasks小窗口中就能够看到当前source页里的所有TODO,用起来很方便。这几天用VS 2010写MFC时留了很多TODO,才发现开了VS的Task List窗口竟然看不到代码页里的TODO位置,看了一下M$的官方Blog发现原来只有VC++用这个功能时是需要手动开启的,VB、C#都是直接开启的。VC++开启这个功能的位置如下:
Tools->Options->Text Editor->C/C++->Formatting-> Miscellaneous->Enumerate Comment Tasks。
官方说法这个选项在C++里被默认关闭的原因是due to performance reasons。

取得windows中一些特殊文件夹路径的方法

比如当前用户的documents文件夹、windows安装文件夹等,虽然一些软件的默认文档保存位置通过这种方式取得感觉有点恶心,不过在用户未指定默认目录的情况下通过这种方式取得的路径还是比较合理的。

以下内容转抄自Visual C++ Tips,原始链接:http://weseetips.com/2008/05/01/how-to-get-the-path-of-special-folders-in-windows/

Windows have a number of special folder such as my documents, desktop folder etc. They are special because, their path can be different in system to system. So how can you get the path of special folder in windows?

Continue reading…

[转]Visual studio 2008/2010 MFC程序Menu、Toolbar字体偏小解决办法

原文:http://www.blogjava.net/luchunwei/archive/2010/06/09/323118.html

首先,这是一个MFC的Bug
http://connect.microsoft.com/VisualStudio/feedback/details/505466/mfc-visual-style-font-size-too-small-to-display-chinese-character-clearly-on-windows-xp

解决时间暂时还不确定,临时的方案如下:
App在InitInstance中加入:

Continue reading…

记录VS2010下用BCGControlBar编译程序时的一个小问题

链接期错误信息如下:

1>BCGCBPRO1200StaticUD100.lib(BCGPGridCtrl.obj) : error LNK2001: unresolved external symbol _xGetSystemMetrics@4
1>BCGCBPRO1200StaticUD100.lib(BCGPFrameImpl.obj) : error LNK2001: unresolved external symbol _xGetSystemMetrics@4
1>BCGCBPRO1200StaticUD100.lib(BCGPFullScreenImpl.obj) : error LNK2001: unresolved external symbol _xGetSystemMetrics@4
1>BCGCBPRO1200StaticUD100.lib(BCGPDlgImpl.obj) : error LNK2001: unresolved external symbol _xGetSystemMetrics@4
1>BCGCBPRO1200StaticUD100.lib(BCGPAppBarWnd.obj) : error LNK2001: unresolved external symbol _xGetSystemMetrics@4

win32下combobox控件的一个大量添加数据时的加速技巧

今天在做MFC程序的时候用到了combobox作下拉列表选择,以前也用过这个控件,但是很少有像今天这样大量AddString的情况,而且是做联动list会同时更新3个以上combo的列表项,运行发现会很卡,而且简单用GetTickCount查了一下,发现就是AddString在耗费时间。其实这个操作默认情况下会触发控件的重绘,从而导致浪费了时间,一般情况下,添加项的时候是不会即刻显示的,所以可以通过SetRedraw(FALSE)然后再add的方法就可以有效提高数据添加的速度了,当然结束以后要SetRedraw(TRUE)回来,然后随便用个什么方法触发一下重绘就可以了。

Win7下使用VS2008生成C++ 项目时的link error

最近发现在Win7下使用VS开发C++项目时,在编译生成目标文件的时候总会时不时的出个link错误:fatal error LNK1000: Internal error during IncrBuildImage,还以为是程序写的有问题,后来发现再执行一次build就不会出错了!其实原来在xp下用VS2008也没出过这个问题,直到最近发现出现频率越来越高,受不了了开始寻求解决方法,发现其实是bug,而且ms也已经提供了补丁:http://support.microsoft.com/kb/948127,打上补丁就解决了。

Symbian编译时的Error -1073741819错误

完整错误信息类似下面这样:

make[1]: *** [\Symbian\9.2\S60_3rd_FP1_2\EPOC32\BUILD\…\Gif_Reader.o] Error -1073741819
make[1]: *** Waiting for unfinished jobs….
make[1]: *** Waiting for unfinished jobs….
make[1]: *** Waiting for unfinished jobs….
make: *** [TARGETMGATE] Error 2

这只是在整个过程中的一部分出现,最后提示还是***Build Complete,carbide的problems里也没有任何对应的代码位置提示,很容易误解成sdk或这编译器坏了,网上有人说重装sdk,有人说clean一遍项目。其实这是由于代码里写了一些貌似合法但实际不对的写法,举个具体的例子就是拿对象类型的变量强制转换成指针使用,比如

CCoeControl& iParent;
((CTestAppView*)iParent)->foo();

这样,就会导致这种build错误。