none
Limitations with mixing UI Automation with IUI Automation in a test harness?

    Question

  • Posted in another forum, but upon further investigation this seems to be a more appropriate place:

    I had developed a test harness in C# using Visual Studio 2010 and UI Automation. 

    I later discovered the limitations of UI Automation and sought to include support for IUI Automation via a COM-wrapper created by tlbimp. 

    Rather than convert the entire harness over to utilize IUI Automation, I decided to implement both side-by-side in the same harness.  Automation Element Properties and Control Type properties are stored in an XML file, and based on the stored Control Type, I can force code to utilize either IUI or UIA for a given test step thus allowing me to mix and match calls to UIA vs. IUI.  This allows me to leave our "legacy" tests that work just fine with only UIA support alone, but still support objects where IUI seems to be a better choice.

    Or so I thought.  It turns out, once I make any call to UIA, the IUI logic begins failing the next time I use it.  If I include only IUI calls in a given test run, everything works just fine.

    Are there known limitations of doing a similar mix and match of automation methodologies?  I suppose if I need to convert the harness over to exclusively use IUI, I can, but the project becomes a lot more effort as I need to ensure I am not breaking the existing tests that previously work wonderfully through just UIA.

    Here's an example of the type of problem I'm encountering.  We have a WPF application using Infragistics buttons.  The Infragistics buttons are not accessible via UIA, but are accessible through IUI.  If I build a test case utilizing only IUI calls, I can retrieve the following list of buttons (Name property) by walking the IUI ControlView:

    Refresh
    Expand
    Collaps
    Splitter Bar
    User Management
    Security Policy
    Audit Reports
    Configure Buttons
    Column left
    Page right
    Column right
    Refresh
    New User
    Delete
    Undelete
    Lock
    Unlock
    Logout
    Restore Layout
    Minimize
    Maximize
    Close
    ApplicationMenu Button

    I can retrieve this list with subsequent IUI calls.  As soon as I enter the UIA portion of code, the very next call to IUI is missing a number of objects:

    Splitter Bar
    User Management
    Security Policy
    Audit Reports
    Configure Buttons
    Column left
    Page right
    Column right
    Minimize
    Maximize
    Context help
    Close

    Any ideas?  Is there anything I can do to "reset" my test harness following a call to UIA so that the subsequent IUI calls will behave as if UIA was never instantiated?  I really need to get at these controls that IUI can see, but I'd rather not need to convert everything over to IUI and force a significant retest effort.  Any thoughts are greatly appreciated.

    Regards,

    Rusty

    Wednesday, March 05, 2014 8:43 PM

All replies

  • I had developed a test harness in C# using Visual Studio 2010 and UI Automation. 

    I later discovered the limitations of UI Automation and sought to include support for IUI Automation via a COM-wrapper created by tlbimp. 

    Rather than convert the entire harness over to utilize IUI Automation, I decided to implement both side-by-side in the same harness.  Automation Element Properties and Control Type properties are stored in an XML file, and based on the stored Control Type, I can force code to utilize either IUI or UIA for a given test step thus allowing me to mix and match calls to UIA vs. IUI.  This allows me to leave our "legacy" tests that work just fine with only UIA support alone, but still support objects where IUI seems to be a better choice.

    Or so I thought.  It turns out, once I make any call to UIA, the IUI logic begins failing the next time I use it.  If I include only IUI calls in a given test run, everything works just fine.

    Are there known limitations of doing a similar mix and match of automation methodologies?  I suppose if I need to convert the harness over to exclusively use IUI, I can, but the project becomes a lot more effort as I need to ensure I am not breaking the existing tests that previously work wonderfully through just UIA.

    Here's an example of the type of problem I'm encountering.  We have a WPF application using Infragistics buttons.  The Infragistics buttons are not accessible via UIA, but are accessible through IUI.  If I build a test case utilizing only IUI calls, I can retrieve the following list of buttons (Name property) by walking the IUI ControlView:

    Refresh
    Expand
    Collaps
    Splitter Bar
    User Management
    Security Policy
    Audit Reports
    Configure Buttons
    Column left
    Page right
    Column right
    Refresh
    New User
    Delete
    Undelete
    Lock
    Unlock
    Logout
    Restore Layout
    Minimize
    Maximize
    Close
    ApplicationMenu Button

    I can retrieve this list with subsequent IUI calls.  As soon as I enter the UIA portion of code, the very next call to IUI is missing a number of objects:

    Splitter Bar
    User Management
    Security Policy
    Audit Reports
    Configure Buttons
    Column left
    Page right
    Column right
    Minimize
    Maximize
    Context help
    Close

    Any ideas?  Is there anything I can do to "reset" my test harness following a call to UIA so that the subsequent IUI calls will behave as if UIA was never instantiated?  I really need to get at these controls that IUI can see, but I'd rather not need to convert everything over to IUI and force a significant retest effort.  Any thoughts are greatly appreciated.

    Regards,

    Rusty

    Wednesday, March 05, 2014 7:05 PM
  • Hi,

    What is ‘IUI Automation’?  Is it another accessibility framework like UI Automation? Did you develop such automation technology yourself?

    Could you describe ‘IUI Automation’ in details so that we can further know your scenario?

    Is ‘tlbimp’ the tool: Tlbimp.exe (Type Library Importer)?

    Thanks,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, March 06, 2014 6:19 AM
  • Hi,  Thanks for your reply.  Maybe my terms are not completely clear.

    When I write IUI I mean the unmanaged Windows 7 UI Automation API.

    Here is the IUIAutomationElement interface here

    Here is a simple example that shows IUIAutomationElements in action, as well as the way to generate an interop dll to access the unmanaged API from within C#.    here

    And with UIAutomation, I am referring to the managed MSAA proxy accessible via AutomationElement Class.

    Hope this clears things up.


    • Edited by rustoleum Thursday, March 06, 2014 6:25 PM
    Thursday, March 06, 2014 6:23 PM
  • Hi,

    Thank you for you detailed information.

    Based on your description, your issue is not related to visual studio testing itself, and I think that it is more related to UI automation implement.

    I notice that you post a new thread at Windows Desktop Development for Accessibility and Automation forum: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/d8ac8237-7930-4073-86f3-35cc0e0db84e/limitations-with-mixing-ui-automation-with-iui-automation-in-a-test-harness?forum=windowsaccessibilityandautomation#d8ac8237-7930-4073-86f3-35cc0e0db84e, which is a correct forum. Then I will merge this thread to that thread.

    Thank you for your understanding.

    Best regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, March 07, 2014 3:05 AM