Cannot access container in visual studio but Spy can see it

[chrisgeorge]

I am trying to access controls of one of our own Progress dialogs. Most of the controls are fine, but two containers are eluding me.

The containers in question are usercontrol's, whereas all of the other controls are standard windows forms controls.

Spy picks it up fine and displays it as a container, correctly listing it's children etc.

However in Visual studio, I cannot access it as a container, and iterating through the children there are two "Unknown" elements that can only be these two user controls.

I am raising this as an issue because Spy can detect it fine, but usign the libraries through visual studio cannot.

I can't provide a test application at the moment, although should be unable to find any issues around this area, I might be able to provide one.

Chris

[Support Team]

Ranorex Spy internally uses the Ranorex Core, so if Spy can identify these elements, you should be able to achieve the same using the Ranorex library, too.

Please make sure that:

• all threads using Ranorex have STA apartment state
• you do not start your Ranorex executable from an untrusted location, that is e.g. a network drive, an encrypted folder, sometimes even a folder in the "Documents and Settings" (Windows XP)/"Users" (Vista) directory (depends on Windows user rights)
• (on Vista) the automating process has the same security permissions as the automated process
• (on a 64 bit operating system) the bit width of the automated and the automating process are the same (see http://www.ranorex.com/support/user-gui ... forms.html)
• you have the latest Ranorex version

It would certainly help to know the Ranorex version and the operating system you're using!

Regards,
Alex
Ranorex Support Team

[chrisgeorge]

Ranorex 2.1.4
OS : XP SP3 32bit
Visual Studio 2008.
The project is set to use STA apartment state

The controls in question are in the Program Files directory for our product, but then I can access other controls (such as dev express) whose libraries also reside in this directory.

What permissions do they need to have? This is the only thing that I can think of aside of it being a bug in ranorex...

Cheers

Chris

[Support Team]

The controls in question are in the Program Files directory for our product, but then I can access other controls (such as dev express) whose libraries also reside in this directory.

I did not mean the location of the controls you are automating, but the location of the Ranorex executable you create. The generated Ranorex exectuable must not reside in an untrusted location.

What permissions do they need to have?

The automating process (your Ranorex executable) needs to have at least the same permissions as the automated application, i.e. both processes need to be started using the same user account.

This is the only thing that I can think of aside of it being a bug in ranorex...

Did you try accessing these controls using a plain and simple Ranorex console application? If Ranorex Spy is able to access those controls, there is for sure a way you can do that in your Ranorex executable, too!
Please try to create a Ranorex console application using Ranorex Studio and make a simple recording that interacts with these controls. The compiled executable should be able to access the controls just like Ranorex Spy.

Regards,
Alex
Ranorex Support Team

[chrisgeorge]

Hmm ok...

I tried creating an exe in Ranorex studio which worked fine.

I then ported the code over the visual studio... which worked fine

I then retried my original code... and that worked too.

Very confused now. I do think that either our control or ranorex is occaisionally misreporting the controls as I have seen the usercontrols reported as Containers or Elements.

I will be working alot with these controls today so if it happens again I'll post more details...

[chrisgeorge]

Right, found out what the problem was!

For the most part I've been running an installed (Release) version of our sql server management studio add-in. But in the directory that contained the test assemblies was also the product assemblies, built as Debug versions.

It seems that Ranorex was trying to access the (release build) controls using the debug assemblies in the build directory, and this was not working well.

When it started working, I had accidentally re-registered the add-in using the debug build of the product, so the debug assemblies matched up, hence it worked fine!

We are trying to ascertain whether developing the tests under debug, then building a running them under Release will work ok, but for now I think the mystery has been solved!

Sorry for blaming Ranorex

Chris