2

I would like to refresh the tree structure of the top level automationelement object (the desktop element) and all of its descendants.

The problem I have ran into is a particular program I am testing discards and rebuilds its GDI objects in a strange manner, and I have certain sections of my automation that I know will cause it to rebuild its tree structure. I'm not explicitly using .cache, but rather .current to access the automation elements values. I can mimic the GDI structure change in uispy and even if I hit 'refresh' in uispy its not good enough to fetch to new objects, closing and starting up uispy again fixes this though. I would like to mimic the behavior of closing+reopening uispy within my program to force a rebuild of whatever datastructures need to be rebuild.

Currently I end up with automationelements that no longer reference their 'new' children, or have 0,0,0,0 for their boundingrectangle among other things.

Also, could someone tell me exactly what the uispy 'refresh' command does programmatically?

Abdul Hfuda
  • 1,463
  • 12
  • 25
  • As a follow up, inspect.exe has a similar behavior, but does not need to close/reopen to pickup the UI changes. A 'refresh' (ctrl+shift+5 or Action->Refresh) does not fix the children that have invalid boundingrectangles. But collapsing the parent and expanding it again will list the 'correct' children that have valid boundingrectangles, also traversing the tree from an upper node with Navigation->firstchild|next sibling works. How do I programmatically take an upper level automationelement and get its findall() function to return the 'valid' children? – Abdul Hfuda Oct 31 '11 at 20:10
  • UIAutomation's .Current properties are not cached, it's always fetched at the point in time you ask for it, so the concept of refreshing it doesn't make sense: it's always 'fresh'. You might be hitting a bug in UISpy, however, where it is doing its own caching. Are you seeing the same issues in code, or only in UISpy? If what's happening is that the app is discarding its old children and creating new ones, then in code you'd need to re-fetch those elements from scratch; references to the old elements will be invalid. – BrendanMcK Oct 31 '11 at 21:03
  • UISpy's 'Refresh' command doesn't do anything at the UIAutomation API level; tries to cache the tree so that it can minimize what it fetches. 'Refresh' causes it to discard its own cached data. – BrendanMcK Oct 31 '11 at 21:04
  • I think whats happening is I have references to 'old' objects no longer descendants of my parent window (and its tree structure). I want to be able to go up to the window (or desktop) AutoElement and fetch the 'new'/'valid' objects that are descendants, but I cant seem to get them. The same query works initially but when the whole window's structure changes new queries fail and I'm left with some old AutoElements with useless .current values. One way I fix this with uispy is closing and opening it again, inspect.exe refresh doesnt work but collapsing and expanding the window's tree does – Abdul Hfuda Nov 01 '11 at 22:40
  • 1
    If you only have a reference to the old elements - that correspond to UI that no longer exists - you'll need to toss them and start again, from the Desktop downwards. (You might be able to restart at some other parent window instead of the desktop, provided it's one that has not been recreated.) Once the UI for an element is gone, you can't navigate in *any* direction from that element - not even up to the parent. It may look like inspect is doing this, but that's just a side effect of how it builds and displays its tree, it's really caching the parent nodes, not navigating up to them. – BrendanMcK Nov 01 '11 at 23:55

0 Answers0