Our customer has an automation on which I noticed that one of the controls has ambiguous match rules (see two attachments). Nevertheless, perform click against this control does click the correct control (the one shown in 1x.png). Does anyone know why?
The correct control is the one which says "Menu_KeiyakuKanri" in the "Attached To" column, but I don't see anything in the match rules neither in Studio as shown nor in the underlying *.os file which either narrows the match to that specific one nor in any other way identifies it as the one I want. It does, however, appear largely safe to use so it must be specified somewhere.
The strange thing is despite multiple targets showing in the connector, it actually does match the specific rule we want it to, so it appears to be a problem (?) with Studio at design time, not a problem with IE at run time. Either the match rules do specifically match the target we want and the other targets are displayed erroneously, or there is an hidden extra match rule which filters the targets to the one we want; I suspected the latter but I couldn't find any trace in the os file.
One different (actually diametrically opposite) problem we recently experienced I suspect to be related if not even the same root cause: our user experienced a case where the match rule visually perfectly matched the underlying control but it only matches on the initial interrogation and fails to after. I have included a screenshot (1.png) which shows the match rule in question: it is a Virtual Native Window Name Match Rule.
I've noticed this sometimes with other match rules as well: it's is if there are hidden conditions within the match rule which make it unmatch.
Has anyone experienced this (the match rules actually match but to the robot can't associate it) or the original issue (the match rules are actually ambiguous - match multiple controls - but the robot seems to be able to associate it with the correct one)?