TTF16.OCX控件在64位系统或/和WIN10下的使用心得

收到一些朋友咨询,没能及时查看和回复,在此写点心得,算是统一回复了吧。

笔者从1998年(没错,是上个世纪)至今,一直在使用(非商用)这个控件(版本号6.1.x),开发工具从Borland C++ Builder 3.x直到现在的Embarcadero C++ Builder 10.x,Windows从win98到64位win10。其间经历过一些问题,但是基本能够解决,过程不细述。现在说一下心得和建议。

一、到现在还使用这个控件开发新东西的,除了笔者这样的懒虫恐怕没有其他类型的人了。对这种情况的建议是:使用ComponentOne Studio for ActiveX

二、到现在还运行这个控件的,应该都是被一些老的应用系统所迫了。分两种情况:1、纯用户;2、运维人员(有源码)

对纯用户的建议是:

1、维护一个安全、稳定、完整的Windows环境。这方面最重要的一条是:一定要及时更新Windows补丁。在更换操作系统之前,要先在一个纯净的新操作系统中进行测试,以排除受其他程序干扰的原因。对于一些不专业的安装程序所导致的问题,通过regsvr32/u反注册再重新注册控件可能会解决。
2、早先,刚刚出现Win7的时候,通过将应用程序设置为管理员权限运行加Windows 98/XP兼容模式,解决了好大一部分问题。但随着Windows的不断升级,竟然不必再做这些设置了(神奇!)
3、找原来的开发公司/人员进行维护。笔者的经验,开发人员对源代码进行少量修改后一定能在新Windows上正常使用(感谢微软!“我们的兼容性可以最大限度地保障您以前的投资”绝不是一句空话)。
4、彻底、完美、成本最低的解决方案:使用WinXP/2003虚机。一个这样的虚机,其启动速度比现在的大多数应用都快!

对运维人员(有源码)的建议是:

1、在相应的Windows环境下,使用尽可能高的版本的开发工具重新编译。这通常会解决绝大多数问题。
2、剩下的问题,通过单步跟踪调试,可以定位导致问题的方法/属性调用。尝试改变方式,最终都可以解决。例如笔者曾经通过WideString初始化方式、自写Unicode粘贴板函数、表单和列名汉字初始值等解决了Windows升64位、升win10带来的一些问题。
3、彻底、完美、成本最低的解决方案:部署WinXP/2003虚机模板分发给用户(呵呵!)
 

上一篇:nacos client 产生大量 time wait和close wait 解决方案


下一篇:0102 64位整数乘法(快速乘)