MSAA UI Automation get_accChildCount Incorrectly R

问题:

While working on automating an Infragistics UltraTree control in a C# Winforms application I found that the UltraTree implemented the AccessibleObject model (MSAA). I was able to successfully grab the IAccessible interface by putting the hwnd grabbed from spy++ into

IAccessible* accessibleObject;
AccessibleObjectFromWindow(hwnd, OBJID_CLIENT, IID_IAccessible, (void**)&accessibleObj);

The problem is that when I now call

long childCount;
accessibleObj->get_accChildCount(&childCount);

The result that I get back is zero. From looking at the UltraTree source code I noticed that its implementation of child count should not be returning zero (verified by using windbg to inspect the fields used in the internal code). All of the other MSAA functions seem to be working correctly (such as 'accLocation').

I am stumped as to why this would be the case. I also tried using 'IEnumVARIANT' as well, but that similarly found no children even though the tree has 25 items in the collection that 'get_accChildCount' utilizes. I haven't yet tried to see if Microsoft Narrator has been able to identify the children since the machine doesn't have a sound card, but hope to get a set up to try that soon. My guess is that Narrator will find the children and there is some weird trick that I am missing.

回答1:

I had the same problem for an infragistics control. If you are able to change the application under test you have 2 options, otherwise i think there is no solution and you are trapped.

---

a) override the AutomationPeer implementation of your UltraTree, so just create your own CustomizedUltraTree. Here is a useful link on this topic Docu

---

b) contact infragistics customer support, for me it was just some versioning issue and they were pretty quick and confident.

回答2:

Kind of a crummy answer, but I ended up finding that by running under the CLR (flipping /clr on) the correct number of children is returned. So literally same exact code with the only difference being whether or not the /clr compiler switch is specified. I really don't want to run this code under the CLR though so this isn't an ideal solution for me, but it does technically answer my question.

I will have to post another question asking why this might be happening :(