Hi
@Sam AssafI realise your post was quite a while ago, but perhaps you or others will get value from this in the future.
I completely agree that the API approach is the way to go, but in the event that the real world intervenes and you're forced to use traditional spying, this is what worked for me. BTW, I'm using the Lightning interface - I guess you are too - so I've no idea if this works for SF Classic too.
It seems that issue with Lightning is that every time you click on a different object (eg: from Account #1 to Account #2 to Account #3) it appends the new view to the original DOM. Presumably, this is so that it can quickly navigate back-and-forth between the various objects that you've selected. For BP robots though, it means that the field you're trying to spy/retrieve is never at the same path in the DOM. Nightmare!
You can see this from the screenshot below. This is the XPATH to the same field in three different accounts. The only difference is line 14.
Hence we end up creating dynamic paths, looking up parent URLs, modifying that offending <DIV>, and stuff like that which becomes completely unwieldy.
The solution that's worked for me is to refresh the browser each time you go to a new SF screen. The browser refresh resets the DOM and therefore the Line 14 DIV is always #1 and the XPATH to the field is always consistent.
So, at design-time, I goto a page, I refresh the page, I spy the page controls; at run-time, I goto a page, I refresh the page, I read the page controls. Something like this:
I'm only writing my objects now (I discovered this thread 'cause I was tearing my hair out) so perhaps some other problem will crop up, but thus far this approach is working for me.
------------------------------
Dan Ternes
CTO APJ
Blue Prism
Asia/Hong_Kong
------------------------------