PB6.5中有关OLE控件功能的三个缺点

    由于PB6.0在汉字方面有问题，因此利用Sybase公司免费提供的PB6.5补丁程序进行升级是PB6.0用户较现实的选择。但笔者在用升级后的PB6.5 开发一个需串口操作微机数据库项目的过程中，发现PB6.5中的OLE(Microsoft喜欢叫她ActiveX)在汉字方面仍存在一些问题。这里不提PB5.0和6.0中存在的有关OLE控件的缺点。首先在PB中创建一个窗口w_1。

    

问题一嵌入PB中的微软OLE控件MSCOMM32.OCX的output属性为char变量或char()函数时，程序执行时为非法。把MSCOMM32.OCX嵌入到w_1中，命名为ole_1。执行以下语句时程序将提示“在进入output属性时非法，并中断程序”：ole_1.object.output=char(48)如果从以下两点来看，这个错误就不应该存在：

 

(1)从MSCOMM32.OCX本身来看，output属性(见MSDN中有关MSCOMM32的内容)完全可以等于与PB中char变量和char()函数相对应的变量和函数。

(2)MSCOMM32嵌入到PB中后，PB把其output属性变量当作any型变量来处 。Any型变量就包括char(或character)型变量。

    处理这个问题的简单方法是：把char变量或函数的值赋予一个string变量，然后再使output属性值为
该string变量值。如：ole_1.object.output=string(char(48))这样PB将正常运行。

    问题二OLE控件接收到的汉字数据无中生有。

    

利用VC++5.0的MFC　ActiveXControlwizard的所有默认选项创建一个ActiveX控件TempControl，并增加一个CString属性SetWord(m_setWord为该属性的CString实例)；在OnDraw()函数中用TextOut 函数在屏幕上显示m_setWord；在处理给SetWord付值的函数OnSetWordChanged()中加上InvalidateControl() 以便显示更新。把TempControl控件嵌入w_1中，命名为ole_2。执行如下代码：ole_2.object.setword="开始通讯实验"结果在屏幕上TempControl控件内不但显示了“开始通讯试验”，而且后面还增加了多余 的字符。多余字符且具有一定的规律性，即总是在汉字末尾首先出现0号ASCII字符，随后有几个莫名其妙的汉字或ASCII字符。如果用户还停留在用PB6.0的时代，那您的运气将更糟(在PB6.0 调试状态执行就见不到需要的汉字，更不用说编译成exe文件后将汇合上其他众所周知的汉 字问题了)。但当SetWord为普通 可打印ASCII字符时不出现该现象。在这个简单的控件 里我们没有其他复杂的功能，只是简单地由w_1把汉字数据付予TempControl控件唯一的属性SetWord， 然后由TempControl控件显示在屏幕上。使用如此简单的控件竟有问题，因此PB6.5中给OLE控 件进行汉字付值是有一点问题。在这个问题里，Microsoft的产品也不是完美无缺的。一 般地，CString实例是不包括0号ASCII字符的。即把一组中间包括NULL(0号ASCII字符)字符的 字符串付予CString的实例时，该实例自动取NULL以前的字符们，即m_setWord就不该包括NULL 及其后面的字符。当然了，在Microsoft产品内部不存在这个问题。这个问题的解决方法 是很简单的，只需在TempControl中OnSetWordChanged()函数的开头把NULL以后的内容去掉 就可以了。但现成的商业控件就没这么轻而易举了。

 

    问题三在PB中读取到的OLE控件内部汉字数据将可能残缺不全。

    

在TempControl控件的OnSetWordChanged()中InvalidateControl() 之前加上：m_setWord="字符已变";即在控件内部改变m_setWord值。在问题二所示那行PB程 序后增加如下语句：stringwordword=ole_2.object.setwordmessagebox("",word) 运行时，对word值与“字符已变”进行对比来看，“字符”尚存，“已变”二字真的已经被变成其他莫名其妙的字符了。该问题难以补救。

 

    综合以上看来，PB6.5的OLE在汉字数据处理方面有一定的缺点。