描述:
我没专门做过Unicode开发。最近从过去一个上万行的程序改了一个ActiveX控件，不是Unicode版本，这个ActiveX提供的接口的参数类型是short*类型的。我另外做了一个本地示例接口程序，可以提供ANSI和Unicode之间的转换，通过这个本地程序提供接口函数，可以间接利用这个ActiveX处理Ansi和Unicode数据。
现在客户提出要在Web服务中用这个ActiveX控件，我查了查资料，在Web服务中使用的ActiveX控件大概需要做成Unicode版本的。这两天我试了试进行修改，感觉工作量很大（因为核心代码有不少于5000行，大量是C代码，有一些来源也比较混杂，即使是原来的ANSI版，也有好些地方是专门修补后才编译通过的），另外我也不太熟Unicode。
所以有一个想法。能不能另做一个Unicode版的外包ActiveX，只是提供个壳，把这个ANSI版ActiveX控件直接包进来，再改编原来接口程序中的转换代码，包出一个提供Unicode接口的版本，再做成Unicode编译版。如果这样做的话，实质的代码量顶多也就两三百行。
我没有什么Unicode开发的经验，请有经验的朋友谈谈是否可行。
另外，原来的那个ActiveX除了少量读写一些硬盘文件数据和少量读写注册表外，都是内部操作。
解决方案1:
对于COM组件是不支持继承,但是对于COM组件是支持包容和聚合的,针对你这样的特殊情况,可以采取对COM组件进行包容处理,将原本的COM组件包进一个新的COM组件内部,对于新的COM组件对外提供Unicode版本的接口,而在内部对接口数据进行Unicode和ASCII的转换,同时在内部完成对包容组件的接口查询调用,将返回数据重新加工后返回最终的外层接口.
从理论上说这是完全可以实现的.
你可以参考有关COM组件包容的处理程序和文档.在这里聚合不能解决你这个问题,所以只能采取包容来处理.