IronPython 2.6[.1]: UI Automation: Wrong values for ControlType, AutomationElementID and more

[ironpythonbot]

Hello to all,

over many years I have forced to implement a test automation scenerie in our company.
Now they will do it and - who hat thougth that - I've got the job! And I had to bring the job to success!

My Environment:

I've succesfully presented a test automation solution only build from Internet-Software. It includes:

Keyword-Driven Tables in HTML (done with Winword)

                              !
                       Python 2.6
                              !
                  Robot-Framework
                   !                      !
         ApplTestlib.py    SeleniumLibrary
                  !                         !
          pyWinAuto       WEB-AppToTest
                  !
     WIN32-AppToTest

Later we will embed the solution in a QAtrac process.

Now it's time to test automate GUIs build from Windows-Forms and WPF too.

First I switched Python 2.6 to IronPython 2.6[and 2.6.1 RC1] and got only one, but 'very magic', bug in Robot-Framework when creating the HTML-Report-File.
Second I'm switched the pyWinAuto-Layer to Miscrosoft UI Automation (.NET >= 3.0) to support all GUI-Frameworks (WIN32, WINFORMS and WPF)

I. In IronPython all UI Automation values ControlTypePropertys (w/o the window itself) where Type 'panel'. Other values are also not the same as you can see
with UISpy or UIA Verify (Tool from Codeplex 'white'-Project). The AutomationIDs has the values from NativeWindowHandles (unique - but never the same from run to run!).
Only the NamePropertys are OK but often empty (when control has no text content yet).

II. All Controls in the window title (titlebar, menubar, menuitems, and min-, max- and close-Button) where completely hidden in Automation-Tree (I've tested with Raw-, Control- and ContentViews)! These eight controls are from IronPython-UI Automation not reachable. This may be a consequence from point I. above.

In this situation it's unpossible for me to identify Controls in the application to automate!

I have found, I run in exactly the same problems witch where reported from Jozef in November 2009:
http://lists.ironpython.com/pipermail/users- ironpython.com/2009-November/011583.html

and heself stated a own solution in
http://lists.ironpython.com/pipermail/users- ironpython.com/2009-November/011630.html

The solution reads:

'Thanks for your response.
Solution to my problem is to first instantiate AutomationElement from dll, not from IronPython.
Then all subsequent AutomationElement retrieved from IronPython looks ok.'

About 30 years I have programmed in ANSI-C (Same SW on Windows,VMS, Linux, etc.) but now being a newbie to C#, .NET and Python.

Therefore I should have an (syntax-)example for the expression:

'to first instantiate AutomationElement from dll'

Witch DLL (Own written, .NET-DLL. ??)
How to instantiate in C#?
How to transport the AutomationElement to IronPython?

The best will be if jozef.a... will give me some example lines of code from his solution in nov 2009 in C# and/or Python. Thanks.

Greetings
Wolfram

Work Item Details

Original CodePlex Issue: Issue 27606 Status: Active Reason Closed: Unassigned Assigned to: Unassigned Reported on: Jun 16, 2010 at 9:50 AM Reported by: Wolfram Updated on: Feb 22, 2013 at 2:10 AM Updated by: jdhardy

[ironpythonbot]

On 2010-06-22 06:27:49 UTC, billchi commented:

Compile a C# DLL that has a ref to UIAutomationClient and UIAutomationTypes. Create a method that returns an automation element :

public class AutoHelpers {

public static AutomationElement GetRootElt () { return AutomationElement.RootElement; }

}

[ironpythonbot]

On 2010-07-27 16:33:35 UTC, Wolfram commented:

Thanks for the advice!

Meanwhile I'm writing a C# class library (with some help of colleagues) witch will do and hold all UI Automation calls and elements.

The only problems I had where build by MS: It is the blocking of the whole test applikation, when I press/invoke a button whitch then opens a modal dialog box for confirmation. With the blocked UI client you can't confirm in the modal dialog! The MSDN solution for this problem should be to do invoke in a seperate worker thread whitch can be blocked and automate the confirmation action in the main thred with will run. Ok, the main thread now will not block, but then the dialog will not appear until you call another UI automation call (i.e. aeRootEle.FindFirst(<the dialog> to find the dialog to confirm). Now the main tread gets blocked in this call while the dialog now apeare! This does not realy help!

The next solution I tryed will help. Add a event handler for the 'windows opened' event (Automation.AddAutomationEventHandler(WindowPattern.WindowOpenedEvent, ...)) just before you invoke the button witch will open the confirmation dialog. The event handler code will run when the dialog opens and you are able to confirm and close the dialog in event code! This was the solution for me.

Greetings Wolfram

[ironpythonbot]

On 2010-09-01 17:28:52 UTC, Wolfram commented:

Now Solution REALY done!

Here's the contiuation of the story and a solution you can't imagine! . After testing the solution with event handling the event handler code runs. This was a very complicated code. First it seems it will be the solution, but when I repeated this for the next button test it failes. Then I found the code run is delayed until the tested application exits. This is very useless!

The following forum contribution gives me an idea to test the complette environment on a REAL PC:

http://social.msdn.microsoft.com/forums/en-US/windowsaccessibilityandautomation/thread/7f0bdc7c-be85-4fde-9f8a-cbb3f16ba5f4/

(see the contribution from E RaijarSekhar Reddy at Wednesday, May 05, 2010 8:00 AM)

You will believe or not! After switching my Test-PC (VMware ESXi Version 4) to my real Office-PC all my probs are gone!

Weeks of heavy developing workarounds like 1) starting the application for testing seperately in the BAT-file in front of the start of the test (because Process.Start(...) never returns)

2) working around blocking Invoke-Call with seperate Thread (will not work! because then it blocks whenn calling the next UI-Automation method).

3) Implementing 'windows opened' event handler for aplication windows, (witch works badly because the run of the event code may be delayed until the end of the test (end of RF).

REMEMBER: When you get (blocking) problems with MS UI Automation and you are on a Virtual Machine (VM), first leave the VM and switch to a REAL PC. Then you have a BIG chance to loose all problems!

Now I was sooooo happy!

But now it seems that the used DevExpress controls in your applications will not get a support for UI Automation by DevExpress. They sayed in forum we should use TestComplete because this test tool has complete suport for DevExpress controls implemented.

Therefore we must buy a very expensive (Floating Enterprise License 5k$) and heavy complex test tool. By by the easy to read Winword HTML tables and easy to write Python keywords ....

This seems to be the last contribution from me in this forum. The test story with IronPython and RobotFramework ends for me at this point ...

I will say thanks at all for their efforts to help me.

By by Wolfram from Germany.