Ordering of RawText elements in v9.3 is different from v9.2.1 and earlier

[Stub]

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.

[odklizec]

Hi,

Have you tried to enable new 9.3.0 "Capture GDI+" option? Eventually, toggle previous RawText options?

GDIPlus.png

[Stub]

Starting to think the ordering and grouping is totally off now in Ranorex v9.3. I am seeing more differences between v9.2.1 and v9.3 in these snapshots that I'm peering at.

Also, what is "Origin: GdiWide"? That's a new attribute value that I'm not seeing in my older Ranorex version snapshots.

[Stub]

I did see that option, Pavel, but I admit that I scrolled past because it's GDI+ and I didn't think that was relevant to us. But I need to go and check. I have toggled a few options back and forth, but I'll need to get more structured about my investigations. This is a complete showstopper for me right now!

[odklizec]

Hi Stub,

Well, I think that the change is somehow related to GDI+ implementation? But because the GDI+ option is by default 'false', enabling it will most probably not help with your problem? But it's definitely worth a try

[Stub]

The RawText elements aren't even ordered left to right anymore either. The Location attribute shows me that the ordering is jumping all over the place, starting in the middle, then further right, next back to the left of the client area.

I've opened a case with Support. There is something wrong here.

[Stub]

Interim update for anybody that's interested in this one: Ranorex Support are suggesting this Ranorex v9.3 behaviour isn't intended. It's being pushed into development for further analysis.

[Stub]

Another quick update. I have been further evaluating this change in Ranorex behaviour, trying to code around it and reduce the fragility of this behaviour dependency. But it is utterly devastating for our tests. In its current state, I do not see how we can upgrade to Ranorex v9.3!

Thus far I have been unable to find a consistent way of detecting the correct RawText element from the paired items, as the results of the Ranorex Find API call are all muddled up, by a mix of X-coordinate, ChildIndex or Column. Sometimes I can get it right, but that technique will fail with the next test data and I need an alternative scheme. Hence I never know which mechanism is going to pull the 'right' element from the application. If I pick the wrong scheme then the tests just collapse because the wrong element is used.

I'm now fairly sure we've had this particular behaviour since at least Ranorex v6.0, when I started my Ranorex journey almost 4y ago, so it's been consistent through several major releases. Hence I have my fingers crossed for a bug fix restoring past behaviour.

Going to down tools on this Ranorex v9.3 upgrade until I see what Ranorex come back with, as I'm just wasting hours of time on it.

[Stub]

Oh, hello!

Fixed a breaking change introduced in 9.3.0 which could have caused RawText elements to be created in the wrong order

[Stub]

The above fix looks like it resolves my issue with Ranorex v9.3.0 in my preliminary testing just now. Yay for v9.3.1.