IUIAutomation Getting Read-Only Selected Value from Combo Box

[Kharizmah]

Back from break...

@junkew Is there anyway using your wrapper or autoit to enable the comboBox, so I can search the children, then disable it again?

I tried :

$findThis.GetCurrentPropertyValue($UIA_ControlTypePropertyId, $controlID)

GUICtrlSetState($controlID, $GUI_ENABLE)

,which does not work.  The control does not get enabled.  The controlID is reported as 50003.

I even tried to change the control ID  back to Hex and Enable to no avail. 

 

[junkew]

Nope in general thats not possible unless the developer has a major defect on his control. So not possible. What is your endgoal and benefit if you could do this? 

[Kharizmah]

@junkew

The endgoal is that I can select the comboBox and see the child elements. Thereby, getting access to the Read-Only selected value  of the comboBox.

The combo Box is tricky.  Even if it's enabled I can't seem to get the value displaying under UIA_SelectionSelectionPropertyId in UISpy.  If it's enabled I have to Expand the comboBox, choose the child element and verify that it is selected via UIA_SelectionItemIsSelectedPropertyId.

 

Edited January 6, 2016 by Kharizmah

[junkew]

If its enabled the virtualized item list could be tried but so far i never used that as i can live with a combobox that i expand first. Is it a bought application or can you discuss with the developers that they should adhere to accessibility standards from microsoft.

What is the purpose of knowing values of a disabled control? As an enduser you can also not see it.

 

[Kharizmah]

I'm not sure why they couldn't have just used a Read-Only textBox.  Then I could access the value.

The purpose was so that when the user makes a change to the object this field would display a value that's part of an enumerated list.

The user can view this value but not change it.

The problem is I'm fighting for support on automating tests via UI and not all the developers are pro-Automated testing.  

[junkew]

So ask the manager to fire those developers as people with eye disabilities need accessibility for screenreaders. Show those developers tools like JAWS, narrator, NVDA. Still not listen then teach them scrum agile devops and concepts of continuous integratiion.

But if I read it properly you can do the ui test like an enduser. Looking into the disabled combobox to know if the values are there is more a unittest. I certainly doubt that the requirement on whats in the list of a disabled combobox is defined. So if you could read it and conclude the list is empty developers will not accept it as an issue.

[Kharizmah]

Ha! Like I have that kind of power.  

I talked with both lead developers, after really looking at the code design and they recommended holding off on the automation for that feature since it's still in transition.

However,  I still feel like that since UISpy shows the binded data, that there should be some way to access it.  So I'll continue to bang my head into the wall until I figure that out.

 

Edited January 7, 2016 by Kharizmah

[LarsJ]

UISpy is a very old program. It's probably based on Accessibility code. It might be worth a try to extract data with pure Accessibility code instead of UI Automation code.

[junkew]

@Kharizmah: You have more power then you think. In the past I invited a blind person to give a presentation on difficulties that person had with software to our team: managers and developers and testers. Then colleagues are impressed and never forget how important it can be for people.

• If UISpy is getting it I am really surprised as I am unable to get to it with the IUIAutomation simplespy and not with inspect.exe either
• I downloaded UI Spy and reproduced what you are saying and you are correct and I am convinced you could reach it thrue the IUIAutomation stuff
• Inspect.exe indeed seems not to have all the good stuff of UISpy like getting the patterns. Shame on Microsoft that they discontinued and neither published the source of the uispy after discontinuing it

Based on some investigation I did I think code in ex1_treewalker.au3 could have the solution elements
There are basically two ways to get your elements with a treewalker or with the findall functions.

Quick test (But make sure you close all your browsers as it starts printing all elements so preferably only scite to run the script and your application)

ConsoleWrite("**** Desktop windows ****" & @CRLF)
findThemAll($UIA_oDesktop, $TreeScope_Subtree)

Otherwise you should make a script which (recursively) walks thru your application

As far as I am aware all ways of reading information are in the IUIAutomation thread

1. IUIAutomation new accessibility framework from Microsoft
2. IAccessible the first standard of Microsoft
3. IAccessible2 the extended standard
4. ISimpleDom an accessibility model from Chrome (my preference is IUIAutomation on chrome so far)
5. JAVA widgets search for JABSimpleSpy    

The ones not in the thread

1. Internet Explore SHDOCVW and MSHTML   (For that you can use IE.UDF although 80% of this can also be reached with IUIAutomation)
2. FF.AU3 specifically interaction to read firefox  (80% of this can also be reached with IUIAutomation)
3. CHROME.AU3 specifically interaction to read chrome  (80% of this can also be reached with IUIAutomation)
4. reading directly from UAT, EXE, Resource, Memory, Disassembly, reverse engineering the exe, debug attaching a running proces                   

 

 I did in the end find UISpy.exe over here

http://kb.froglogic.com/display/KB/Getting+information+about+toolkits+and+GUI+controls+(Windows)

I tried: Interesting message: 

UISpy is running with limited user access (LUA) . This will prevent UISpy from accessing UI Automation details from applications running with higher privilege. See UISpy documentation for further details.

I am able to reproduce your problem with a small demoapp I made with 1 enabled combobox values a,b,c,d and 1 disabled z,y,x running under windows 10

Indeed UISpy can read also the disabled one 

The default view in UISpy is the Control View,but I get same result with content, custom and raw view.

Interesting part is that this learns me that UISpy is also based on the IUIAutomation stuff

 

 

 

 

[junkew]

Normally | do not install untrusted stuff but as I am intriged with this problem I installed this

http://download.cnet.com/Automation-Spy/3000-2218_4-76237747.html

It also a spy based on Automation lib of Microsoft and shows indeed also the stuff of the disabled control. So 99.99% it can be done with IUIautomation and that inspect.exe is not showing things that actually can be shown

and if its a wpf application that can help https://snoopwpf.codeplex.com/ and as my demoapp is a wpf app to my surprise you can enable the disabled control remotely with snoop spy tool

and unfortunately for whatever reason now my uispy is behaving same as inspect.exe. Both cannot see the disabled comboboxitems.

[junkew]

To answer your original post:

Yes, you can but however its not easy in one piece of code (I made 2 small demo apps to understand the stuff one in WPF and one in WinForms)

• UISpy, Inspect and Simplespy can look into enabled and disabled lists if from type WindowsForms10.COMBOBOX.app.*
  However UISpy seems to see it quicker then inspect (inspect only sees it after userinteraction with the combobox so indeed seems to be virtualized item logic)
• They all cannot read a disabled combobox control if its a WPF application from type ControlType.ComboBox
• Automation spy and SNOOP works with .NET injection libraries from the inside of the app as such it can see more and with 
  https://msdn.microsoft.com/en-us/library/ms173183.aspx reflection library all things can be manipulated (under assumption developers are not protecting it)
• After triggering stuff with SNOOP (enabling/disabling a combox all tools can see stuff), so when validating make sure you always start with a restart of the app and restart of your UISpy and Inspect tooling

So inject the SNOOP DLL from GITHUB from AutoIT into your application and you can see more and even enable/disable your combobox.

• @Trancexx and @Monoceres
  made some threads on this but you need the more experienced people. Its to difficult for me in AutoIT (C/C++ is more my area to do this and less the more complicated way in AutoIT)

 

[Kharizmah]

 

@junkew I thought about using Snoop as a work around, but not using it as a hook, but sort of automating snoop to enable/disable the combobox.

However, I'm not sure that is the cleanest technique. The developers were talking about me creating a custom reflection group specifically for this, but I still say that having the comboxBox disabled in Global View of the entire process really makes me see it as poor design.  The Combo Box was designed for user interaction, not as as an enumerated inaccessible display. 

I'll have to seriously look into using the Snoop.dll api using the hook method.  Looks overwhelming at first glance, so I'll play around with it and let everyone know how it works.

@LarsJ I'll also look into using IAccessibility verses IUIAutomation and see if that makes any difference.

What you see Isn't what you get

To comment on one of the previous forum links https://social.msdn.microsoft.com/Forums/vstudio/en-US/68339ec2-7d62-419f-963d-f2cd8172db3f/automation-disabled-combobox-has-no-value?forum=wpf you posted. Microsoft stated:

This seems to be the case when I call for $findThis.GetCurrentPropertyValue($UIA_SelectionSelectionPropertyId, $selection).

What irritates me is that whether it is UISpy or Inspect.exe- despite what Microsoft says in this forum- I do not see 

Selection:    ""list item" """

I see 

Selection:    ""list item" "flat"

so that it reports as NULL is frustrating as you mentioned :

Edited January 11, 2016 by Kharizmah