Recognition of COM (ActiveX) Interfaces

Technology specific object identification, supported applications, web technologies, and 3rd party controls.
frank1914
Posts: 3
Joined: Mon May 30, 2011 1:26 pm

Recognition of COM (ActiveX) Interfaces

Post by frank1914 » Mon May 30, 2011 2:07 pm

Hello,

I'm currently evaluating Ranorex on a Win 7 64-bit (VM) environment. A key part of our application is a 64-bit ActiveX control that functions as an image container and exposes a set of properties and methods. In our 32-bit environment our current automation tool can successfully identify this interface and we're able to get and set properties and invoke exposed methods. These controls are hosted both within IE as well as within explorer.exe (the desktop explorer process) that embeds a web browser control.

Unfortunately there is as of yet no native 64-bit version of that tool and its 64-bit object recognition is limited to viewing the control as a generic window object.

I'm running the 64-bit Ranorex Spy and Recorder and the controls do appear to be recognized as containers of some sort and all the intermediate objects (mostly shell views) appear as well - which is very encouraging.
However, the interface itself is not being recognized.

My first question is, does Ranorex have the ability to recognize and interact with 64-bit custom COM (ActiveX) interfaces and, if so, is this something the tool supports natively through some configuration or 'Add-In' component?

As our current workaround, I've written a C# COM+ app that functions as a bridge between our 32-bit automation tool and our 64-bit application. Having knowledge of the app I can import a reference to the interface and get at the control through the underlying HTML DOM. This works when the controls are hosted directly on a page in IE.

However I cannot get it to work with the more complex object hierarchy in explorer.exe. In this case the controls are not directly accessible through the DOM but are instead child objects of custom ShellView objects that don't exposed the interface I need. I can identify the handle of the image container I want, but I can't see any way to get the interface from that handle.

My second question is can Ranorex be used within Visual Studio 2005 in a way that exposes its object recognition capabilities to C#?

Any help or ideas would be appreciated and I apologize for the long post.

Thanks,
Frank

User avatar
Ciege
Posts: 1336
Joined: Thu Oct 16, 2008 6:46 pm
Location: Arizona, USA

Re: Recognition of COM (ActiveX) Interfaces

Post by Ciege » Tue May 31, 2011 7:40 pm

First off, yes Ranorex can be used within Visual Studio, that's how we operate here (using VS 2008).

So if your AUT has a valid COM object you should only need to make a reference within Visual Studio to that and then you will be able to use the interface that your AUT provides.
If this or any response has helped you, please reply to the thread stating that it worked so other people with a similar issue will know how you fixed your issue!

Ciege...

frank1914
Posts: 3
Joined: Mon May 30, 2011 1:26 pm

Re: Recognition of COM (ActiveX) Interfaces

Post by frank1914 » Tue May 31, 2011 8:02 pm

Thanks for the reply Ciege.

The short answer is yes, I'm able to access our ActiveX control by referencing the interface library within my C# project. That's my workaround and I can do that without Ranorex in the picture.

What I was expecting is for Ranorex's inspector/spy tool to pick up that interface so that I could record/compose tests directly using the tool.

32-bit QTP has that ability with its ActiveX Add-In. From what I'm seeing 64-bit Ranorex does not.

- Frank

User avatar
Ciege
Posts: 1336
Joined: Thu Oct 16, 2008 6:46 pm
Location: Arizona, USA

Re: Recognition of COM (ActiveX) Interfaces

Post by Ciege » Tue May 31, 2011 8:10 pm

Ah OK... I get your question now. Personally, I don't have any internal ActiveX controls that I need to deal with. However, according to the Ranorex supported technologies, ActiveX is supported.

I guess what would need to be done is wait for Ranorex support to comment and you (if possible) could provide their team with your AUT so that they can determine what is or is not working properly with your AUT and help you out getting it taken care of. They are good like that!
If this or any response has helped you, please reply to the thread stating that it worked so other people with a similar issue will know how you fixed your issue!

Ciege...

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: Recognition of COM (ActiveX) Interfaces

Post by Support Team » Tue May 31, 2011 8:37 pm

Hello Frank,

ActiveX is a set of COM interfaces. Ranorex on the other hand parses the GUI for different technologies (Win32, Msaa, Web, MozillaWeb, Wpf, WinForms, Flex, Office, RawText), not COM interfaces. So ActiveX is not supported as such. It's only if native window handles are used by the ActiveX control, then these will be recognized through the Win32 plug-in. Similary the ActiveX controls could support MSAA, then the MSAA plug-in would find elements within the ActiveX control. In general this will not be the case, though.

Regards,
Roland
Ranorex Support Team

frank1914
Posts: 3
Joined: Mon May 30, 2011 1:26 pm

Re: Recognition of COM (ActiveX) Interfaces

Post by frank1914 » Tue May 31, 2011 10:06 pm

Thanks Roland for being upfront about the lack of ActiveX support.
I've had to dance around with other vendors who claim their products have it until I demonstrate otherwise.

I'm a COM/ATL developer and I'm aware of the internals of the controls and what the issues are. As I mentioned I've created a workaround in C# to bridge our 64-bit app and our existing 32-bit automation tool.

One issue is leveraging the large VBScript framework we've developed in house and this allows us to do that.

Other issues are more organizational:

We're not just looking for a unit test tool that embeds with Visual Studio. We need something we can roll out on literally hundreds of physical and virtual desktops to do full system testing. We can't justify that number of Visual Studio licenses (and we're regulated by the government so we have to play nice with licensing).

The other issue is in-house automation skills. Aside from myself the other members of our automation group have primarily a scripting skill set. Porting our framework to a .NET language would be fine by me but would place a learning burden on the others that management is not conmfortable with.

Our assumption is that HP will eventually get a 64-bit app out in the market that will perform comparably to their 32-bit app - but they seem to be in no hurry to do so and I'm sure we're not their only customers who are unhappy about it and beginning to look elsewhere.

But they do have this ActiveX recognition - at least on 32-bit - that's a critical part of our testing.

Thanks again and I'll keep you guys in mind down the line,
Frank