After changing the ranorex version, the path to the container has changed
After changing the ranorex version, the path to the container has changed
We have:
- installed version of ranorex9.3.4 on machine1 (M#1)
- installed version of ranorex10.1.3 on machine2 (M#2)
Testing:
- a program for desktop (WPF, .NET Framework 4.8 )
Actions:
1. When running tests on M#1 (ranorex version 9.3.4), the tests pass successfully.
2. When running the same tests on M#2 (ranorex version 10.1.3), the tests fail because that the path to some elements is extended by several containers.
3. When checking versions with programmers, the indicated containers existed. However, in version 9.3.4 they were not available and visible.
Screenshots:
1. SPY M#1 (ranorex version 9.3.4) --> path to container ‘PopupContent’ --> Element with type ‘Border’ is parallel to element with type ‘Grid’
- Form[@automationid='Window' and @type = 'PopupView']/Element[@type='Border']/Element[@type='AdornerDecorator']/Container[@type='ContentPresenter']
- Form[@automationid='Window' and @type = 'PopupView']/Container[@type='Grid']/container[@type='ContentControl']
.Form 'Window' --> PopupView
...Element --> Border
... ...Element --> AdornerDecorator
... ... ...Container --> ContentPresenter
.Container --> Grid
...Container --> ContentControl
2. SPY M#2 (ranorex version 10.1.3) --> path to same container ‘PopupContent‘ --> Element with type ‘Grid’ is nested in element with type ‘Border’/‘AdornerDecorator’/ ‘ContentPresenter’
- Form[@automationid='Window' and @type = 'PopupView']/Element[@type='Border']/Element[@type='AdornerDecorator']/Container[@type='ContentPresenter']/Container[@type='Grid']/container[@type='ContentControl']
.Form 'Window' --> PopupView
...Element --> Border
... ...Element --> AdornerDecorator
... ... ...Container --> ContentPresenter
... ... ... ...Container --> Grid
... ... ... ... ...Container --> ContentControl
- installed version of ranorex9.3.4 on machine1 (M#1)
- installed version of ranorex10.1.3 on machine2 (M#2)
Testing:
- a program for desktop (WPF, .NET Framework 4.8 )
Actions:
1. When running tests on M#1 (ranorex version 9.3.4), the tests pass successfully.
2. When running the same tests on M#2 (ranorex version 10.1.3), the tests fail because that the path to some elements is extended by several containers.
3. When checking versions with programmers, the indicated containers existed. However, in version 9.3.4 they were not available and visible.
Screenshots:
1. SPY M#1 (ranorex version 9.3.4) --> path to container ‘PopupContent’ --> Element with type ‘Border’ is parallel to element with type ‘Grid’
- Form[@automationid='Window' and @type = 'PopupView']/Element[@type='Border']/Element[@type='AdornerDecorator']/Container[@type='ContentPresenter']
- Form[@automationid='Window' and @type = 'PopupView']/Container[@type='Grid']/container[@type='ContentControl']
.Form 'Window' --> PopupView
...Element --> Border
... ...Element --> AdornerDecorator
... ... ...Container --> ContentPresenter
.Container --> Grid
...Container --> ContentControl
2. SPY M#2 (ranorex version 10.1.3) --> path to same container ‘PopupContent‘ --> Element with type ‘Grid’ is nested in element with type ‘Border’/‘AdornerDecorator’/ ‘ContentPresenter’
- Form[@automationid='Window' and @type = 'PopupView']/Element[@type='Border']/Element[@type='AdornerDecorator']/Container[@type='ContentPresenter']/Container[@type='Grid']/container[@type='ContentControl']
.Form 'Window' --> PopupView
...Element --> Border
... ...Element --> AdornerDecorator
... ... ...Container --> ContentPresenter
... ... ... ...Container --> Grid
... ... ... ... ...Container --> ContentControl
You do not have the required permissions to view the files attached to this post.
Re: After changing the ranorex version, the path to the container has changed
Hi,
I'm afraid, what you are experiencing is quite normal. How I understand it, the actual state is in fact correct, because it now shows previously unavailable elements? So you will most probably have to adapt the xpaths, reflecting latest changes in Ranorex.
There were a lot of changes and fixes introduced between 9.3.4 and 10.1.3, so it's hard to tell which change exactly caused your problem. It could be either a WPF related change or switch to .Net 4.8? It's always good to keep the Ranorex up to dated and not to delay updates for so long (a year in your case). If you were updating Ranorex on a regular basis, it would be easier to identify the causing change or fix.
I'm afraid, what you are experiencing is quite normal. How I understand it, the actual state is in fact correct, because it now shows previously unavailable elements? So you will most probably have to adapt the xpaths, reflecting latest changes in Ranorex.
There were a lot of changes and fixes introduced between 9.3.4 and 10.1.3, so it's hard to tell which change exactly caused your problem. It could be either a WPF related change or switch to .Net 4.8? It's always good to keep the Ranorex up to dated and not to delay updates for so long (a year in your case). If you were updating Ranorex on a regular basis, it would be easier to identify the causing change or fix.
Pavel Kudrys
Ranorex explorer at Descartes Systems
Please add these details to your questions:
Ranorex explorer at Descartes Systems
Please add these details to your questions:
- Ranorex Snapshot. Learn how to create one >here<
- Ranorex xPath of problematic element(s)
- Ranorex version
- OS version
- HW configuration
Re: After changing the ranorex version, the path to the container has changed
I do not agree with the statement "what you are experiencing is quite normal."
I have similar exeperiences as Dana although I update Ranorex on a regulary basis. Our test suits worked fine up to version 10.1.2 and stopped working properly in version 10.1.3 for our WPF based programs. Suddenly additional containers appeared in the xpaths making it necessary to adapt almost every single test or every repository item. I wonder, why the version has been changed only from 10.1.2 to 10.1.3 if such major changes have been introduced in Ranorex for WPF applications.
I have similar exeperiences as Dana although I update Ranorex on a regulary basis. Our test suits worked fine up to version 10.1.2 and stopped working properly in version 10.1.3 for our WPF based programs. Suddenly additional containers appeared in the xpaths making it necessary to adapt almost every single test or every repository item. I wonder, why the version has been changed only from 10.1.2 to 10.1.3 if such major changes have been introduced in Ranorex for WPF applications.
Re: After changing the ranorex version, the path to the container has changed
Hi,
Well, there were two WPF-related changes, introduced in 10.1.3. I already posted a question to Ranorex folks if there were done some more unlisted changes. But in my opinion, if Ranorex now recognizes more elements, it sounds like an evolution of WPF-plugin? And of course, such changes could always break some repo xpath. I'm afraid, that's the price of evolution We will see what will say Ranorex folks, but I still think that updating xpaths is the only way how to fix your tests. In case you want to minimize number of repo changes caused by recognition enhancements, try to use rooted folders wherever possible. Simple change of rooted folder is definitely easier than going through entire repo.
Well, there were two WPF-related changes, introduced in 10.1.3. I already posted a question to Ranorex folks if there were done some more unlisted changes. But in my opinion, if Ranorex now recognizes more elements, it sounds like an evolution of WPF-plugin? And of course, such changes could always break some repo xpath. I'm afraid, that's the price of evolution We will see what will say Ranorex folks, but I still think that updating xpaths is the only way how to fix your tests. In case you want to minimize number of repo changes caused by recognition enhancements, try to use rooted folders wherever possible. Simple change of rooted folder is definitely easier than going through entire repo.
Pavel Kudrys
Ranorex explorer at Descartes Systems
Please add these details to your questions:
Ranorex explorer at Descartes Systems
Please add these details to your questions:
- Ranorex Snapshot. Learn how to create one >here<
- Ranorex xPath of problematic element(s)
- Ranorex version
- OS version
- HW configuration
Re: After changing the ranorex version, the path to the container has changed
So I got a reply for Ranorex and there is a known issue in 10.1.3, which is now under investigation and possible fix. So as of now, the best fix is to stay on 10.1.2, until the fix is released.
Pavel Kudrys
Ranorex explorer at Descartes Systems
Please add these details to your questions:
Ranorex explorer at Descartes Systems
Please add these details to your questions:
- Ranorex Snapshot. Learn how to create one >here<
- Ranorex xPath of problematic element(s)
- Ranorex version
- OS version
- HW configuration
Re: After changing the ranorex version, the path to the container has changed
Thank you for your help! I wonder if we ever will get informed, when the bug is fixed and in which Ranorex version the bug fix will be available...
Re: After changing the ranorex version, the path to the container has changed
Hi,
Major changes and fixes are always listed in the release notes, available here:
https://www.ranorex.com/release-notes/
Major changes and fixes are always listed in the release notes, available here:
https://www.ranorex.com/release-notes/
Pavel Kudrys
Ranorex explorer at Descartes Systems
Please add these details to your questions:
Ranorex explorer at Descartes Systems
Please add these details to your questions:
- Ranorex Snapshot. Learn how to create one >here<
- Ranorex xPath of problematic element(s)
- Ranorex version
- OS version
- HW configuration
Re: After changing the ranorex version, the path to the container has changed
Thank you. I'm aware of the release notes, but sometimes the notes are difficult to understand. If you look at the release notes of version 10.1.3 the only WPF related changes are: "Recognize CEF-based custom classes by enabling WPF full types by a user whitelisting".
I did not supsect this change to have such a major impact.
I did not supsect this change to have such a major impact.
Re: After changing the ranorex version, the path to the container has changed
I've had a couple of showstopping (for us) bugs fixed after I pointed them out. An update in the release notes is usually identifiable enough to know they got to it. It's the only notification you'll get, short of trying a new release out for yourself.
Re: After changing the ranorex version, the path to the container has changed
Well, as it seems, neither Ranorex guys expected that this change could have such negative impact But Stub's point is correct. It's always best to test new Ranorex (any app) version before using it in production! I'm too testing each new release a day or two, before installing it over all VMs.melodican wrote: ↑Tue Feb 01, 2022 8:57 amThank you. I'm aware of the release notes, but sometimes the notes are difficult to understand. If you look at the release notes of version 10.1.3 the only WPF related changes are: "Recognize CEF-based custom classes by enabling WPF full types by a user whitelisting".
I did not supsect this change to have such a major impact.
Pavel Kudrys
Ranorex explorer at Descartes Systems
Please add these details to your questions:
Ranorex explorer at Descartes Systems
Please add these details to your questions:
- Ranorex Snapshot. Learn how to create one >here<
- Ranorex xPath of problematic element(s)
- Ranorex version
- OS version
- HW configuration
Re: After changing the ranorex version, the path to the container has changed
hi, we've also encountered a similar issue, but i would like to know if the changes you've encountered match the code itself.
because from what i've seen the new hierarchy detected by ranorex does not reflect the true hierarchy that exists in the code .
because from what i've seen the new hierarchy detected by ranorex does not reflect the true hierarchy that exists in the code .
Re: After changing the ranorex version, the path to the container has changed
I wonder, when the issue appearing in version 10.1.3 will be fixed. The release notes of the latest version 10.1.6 do not contain any information related to the issue (same is valid for versions 10.1.4 and 10.1.5).
Re: After changing the ranorex version, the path to the container has changed
Well, you are not alone. I too pointed out that it takes way too long to fix such critical issue. There is already 10.1.7 out, but there is no indication in the release notes about fixing this problem
Pavel Kudrys
Ranorex explorer at Descartes Systems
Please add these details to your questions:
Ranorex explorer at Descartes Systems
Please add these details to your questions:
- Ranorex Snapshot. Learn how to create one >here<
- Ranorex xPath of problematic element(s)
- Ranorex version
- OS version
- HW configuration
Re: After changing the ranorex version, the path to the container has changed
i hate to be a karen and go "i'd like to speak to the manager" but to me this seems like a major issue.
ranorex as a whole relies on sniffing out ui elements in application, that's one of it's main being.
if it does it WRONG, then it seems more than just a something that can be overlooked.
what's worse, the more versions that will go , the more people that would need to adapt their code, and once such a bug is fixed then they'll face the same thing again.
from my POV, the minimum is to have a switch to enable us to go back to the old way.
the same way have a switch for several ways of composing ui elements.
ranorex as a whole relies on sniffing out ui elements in application, that's one of it's main being.
if it does it WRONG, then it seems more than just a something that can be overlooked.
what's worse, the more versions that will go , the more people that would need to adapt their code, and once such a bug is fixed then they'll face the same thing again.
from my POV, the minimum is to have a switch to enable us to go back to the old way.
the same way have a switch for several ways of composing ui elements.
Re: After changing the ranorex version, the path to the container has changed
Hi, is this issue already fixed or is there a simple workaround?