Treeview not loading properly with 2.3.8 : Bug Reports

[Ciege]

Hi guys.
I just recently upgraded from 2.3 to 2.3.8. I am having an issue where a treeview is not loading properly when I launch our AUT with Ranorex.

This is the exact same problem that I ran into when testing the 3.0 Alpha and communicated with support through email on 10/28/2010 - 11/3/2010. The email title was "Ranorex V3.0 Alpha - Questions/Issues/Comments" and the issue was number 6. This email also contained a video capture of the issue using the 3.x dlls and the issue not appearing using the 2.x version of the dlls.

I did an upgrade straight from 2.3 -> 2.3.8, I didn't use any version in between. Can you determine what has changed from 2.3 to 2.3.8 that is also included in 3 that is the cause of this issue? I will have to revert back to 2.3 to be able to test our AUT as 2.3.8 makes testing impossible.

EDIT: Just an update, this occurs on both of my test machines (XP & Win7) that have been updated with 2.3.8.

Thanks...

[Support Team]

Thank you for reporting this issue!

I did an upgrade straight from 2.3 -> 2.3.8, I didn't use any version in between. Can you determine what has changed from 2.3 to 2.3.8 that is also included in 3 that is the cause of this issue? I will have to revert back to 2.3 to be able to test our AUT as 2.3.8 makes testing impossible.

You did update from 2.3.0 to 2.3.8 straight? Basically, all changes from 2.3.0 to 2.3.8 are also in 3, so that's quite a number of changes between 2.3.0 and 2.3.8. Could you up/downgrade to a version in between, say 2.3.5, and try again so we can limit the number of changes in question?

This sounds like a rather odd problem; the tree seems to refuse to load correctly, because Ranorex interacts with it. From your email I saw that your application uses WinForms controls:
Do you often use InvokeRemotely?
How do you invoke the button that opens the problematic tree view? Could you post the respective code?
If you do all the automation as usual and just click the button manually, does the tree view correctly open?

Regards,
Alex
Ranorex Team

[Ciege]

Yes, I typically do not upgrade a running installation of Ranorex mid-project unless there is a need for it (like needing a Ranorex bugfix). And since I am at the end of the project I was able to update to the latest.

I'm working on doing some tests checking which version of Ranorex causes the issues. This is a time consuming test as I have to revert to a 2.3 image then install the next test version of Ranorex then install my AUT then test (I assume one cannot immediately install a lower version of Ranorex on top of a higher version?).

I do have an InvokeRemotely to expand and/or read data from the tree, but it never gets that far as the tree is empty upon loading the AUT. So what happens is if I load the AUT via Ranorex, then click the button that opens the window that has the treeview embedded in it, the treeview is empty. Similarly, if I load the AUT manually, that same treeview contains data.

I'll let you know more when I find out more through my test trials...

[Ciege]

OK, I believe I've narrowed it down to the 2.3.4.9270 release.
2.3.3.8879 works fine, then when I upgrade to 2.3.4.9270 the issue occurs.

[Support Team]

We identified the use of the Ranorex.Control.InvokeRemotely method as the cause for that problem; actually the WinForms.Control.Invoke method used inside InvokeRemotely. For some reason, if InvokeRemotely is executed on the main form at the same time the tree loads, something goes wrong and the tree does not load correctly. This also correlates to the changes from Ranorex v2.3.3 to v.2.3.4, where the EnsureVisible method for WinForms controls uses InvokeRemotely from v2.3.4 on. The weird thing is that the InvokeRemotely always returns successfully, just the tree view does not load correctly if “interrupted” by a call to InvokeRemotely at the wrong time.

We now changed the internal implementation of the InvokeRemotely method to not use WinForms.Control.Invoke anymore, which caused the problem (as mentioned above). The Invoke was not needed anyway and not using it should not make a difference but for performance. We will incorporate this fix both in the upcoming 2.3.9 and 3.0 releases.

Regards,
Alex
Ranorex Team

[Ciege]

Indeed... This is great news.

I've tested the fix and can confirm that it has been working and expected now.

Thanks again for the stellar support you all provide!

[Support Team]

Thanks again for the stellar support you all provide!

You are welcome! Thank you for testing the fix!

Regards,
Alex
Ranorex Team