Ranorex Forum

First, I have to thank you all for sharing your thoughts and experiences!

IanF wrote:I went over the settings again (got it right this time)
.//picture[@automationid='PartnershipIcon']
This is a generated XPath based on those settings.

So this should get you the "abbreviated "paths right away, unless the path is not precise enough to retrieve a single element, in which case the path will be extended until it is. Right?

odklizec wrote:So even with new optimized generation of RXpaths, it may still be useful to have this feature back? Maybe just for advanced users, who know the danger of using this feature but who still prefer to use it in their tests?

It could still be useful, you are right. However, what we try to do is move away from the error-prone "Abbreviate..." functionality and replace it by some more reliable and still comfortable feature.
Our idea was to make the automatic RanoreXPath generation flexible enough to let the user decide whether to generate really short RanoreXPaths in the first place, instead of having to manually click on the paths in the repository afterwards (and hope for the abbreviated path to still get the correct element...)

IanF wrote:Moving on how hard would it be to provide basic settings for things like Silverlight or HTML or GUI apps would certainly make stuff easier to deal with.

Changing the RanoreXPath generation parameters is currently almost impossible for Ranorex users, I agree
My idea to improve that would be something like the security slider in IE, where the user can decide whether he wants shorter or longer RanoreXPaths to be generated - with all the pros and cons (speed, reliability, maintainability).

Regards,
Alex
Ranorex Team

Alex

A slide for RanoreXPath more or less sounds like a good idea.

Jim

I have seen what AX can be like and I can imagine the RanoreXPaths and the amount of them could get very complex.

The AUT here isn't huge so a repository with easier radability is the better choice we have sections with verbose paths which do don't perform any better than the abbreviated paths.

IanF wrote:Alex
Jim

I have seen what AX can be like and I can imagine the RanoreXPaths and the amount of them could get very complex.

The AUT here isn't huge so a repository with easier radability is the better choice we have sections with verbose paths which do don't perform any better than the abbreviated paths.

Yes, agree 100% Ian, as I said, different things work for different circummstances.

Jim

Hi Alex / Support.

Has automatic generation of RXpaths been improved in 4.1.1 and 4.1.2?
Was a RXpath generation slider added??

I think better to disable functions using a on/off checkbox in options.
Rather then "permanently disable" functions people have found working for years.

It would have been simple to allow "Automatic (original method) abbreviation" in options.
Add an option do some analysis/timing on the abbreviated path VS a "automatically generated" optimal? path.
Which raises a msgbox to give the user feedback.

So the user can make a decision on what method to use for RXpath generation based on analysis/timing.
Rather that Ranorex telling the users what method to use.

Thanks
Erik
Caterpillar Brisbane

Part of the issue with just leaving in an old feature is that they made several significant changes to the underlying algorithms and functions that it used that more than likely cause the old way to no longer even work and would have meant re-tooling the functionality anyway. At this point, it was better for them to remove the functionality than spend extra time trying to make it work again with the new way they are doing path generation. This is a very central issue for software when making changes to base functionality. Sometimes you can't just make it an option for the user because it would actually cause problems.

And, while Ranorex is very flexible, it is also a tool. There are some times when tool makers have to tell the users how and when to use the tools they make. While you can use a screwdriver to hammer a nail, it isn't the correct tool for the job.


I still see more problems with the abbreviate function than good. All it did was remove uniqueness from the paths, with no intelligence, which is never a good thing for identification. It points to an underlying problem with how path generation is handled, and leads to bad practices for the users, as demonstrated by some of the comments here. Users will use the tools you give them, good or bad, and what we may see as easy right now can lead to big problems later.

erikoss wrote:Has automatic generation of RXpaths been improved in 4.1.1 and 4.1.2?
Was a RXpath generation slider added??

I'm not sure what you mean by "improved" - and no, there is no slider, yet. However, you can simply change the RanoreXPath generation algorithm to automatically generate short RanoreXPaths as outlined in a previous post in this thread.

erikoss wrote:I think better to disable functions using a on/off checkbox in options.
Rather then "permanently disable" functions people have found working for years.

I agree with you and we try to avoid removing working functionality. However, people (obviously not those posting on this thread ) repeatedly had problems with the "Abbreviate Item Path" rendering their repository items invalid, no matter how experienced they are, just because that functionality could throw away essential information in a RanoreXPath.
So removing that functionality and replacing it by a better RanoreXPath generation method was actually kind of a bug fix for an error-prone functionality.

Your idea of adding a setting to enable legacy functionality sounds great, first. On second thought, as Ranorex is quite a rapidly developing tool, think of all the legacy functionality we would then need to maintain. Should we add a legacy setting for every bug fix as well, then, just to maintain backwards compatibility?
And as explained before, with the automatic RanoreXPath generation vs. the "Abbreviate Item Path" functionality, choosing between those two functionalities means choosing between a path that works and one that possibly fails.

So my point is: From time to time we would like to remove some functionalities that we think we have a better alternative for. Otherwise we would be stuck with our tool and it would degrade to a bloated chunk of legacy software.

Regards,
Alex
Ranorex Team

All valid points/views.

As a ending comment, We have seen great value, have received good feedback, in seeking, and allowing users, input to development and direction of functionality development.

Perhaps next time, it would be better received, if you seek input/survey from users on removing functionality. Community input to software development had achieved great success and users feel more involved given a greater feeling of ownership.

erikoss wrote:Perhaps next time, it would be better received, if you seek input/survey from users on removing functionality. Community input to software development had achieved great success and users feel more involved given a greater feeling of ownership.

That's one of our key goals, to seek more user input on request, e.g. to determine functionalities that are frequently or seldom used. The last survey was issued almost a year ago and contained rather general questions. An idea is to conduct surveys on a regular basis and also let users answer Yes/No questions on topics we are unsure about.

Thank you again to you and all others posting to this topic for your inputs!

Regards,
Alex
Ranorex Team