Did this article resolve your question/issue?



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

« Go Back


TitleCritical Alert – Issues migrating applications that use ActiveX/COM objects to OpenEdge 11.
URL Name000028532
Article Number000189649
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
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.