带你轻松了解PB6.5中OLE控件的三个缺点

PB6.0在汉字方面有问题,因此利用Sybase公司免费提供的PB6.5补丁程序进行升级是PB6.0用户较现实的选择。但笔者在用升级后的PB6.5开发一个需串口操作微机数据库项目的过程中,发现PB6.5中的OLE(Microsoft喜欢叫她ActiveX)在汉字方面仍存在一些问题。

首先在PB中创建一个窗口w_1。

问题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将正常运行。

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

利用VC++5.0的MFC ActiveX Controlwizard的所有默认选项创建一个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中给 控件进行汉字赋值是不方便的。

在这个问题里,Microsoft的产品也不是完美无缺的。一般地,CString实例是不包括0号ASCII字符的。即把一组中间包括NULL(0号ASCII字符)字符的字符串付予CString的实例时,该实例自动取NULL以前的字符,即m_setWord不包括NULL及其后面的字符。当然了,在Microsoft产品内部不存在这个问题。这个问题的解决方法是很简单的,只需在TempControl中OnSetWordChanged()函数的开头把NULL以后的内容去掉就可以了。但现成的商业控件就没这么轻而易举了。

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

在TempControl控件的OnSetWordChanged()中InvalidateControl()之前加上:

m_setWord="字符已变";

即在控件内部改变m_setWord值。在问题二所示那行PB程序后增加如下语句:

string word
word=ole_2.object.setword
messagebox("",word)

运行时,对word值与"字符已变"进行对比来看,"字符"尚存,"已变"二字真的已经被变成其他莫名其妙的字符了。该问题难以补救。

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