DSOFramer is an ActiveX component provided by Microsoft for Online Editing and calling Office programs such as Word and Excel. Many third-party Office components are developed based on the DSOFramer component. Today, we will not talk about how to use DSOFramer components. There are already many articles on how to use DSOFramer components on the Internet, but some pitfalls in using DSOFramer components for development.
The full name of the DSOFramer component is dsoframer. ocx. All articles about how to use the DSOFramer component will tell you that to use the DSOFramer component, you must first register the component in the Windows operating system. The registration method is simple:
After the registration is successful, the Windows operating system prompts "DllRegisterServer is successfully registered in dsoframer. ocx ".
.
So far, everything has gone smoothly. However, if you use a 64-bit Windows operating system like me, you will not be aware of it. Why? Let's continue.
Suppose we have compiled a program to call DSOFramer. What will happen when we run the program? "Success "! Yes, that's right. The system prompts "exceptions that cannot be handled by applications ".
Why is this error? Haven't we registered dsoframer. cox in the system32 directory? Why does the system prompt "no registration class?
Yes, the problem is here. If we use a 32-bit Windows operating system, OK and the program will not have any problems during running. Unfortunately, I am using a 64-bit Windows operating system. If you use a 64-bit Windows operating system, you may find that in addition to the common system and System32 directories in the % windir % directory, there is also a SysWOW64 directory. In a 32-bit Windows operating system, the System32 directory is used to store 32-bit DLL, while in a 64-bit Windows operating system, it is said that to maintain downward compatibility, the System32 directory is used to store 64-bit DLL, the newly added SysWOW64 is used to store compatible 32-bit DLL (although the effects of System32 and SysWOW64 directories should be completely different ).
The preceding exception occurs because DSOFramer is a 32-bit component. Therefore, in a 32-bit Windows operating system, copy it to the System32 directory for registration; In a 64-bit Windows operating system, copy it to the SysWOW64 directory for registration, instead of copying to the System32 directory.
In a 64-bit Windows operating system, copy dsoframer. ocx to the SysWOW32 directory and use regsvr32 to register the component. Then, when running the program, there will no longer be "no registration class" exceptions.
In addition, you must note that in Visual Studio compilation options,Target CPUThe default option is Any CPU. In many cases, we will not change this default setting, but decide how to load the program according to the system environment at runtime by. net framework JIT. However, because DSOFramer is a 32-bit component, you should set the target CPU in the compilation optionX86. In this way, the registered DSOFramer component can be found in the correct position during the program running.
Therefore, when using the DSOFramer component, the best practices are:
In SysWOW64, "WOW64" means "Windows on 64-bit Windows ". Therefore, you will understand why dsoframer is used in 64-bit Windows. the ocx component is copied to the SysWOW64 directory because it is a 32-bit DLL component running on "64-bit Windows (32-bit) Windows.