Ordering of RawText elements in v9.3 is different from v9.2.1 and earlier
Posted: Fri Feb 28, 2020 2:34 pm
We've been using Ranorex v9.1.1 for a while now. Works great, very reliable, I know what to expect. But obviously the time eventually comes to upgrade. I do this carefully because of a huge wariness over introduced issues that I then have to battle with. Unfortunately I immediately hit one with Ranorex v9.3 upon trying it for the first time today.
We rely upon GDI Capture and RawText elements. These tend to be grouped together in pairs, one element that is the full width of the area that the text is being drawn into; and a second that is much more compact, covering just the text area. Ordinarily, in all versions of Ranorex that I've used thus far, v6.0 through v9.1.1, these have been ordered as just described, large area element precediing tighter area element.
But this ordering has changed in Ranorex v9.3. Some RawText elements are ordered as described, but a great many sibling elements are ordered the opposite way. It appears I've just been picking the one I want out because the ordering was stable. Yes, I realise this is delicate, but it has been stable for ages as far as I'm concerned. While I will go and look into improving the code in this area, Ranorex v9.3 has changed its established behaviour here.
So I went back to examine the issue more closely in other Ranorex versions, so I can report the problem directly to Ranorex.
v9.1.1, v9.1.2, v9.2.1 all work in the expected sequence, just as older versions of Ranorex did before them.
v9.3 is the first that appears to re-order the RawText elements.
We rely upon GDI Capture and RawText elements. These tend to be grouped together in pairs, one element that is the full width of the area that the text is being drawn into; and a second that is much more compact, covering just the text area. Ordinarily, in all versions of Ranorex that I've used thus far, v6.0 through v9.1.1, these have been ordered as just described, large area element precediing tighter area element.
But this ordering has changed in Ranorex v9.3. Some RawText elements are ordered as described, but a great many sibling elements are ordered the opposite way. It appears I've just been picking the one I want out because the ordering was stable. Yes, I realise this is delicate, but it has been stable for ages as far as I'm concerned. While I will go and look into improving the code in this area, Ranorex v9.3 has changed its established behaviour here.
So I went back to examine the issue more closely in other Ranorex versions, so I can report the problem directly to Ranorex.
v9.1.1, v9.1.2, v9.2.1 all work in the expected sequence, just as older versions of Ranorex did before them.
v9.3 is the first that appears to re-order the RawText elements.