The first one was a list of elements with a print_tree starting from SEMM02,1 the other one from the start of a tree so the values are different but why is the presentation different =
It depends on how you chain locators together, starting from a root element as the source and then diving into relative paths when you search for children.
The simplified “ControlType” printing is the raw control displayed during the Print Tree traversal, while the WindowsElement printed object is our keyword-understandable element object which incapsulates the control seen previously, but based on how you get to retrieve that (from root to root for eg.), you might get different representations of the final locator embedded in the internal item object.
Remember that the Path: you saw there is the path relative to the lastly controlled window (or set anchor) or passed in optional locator into Print Tree, where the path: > path: ... representation is relative one to another (6|1|1), which is then again relative to name:AutoDb type:TreeItemControl and that was outputted like so based on the code you’ve written in the bot. (as we chain parent > child locators when we display them)
Thank you for your explaination. I just feel it better if it would be one way of presentation of the path because one could use common functions inside the coding to work with the path. In my testcase (keepass) if have used now another way to find a solution without using the presentation of the path.
Now I can disturbe the process and seldom it will fail. Thank you for your support.
Hello!
The DisturbNot.zip contains the Keepass Database and the python programm and the log.txt (console)
plus py.log (logging file) an the ListGroup.txt (the result) without disturbing the process.
The Disturb.zip contains the log.txt, py.log and ListGroup.txt where I tried to disturb the process. You can see on the log.txt that some keywords failed.