石头记

不知大家碰到过这个问题没有，就是当你用两个double值进行计算后，当你想将结果输出时，却得不到希望的结果。反正与想象的不一样，在Windows时提供了API解决此问题：(MFC或标准C++好象都没找到简单的解决办法)示例如下：double d = 5 - 4.99;d应该是等于0.1吧，跟踪一下程序，发现不是，显示的值是0.0099999999999997868(不知道VC的调试器是如何

    最近要做一个状态保存器，希望用进程内COM实现，并且将状态保存在内存中，其实很简单，只需要在组件的应用程序中开辟全局内存区，即可达到效果，但突然想到，为什么进程内组件不能实现单例呢？于是，进行了若干尝试。    问题提出：    如何实现一个单例的COM进程内组件.(类似进程外组件的SingleUse)     仔细查看后发现：1：由于组件的实例创建由类厂实现，而类厂实际上是通过new的方

写Unicode控件时发现的传字串参数的问题：问题描述：   Unicode的OCX,属性参数Text，类型：BSTR。   控件的源码(VC中)   afx_msg void SetText(LPCTSTR lpszText)    VB调用1:   Dim strTest As String    strTest = Text1.Text       ‘Text1文本框为空    If N

最近处理一个控件Bug，发现COM组件字体读取有趣问题。Bug描述：      简体中文下的应用编写：         ocx.Font.Name = "宋体"       对控件的字体初始化         text1.text = ocx.CellFont(1,1, KDS_FontProp_Name)   读取单元格1,1的字体     控件说明：当相应单元格未设置字体时，将使用控件的字

在做打印预览时：发现有趣的现象。现象：1：打印预览时宽度设置为0.1mm的线与设置为0.2mm的线显示效果一样，无区别。打印机输出正常。2：打印预览时：相同宽度的线有些显示有些不显示。 打印机输出正常。仔细查看了一下，实际上是映射模式下的显示问题，鉴于映射模式总是让人焦头烂额，值得总结一下： 开始分析：第一步；写一个MM_TEXT模式的例子。打印6条竖线，宽度由1递增。   dc.Se

    在调试应用端程序时，偶然发现很奇怪的现象，是关于被引用的MFC扩展DLL的使用问题，跟踪了老半天，总算找到问题所在，同时，也解除了以前存于心中的疑感，问题虽小，但很可能被忽视。问题：    将OCX与依赖的DLL置于同一目录下，并注册该OCX，这能保证使用正确吗？    初一看，感觉是这么回事，实则不然。我们来模拟一下场景：     假设控件A.ocx,控件 B.ocx,都依赖于MFC的扩

    在各种不同开发语言中,字符串类型显然是最常见,也是最常用的。     常用代表它最易用，是这样吗？未必，越简单，越普通，你会忽视，内里隐藏着的陷井更容易使你中招。它往往是绊脚石，或者程序中性能的瓶颈。     本身,我对VB语言及相关应用并不太熟，只不过近期编码用到，有些体会。一: 先来总结一下,常用编程语言的字串表达方式: C:      char(wchat_t) * 或 []:  字

    Web上使用ActiveX控件时，用两种安全防护，一是下载，二是使用。对于未签名的ActiveX控件，在IE的选项中有相应处理。我们不考虑下载，假定控件已在用户机注册(可能是额外的小安装包)，因为未签名，所以仍会弹出警告提示，但实际上，在控件中实现适当接口，可以去除该警告。     以MFC的ActiveX控件实现为例，可以简单如下方式做到：     1：在CXXXCtrl(继承于CO

    最近编码，在取用户文档数据目录时，遇到问题：     我的做法是： + "/Documents and Settings/" +  + "/Application Data/"     为啥这么麻烦，因为当时我没有找到合适的API，有什么问题呢？     问题出在用户名，假如我的用户名是Stone，但文档数据目录却有可能存在两种，一是：Stone， 还有可能是 Stone.域名。但实际上S

    现在，偶维护的控件，每发布一次，需要做不少工作。手脚麻利，脑袋清醒，一次需要差不多30分钟，但仔细想来，几乎没做什么有意义的事情：    假定代码已经调试完毕，准备发版，简单罗列一下需要做的事儿：    1：签出相关的发布文件。因为牵扯多个版本，所以有好几个不同的文件。    2：编译源码：        首先呢，需要升级控件编本号(通过修改rc文件和odl文件)。       由于控件根

   对于标准的MFC扩展DLL，当需要要编译成两个不同名的版本时：如，A版和U版。其它VC程序在使用时，一般采用lib方式链接。扩展DLL导出两个不同名的lib，分别对应不同的DLL版本(两个版本不同名MyMFCDLL.dll和MyMFCDLLU.dll)。   一般情况，采用DEF文件来进行lib和dll的对应。如下：    LIBRARY      "MyMFCDLL"    或    LI

用CFontHolder.Select要小心： 如果你只用第一个参数，那也罢了，如果要用后两个参数，改变当前字体的显示比例，就要小心了。 首先：     用 IFont-Set_Size()来设置字体时，系统会进行舍入处理，     比如：设置10，再Get_Size就变成9.75。     这是正常的，至少你再设置一次9.75，它不会再变化。 问题：     当用Select改变映射模式，舍入规

    前段时间，在查控件的内存泄露时，最终找出一个错误：在使用XMLDom(COM)时，由于重复使用某接口指针前未释放Dispatch指针(Release)，而导致内存泄露，而此类错误(如同BSTR类型的泄漏)，VC的调试器和Bondcheck均无能为力。解决办法，似乎只有细心一途。    但只要稍稍仔细看看，就可发现，实际上如果正确使用VC提供的智能指针，是可以避免此问题的。    另外，一直

  检查自已的代码时，发现一个比较弱智的错误，是关于转码的，和CString的=操作符有关。  为了能简单重现，我模拟了一下代码：  //未有UNICODE或_UNICODE定义  USES_CONVERSION;  CString sTest(_T("test中文"));  sTest = A2W(sTest);  ::MessageBoxW(NULL,(LPCWSTR)sTest.GetBuf

在处理打印时，有时需要提前计算分页情况，或者是对报表头尾进行区域边框汇制，也就是需要提前计算文本的行高(在实际输出前)。做法是将文本的字体选进DC，然后从DC中取出TextMetric，再从中取出字高和间距进行计算。在实际输出(打印或预览)时，再次重新计算行高，以便输出(采用Textout需要区域参数)。发现问题：如果输出到对话框(实现打印预览)时，重新计算的行高与之前计算的行高有区别。于是，

好象很少情况会在com的参数中用到数组。但有时候数组确实也会有它的方便之处。特别是变体数组可以存放不同的数据类型，特别的方便。(还有就是传递不定数目的参数时，可利用变体数组，非常有用)比如现在有一堆数据需要进行处理，处理的分支条件是数据的类型。VB中的调用代码：dim var1,var2ReDim var1(3)var1(0) = CInt(10) 整型需要*10var1(1) = CL

需要将CString的Format进行封装，使得在所有加载资源ID的代码调用前，切换到正确的资源。用完后恢复为用之前的资源。因为涉及到变参，开始有些没想明白。因为变参需要约定规则，而Format的规则，即格式串中%符号，这很复杂，解析太烦。查看CString::Format源码，发现：CString::FormatV已经将一切工作搞定。这样一来，实现就很Easy了：void CBaseUtil::

最近偶然用到一个结构体：SCROLLBARINFO ，编译(用到VC6+SP6)时无法通过，提示未找到其定义。仔细查看了一下API文档，提到：HeaderDeclared in Winuser.h, include Windows.hMinimum operating systemsWindows 98, Windows NT 4.0 with Service Pack 6觉得没啥问题啊，只好把W

    今天得闲，刚好又要处理OCX向下兼容性的问题，于是仔细查看了一下造成问题的原因，做了些简单测试，不打算从原理分析，我们暂且从表象上分析。[问题描述]    在使用MFC框架制作OCX时，存在向下兼容性问题。    在旧控件的某个接口添加Property时，重新编译。你会发现原有的调用exe程序(VB编译所得)在调用该接口的Method时会出错。    Why？按理，添加属性，不应该出现兼容

MSDN中关于CWnd::OnChar()帮助有误？需要将窗体的OnChar消息传递给内含的子窗体，按MSDN解释：nFlags等同于LParam的值，于是按如下进行传递SendMessage(WM_CHAR, nChar,  nFlags)结果发现传到子窗体中的nRepCnt不正确。看看OnChar帮助(见下)，对于nFlags，MSDN中的Contains中并未包含nRepCnt，而下面的列表

VarFormat的不正确使用导致内存泄漏一个很弱智的错误代码如下：       _variant_t var(dblValue);       CString sOut;       BSTR bstrOut = sOut.AllocSysString();       ::VarFormat(&var, L"0.#########", 0, 0, VAR_FORMAT_NOSUBSTITUTE

如果将2000系统的默认语言切换为日文(或英文，繁体中文)，你将发现很多软件输出的是一堆乱码或?。其它人的程序也就罢了，可是，俺们提供给用户的程序也这样。偏偏用户中有小日本，他用中文Win2000，但却将默认语言设为日文，唉。出现问题描述：我们的程序结构是：客户端的输出采取HTML(混合VB脚本)，关键业务采用ActiveX控件。控件由VC编写。乱码为VC编写的ActiveX控件中的输出。分析一下

昨天写程序时，想调用OCX中的输出函数（DllregisterServerl, DllUnregisterServer）完成自注销，注册。于是，使用LoadLibrary 来加载 ocx，然后再取其函数指针。结果发生奇怪问题：1：如果该ocx是Unicode版ocx，则直接加载肯定会失败。Ansi版ocx会一切正常。2：对于Unicode版ocx，如果在调用 LoadLibrary 前，曾经使用过

    旧有程序，在处理CTime的格式化时，经常会使用Format函数进行输出。    普通情况下不会有问题。但最近改Bug，在旧控件中碰到一个特殊情况，发现其缺陷。[具体状况]    用MFC编写的OCX中，有如下简单代码：    CTime t = CTime::GetCurrentTime();    CString sTime = t.Format(_T("最近计算时间: %Y,%m,%

    前几天，一位同事问起如何在java中调用vb写的com，以前知道可以用java的native方式，通过windows dll中转来实现，但未实践过，今天忙里偷闲，刚好试了一把。写了一个最简例子。    步骤很简单，或许哪位同学以后有可能用到，俺就帮忙整理了一下：第一步：生成最简COM(采用VB60)1.1：VB代码PROGID：testVBCom.clsTest线程模型：STA 多实例模型

   在调用Java的打印时，发现调用Java提供的纸张调整功能有问题(需要实现连续走纸的动态微调，在打印过程中，动态改变纸张高度，来消除走纸误差)。对于该应用，我是在Windows上用MFC做过相应程序的，没有任何问题。网上也有很多介绍，应该说Windows的打印是进行了很好支持的。但为啥Java的实现会有问题呢？      看过Java的相关代码后找到原因：发现它在纸张调整时，做了额外的根