Ranorex Forum

Windows 7 Pro
Ranorex 5.2.1

.NET uses scope to indicate the appropriate values and methods that are available at given levels of software.

Ranorex Studio is not following the principle of lowest scope when attempting to auto-bind variables to data.

Ranorex is binding global parameters before local, which is reversed from what .NET does. Variables should always attempt to bind to the lowest scoped data available, so if there is a local data source that contains the same column name as a global parameter, the data source's column should win.

If the test creator wants to re-bind to a higher level data source, that should require manual manipulation.

For example, if the test is setup like the following: Then, when using auto-bind, the Value1 variable of Recording 1 should be bound to DataConnector.Value1. Instead, Ranorex is binding the variable to GlobalParameter.Value1, which is in the farthest scope from the variable.

I could have sworn that this worked correctly in earlier versions, but I haven't gone back to test it.

Hi krstcs,

You are right and we are already aware of this issue.
This worked differently in 5.1, so it changed but this was not intended.
This will be fixed with one of our next versions.

Thanks,
Markus

Awesome, thanks Markus!

This BUG has returned in 5.4.1 (and 5.4.0 from what I hear).

This issue was fixed in 5.3 (although it isn't in any of the release notes) but has now been changed (regressed!) back to the incorrect way. And from what I'm hearing from other users, the support team is saying that "this is how it has always worked", which is incorrect. It only worked that way in 5.2.1/5.2.2 and now 5.4.0/5.4.1.

In 5.3.2 (and 5.1 and earlier), auto-bind chose the parent test case's parameters or data source to bind with before trying to bind to a parent, which is a FIX to the issue I started here for 5.2.1.

In 5.4.1, Ranorex now attempts to bind first with the source FARTHEST AWAY from the usage, which is inconsistent with the basic OOP principle of lowest scope and how .NET handles scope. Ranorex should ALWAYS check the parent test case FIRST, then move up to the parent's parent, and so on, when there are multiple data sources or parameters that could match.

Order of auto-binding for module variables with the same name as connector columns or parameters should always be, in this order:
1. Any data in the module's parent test case first, then move up the tree, finally to root test case (or suite for parameters)
2. Data connectors before parameters (this is FIXED in 5.4.1, yeah!)

There seems to be some disagreement amongst the Ranorex team about what SHOULD be happening as I have gotten a message from another user stating that the Ranorex team says the current way is working as intended, which, again goes directly against what Markus told me below was a bug that should be fixed.

In addition, that fact that these changes are not mentioned in release notes for ANY VERSION says to me that you guys aren't sure what's going on either, which is more than a little concerning.

This is my experience also. I hope Ranorex's development team will reconsider their standpoint since I have testcases that when I change variables I have to manually rebind after auto-bind now (which kinda defeats the purpose ). The reason it makes sense that auto-bind should work the way it worked is that you can set some default values on the highest level and only deviate on lower levels by for instance adding a custom parameter (at least that's the way I use it).

Hi Kelly,

I have to apologize, this was a misunderstanding on our site.

What we tried in 5.4 is to generalize the auto-bind functionality for parameters and data sources, that it always works in the same way. In your point of view this is the wrong way and I agree with that.

I therefore already forwarded the detailed information about your request and we will discuss internally how we move on with that.

Again, sorry for the inconvenience this have caused and thank you for your patience.

Regards,
Markus

Thanks Markus!

Hi all,

Is there anything new regarding this issue? I've recently started using Auto-Binding more frequently and I have to agree that variables should be auto-binded to a nearest (parent) TC. This logic makes definitely more sense than actual auto-binding behavior

I haven't heard/seen anything yet, but this may be a change that is bigger than expected.

Hi Kelly and Pavel,

Please be assured that this was already forwarded and is taking into account when discussing about our new datasource strategy.
Since this is part of a bigger datasource change, it can take a while until it gets changed.

Regards,
Markus