Did this article resolve your question/issue?


Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025



Critical Alert – Issues migrating applications that use ActiveX/COM objects to OpenEdge 11.

« Go Back


Article Number000028532
An issue has been identified in OpenEdge 11 where 3rd-party ActiveX controls that worked correctly in previous versions of OpenEdge (OpenEdge 10.2B and earlier) exhibit erratic behaviors of different kinds.  This is due to an issue involving the third-party ActiveX control and the operating system and is not due to any bug in the OpenEdge product.
The exact symptoms of erratic ActiveX behavior will vary – the ActiveX controls may function at design time but fail to display at runtime, or the client session may crash in some environments but not in others (such as 32-bit vs. 64-bit Windows version, physical vs. virtual machine). What these issues all have in common is that they occur only when running more recent Windows versions (Vista, 7, 8.x, 10, 2012, etc). On older Windows versions (e.g. Windows XP) the application will run as expected.

OpenEdge Development's investigation has found that despite the different symptoms that are exhibited, and despite the different 3rd-party components that are involved, these issues all share a common cause that lies outside of the OpenEdge product: The ActiveX objects have some conflict with the current versions of Microsoft’s security features. Any executable compiled in Visual Studio 2010 with the default project settings, specifically for the /NXCOMPAT linker flags, can run into these issues. 
The reason that this issue has come to light only beginning with OpenEdge 11 is because with OpenEdge 11, Progress Software switched over to Visual Studio 2010 as its compiler platform. In addition, the OpenEdge product is compiled with /NXCOMPAT:YES to ensure Data Execution Prevention (DEP) compliance.
This finding has been confirmed by noting that when the disrupted ActiveX controls are used within Visual Studio 2010 directly, with OpenEdge entirely out of the picture, the same erratic behaviors result. For example, if the control is invisible at runtime in OpenEdge 11, it is also invisible at runtime in a Visual Studio project. If the control causes the AVM to crash in OpenEdge 11, it also causes Visual Studio to crash.

Progress Software strongly recommends that customers who are planning to upgrade to OpenEdge 11 and who are using 3rd-party ActiveX controls in their applications should verify that the versions of those controls are certified to work with Visual Studio 2010 and the Microsoft DEP. If the versions the customer is currently using are not certified then they should then work with their ActiveX vendor to identify a migration path.
If no upgrade path is available for the disrupted controls, Progress Professional Services can assist in identifying and implementing an alternative approach to resolve the situation.
Additional Information
Last Modified Date7/27/2016 3:35 PM