Clash of OLE controls (OpenInsight 32-Bit)
At 15 JAN 2010 07:42:33AM Martin Drenovac wrote:
We've just recently started to migrate our main application to 9.1.1, and have struck a major hurdle. We use a number of SRP controls, and now under 9.1.1, the OI environment just clocks out & goes into a 50% cpu grab.
We have spent the better part of a 1/2 day tracing routine for routine against our 8.0.8 version, and we're clear that the call into the SRP ole control is causing the OI environment to seize.
Just looking for advice as to how to track this down and how to move forward to get this corrected. Everything works under 8.0.8 and now it doesn't so what can we hope for?
Environment is Vista & 8.0.8.
TIA
At 18 JAN 2010 08:44PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Martyn,
When you say "call into OLE" what do you mean? Are you setting a property or are you responding to an event? If it's an event are you listening to it in synchronous fashion? Is this all OLE controls or just the one?
World leaders in all things RevSoft
At 19 JAN 2010 12:34AM Martin Drenovac wrote:
Cheers guys - here's a quote from my developer:
We have just upgraded our app from an OI 8.n to 9.1 and now when we launch the app it gets stuck on this line:
Set_Property(wshortcut, "OLE.AutoReposition", true$)So, it's just one control - the others all work fine, and all works fine in 8.x, therefore we're confused on how to move forward and debug.
Cheers
At 19 JAN 2010 03:15AM [email protected]'s Don Bakke wrote:
Since this involves an SRP ActiveX control we were working with Martin to try and identify the problem offline. However, since there are now questions being raised by this I'll report what we've discovered here in hopes that Revelation might point us to a resolution.
The ActiveX control in question has a method that allows OI forms to be embedded within it. A prerequisite for this feature is to turn off all style bits related to borders and menus (so the internal contents of the form can appear seamlessly within our control.) Then we set the parent of this OI form to be the ActiveX control.
We discovered that a form with no controls will embed without any hanging. The moment any control (even just a static label) is on the form the hanging effect happens.
We've concluded that the hanging is not occurring in our control. The stack trace in Visual Studio looks like this:
NTDLL
USER32
USER32
OENGINE
At this point we are unsure what OI is doing.
At 20 JAN 2010 11:24PM [email protected] wrote:
Don,
Can you glean any further information from tracing Windows messages?
Battlestar Sprezzatura - BSG 77
Colonial leaders in all things RevSoft