Silverlight Object hierachy becomes misaligned/jumbled when scroll methods are invoked.

I've noticed this as well, but it hasn't stopped me selecting the item I want. I usually use FindChild on the list/combobox, looking for an item with NativeUIAObject.Name equal to the string I'm looking for. Then I call AddToSelection on whatever object is returned. If I have to scroll the list, I refresh it afterwards and call FindChild again. It's always worked for me.

Thanks for your reply Tony,



I do exactly what you've mentioned. Once the hierachy becomes jumbled, it remains jumbled no matter what you do.

I can even reproduce this my manually scrolling up and down the list box.



If I only needed to select an item, and not revisit the listbox, this would be fine. But when I revist the listbox, I can't select the item i need to.



I'm hoping that AQA can resolve this asap.



Thanks



Evan

You do exactly the same thing? From your first post it looked like you were looking for the TextBlock containing the string you wanted and calling AddToSelection on its parent. If the tree has been rearranged, the Parent property might not be reliable. My method is to ignore the TextBlock in favor of the "NativeUIAObject.Name" property of the ListBoxItem itself. That way, the object returned by the search is the same one you call AddToSelection on, and you don't have to rely on the Parent being correct and up to date. That method should always work, regardless of how "jumbled" the tree has become.



I'm not sure what you mean by revisting the listbox, but you should always search for the item you want, rather than trying to reuse a reference to the item from an earlier part of the test. Silverlight is free to reorganize and reuse the objects within list and combo boxes, so you can rarely assume that an old ListBoxItem reference is still good.

Our List Items contain several/multiple TextBlocks. We need to identify an list box item, by its the name/content of it'sTextBlock.(it's child object)



By revisiting, I mean going back to the list box and trying to select another item.

I don't use any existing references.



The mixing up of the object hierachy is clearly a TestComplete issue.

This is proven since after completely shutting down and restarting TestComplete, the hierachy is correct.



The problem does not allow me to verify that an item is selected in a listbox because I can only recognise an item by its child (a textblock) and it's parent is incorrect.



Evan

Ah, multiple TextBlocks in each item, so the NativeUIAObject.Name is probably just a class name that's the same for all items, right? Tricky.

I agree that TC does have problems with Silverlight objects, and it certainly needs work, but I've found that it's not always as bad as it appears. It seems to me that the real problem lies with the Object Browser panel. The tree that you see in the Object Browser does often get badly out of sync with what's really on screen, and that seems to interfere with scripts. But in general I have found that there are no problems while actually running scripts that deal with the same objects, as long as I haven't used the Object Browser beforehand. That means that I often have to restart TC or go through various other rituals in order to get a script written, but once it's written it works OK at runtime. Very annoying, yes, but manageable.



There may be another workaround for your situation. I assume that you are searching for the desired TextBlock by calling FindChild from the ListBox object, is that right? Instead of that, you may be better off if you first use FindAllChildren to find all the visible ListBoxItems, and from each of those call FindChild to find the TextBlock within and see if it's the one you're looking for. If it is, you already have what should be a valid and correct reference to its parent. If you get through the whole set of visible ListBoxItems without finding the item you want, then scroll a bit, refresh, and try it all again.

You're right Tony. Very tricky.

I do agree that AQA can improve their support for silverlight, and I hope that this thread can help them improve this.



After hours of painful attempts to find I decent/elegant workaround. I found something that can probably help you too.

If you make any changes to TC options, the object browser regenerates.

So, if you execute the following in your test for example, the object hierachy is completely rebuilt and it will fix itself.

<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<meta content="Word.Document" name="ProgId" />
<meta content="Microsoft Word 12" name="Generator" />
<meta content="Microsoft Word 12" name="Originator" />

 
Options.Web.TreeModel = "DOM"

Options.Web.TreeModel = "Tree" 

 
Sys.Refresh 

I know, a strage workaround, but it works  (keeps the relationship between a textblock and ListBoxItem in sync.)

This will suffice for what I need. But I hope it can help you and others until AQA resolve the problem.

Thanks again Tony

Evan