Hi, it seems there is something wrong with GDI recognition in latest 4.1.5 (and in 4.1.4 too). It seems the problem happens in the RX Spy started from RX Studio (works OK in standalone Spy).
I added a SysTreeView32 element from an already running application to the GDI list. After I refreshed the RxSpy, it correctly showed the SysTreeView32 RAW elements. See this screenshot:
I then recorded some steps and selected RAW elements have been correctly highlighted and stored in repository. The problem started when I tried to edit an element containing RAW text by starting the Spy from Studio. Additionally, the element in question is not even found/recognized after an attempt to highlight it from Studio (Repository view).
Here is a screenshot showing the content of Spy started from Studio:
Here you can find snapshots created both in Standalone Spy and Spy started from Studio:
And here is the path which works OK in the standalone Spy, but not in Studio Spy:
/form[@title~'^LiteBox3D']/element[5]/element/element[1]//element[@accessiblename='left_panel']/element[@accessiblename='measurement_panel']//tree[@accessiblename='measurement_tree']/rawtext[@column='6' and @row='2']
Aside the SysTreeView32 element, I also tried to add the process name to the GDI list, but this did not help.
Any idea what's wrong or what should I try? I only now realized the need of using GDI in our tests, so it may be that I'm missing something important?
PS: You may notice that there is used a variable in the root node definition , but this is definitely not a cause of this issue. Other GUI elements are recognized OK, except the RAW elements. And I also tried to remove this variable, but this did not help either.
BUG: GDI recognition broken?
BUG: GDI recognition broken?
You do not have the required permissions to view the files attached to this post.
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
- Support Team
- Site Admin
- Posts: 12145
- Joined: Fri Jul 07, 2006 4:30 pm
- Location: Houston, Texas, USA
- Contact:
Re: BUG: GDI recognition broken?
Hi,
May I ask you uninstall Ranorex, restart your machine and then reinstall Ranorex with the setup.exe file?
We have an GDI issue in 4.1.4, so your issue could be related to it and I want to make sure everything is correctly installed on your machine.
Thanks,
Markus
May I ask you uninstall Ranorex, restart your machine and then reinstall Ranorex with the setup.exe file?
We have an GDI issue in 4.1.4, so your issue could be related to it and I want to make sure everything is correctly installed on your machine.
Thanks,
Markus
Re: BUG: GDI recognition broken?
Hi Markus,
Thanks for the reply. I already tried that. I even uninstalled 4.1.5 and installed back 4.1.4, only to realize there is the same problem So I again uninstalled 4.1.4 and installed back 4.1.5.
I just tried 4.1.5 on another machine (WinXP64) with the same result. Simply, if the Spy is run in standalone mode (outside the Studio) GDI recognition works as expected. Once the Spy is started from Studio, trace works for the first time, but once the spy is refreshed, or started from Repository (by edit button), the GDI elements are gone.
Thanks for the reply. I already tried that. I even uninstalled 4.1.5 and installed back 4.1.4, only to realize there is the same problem So I again uninstalled 4.1.4 and installed back 4.1.5.
I just tried 4.1.5 on another machine (WinXP64) with the same result. Simply, if the Spy is run in standalone mode (outside the Studio) GDI recognition works as expected. Once the Spy is started from Studio, trace works for the first time, but once the spy is refreshed, or started from Repository (by edit button), the GDI elements are gone.
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
- Support Team
- Site Admin
- Posts: 12145
- Joined: Fri Jul 07, 2006 4:30 pm
- Location: Houston, Texas, USA
- Contact:
Re: BUG: GDI recognition broken?
Hello odklizec,
Thank you for the description.
Unfortunately it is hard to analyze the issue. Is it possible to get your application and your solution in order to analyze the issue in more detail?
Regards,
Bernhard
Thank you for the description.
Unfortunately it is hard to analyze the issue. Is it possible to get your application and your solution in order to analyze the issue in more detail?
Regards,
Bernhard
Re: BUG: GDI recognition broken?
Hi,
Finally, I have some time for the follow-up regarding this issue It's seems to be still reproducible with Ranorex 5.2.
Please follow the below steps to reproduce the problem (tested and reproduced on Win7 Pro 64bit).
- download and install our app from here:
http://ftp.transcat-plm.com/pub/tcsoft/ ... _64bit.exe
- start the app
- download the attached cubes_normals.zip file and unpack it to c:\temp dir - add ^SysTreeView32$ to GDI capture Class names
- load and start the attached Ranorex project >> the project should load above mentioned jt file, measure one cube and validate the result of measurement action. It should finish OK.
The problematic element is RawText. If you now start editing this element from Ranorex Studio, it fails to find the element. The same happens if you try to highlight the element (using Highlight Element button in repository).
Now start the standalone (64bit) Spy and try to track the element in question manually (Volume value 64000mm3). It should be tracked OK and the RawText Row and Column attributes should be the same as stored in repository. Hope it makes sense to you?
Finally, I have some time for the follow-up regarding this issue It's seems to be still reproducible with Ranorex 5.2.
Please follow the below steps to reproduce the problem (tested and reproduced on Win7 Pro 64bit).
- download and install our app from here:
http://ftp.transcat-plm.com/pub/tcsoft/ ... _64bit.exe
- start the app
- download the attached cubes_normals.zip file and unpack it to c:\temp dir - add ^SysTreeView32$ to GDI capture Class names
- load and start the attached Ranorex project >> the project should load above mentioned jt file, measure one cube and validate the result of measurement action. It should finish OK.
The problematic element is RawText. If you now start editing this element from Ranorex Studio, it fails to find the element. The same happens if you try to highlight the element (using Highlight Element button in repository).
Now start the standalone (64bit) Spy and try to track the element in question manually (Volume value 64000mm3). It should be tracked OK and the RawText Row and Column attributes should be the same as stored in repository. Hope it makes sense to you?
You do not have the required permissions to view the files attached to this post.
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: BUG: GDI recognition broken?
Here is the above mentioned project (cannot attach more then 3 attachments in one post)...
You do not have the required permissions to view the files attached to this post.
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
- Support Team
- Site Admin
- Posts: 12145
- Joined: Fri Jul 07, 2006 4:30 pm
- Location: Houston, Texas, USA
- Contact:
Re: BUG: GDI recognition broken?
Hi odklizec,
Thanks for getting back to us with more information .
I was unfortunately not able to reproduce the issue on my machine, may I therefore ask you to use the following RxPath: ".../rawtext[@rawtext='64000mm3'][1]" instead of the one with the row and column attributes?
In general it is not recommended to use the row or column attributes for rawtext elements if not necessarily needed.
Does it work when you do so?
Regards,
Markus
Thanks for getting back to us with more information .
I was unfortunately not able to reproduce the issue on my machine, may I therefore ask you to use the following RxPath: ".../rawtext[@rawtext='64000mm3'][1]" instead of the one with the row and column attributes?
In general it is not recommended to use the row or column attributes for rawtext elements if not necessarily needed.
Does it work when you do so?
Regards,
Markus
Re: BUG: GDI recognition broken?
Hi Markus,
Thanks for the reply. Unfortunately no. This would not work for us, because the value changes with each loaded and measured model. And we have a data driven test validating the values from the second table column. Maybe it could be done via regex by identifying the cell via mm3, mm2 and mm strings. But I think I already tried that and it eventually failed, because there could be more rows containing mm3 or mm2 string. So this is why we are using column/cell identification.
In any case, once we figure out what are the correct RAWtext column/row values, it works OK in replay. It's just that the row/column attributes disappear from spy if the RawText element is edited via studio. It's not a serious issue, but it's really annoying when one want's to add and debug new table like this. So it would be nice to have it fixed. Were you able to reproduce it on your side?
And this returns us back to the old problem that Ranorex does not support reading values from Java SWT Treeviews with multiple columns This is the only reason why we mess with RawTexts for these tables. Here is the original post about it.
http://www.ranorex.com/forum/ranorex-tr ... t2049.html
It would be really nice to have the multi-column SWT Treeviews supported
Thanks for the reply. Unfortunately no. This would not work for us, because the value changes with each loaded and measured model. And we have a data driven test validating the values from the second table column. Maybe it could be done via regex by identifying the cell via mm3, mm2 and mm strings. But I think I already tried that and it eventually failed, because there could be more rows containing mm3 or mm2 string. So this is why we are using column/cell identification.
In any case, once we figure out what are the correct RAWtext column/row values, it works OK in replay. It's just that the row/column attributes disappear from spy if the RawText element is edited via studio. It's not a serious issue, but it's really annoying when one want's to add and debug new table like this. So it would be nice to have it fixed. Were you able to reproduce it on your side?
And this returns us back to the old problem that Ranorex does not support reading values from Java SWT Treeviews with multiple columns This is the only reason why we mess with RawTexts for these tables. Here is the original post about it.
http://www.ranorex.com/forum/ranorex-tr ... t2049.html
It would be really nice to have the multi-column SWT Treeviews supported
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
- Support Team
- Site Admin
- Posts: 12145
- Joined: Fri Jul 07, 2006 4:30 pm
- Location: Houston, Texas, USA
- Contact:
Re: BUG: GDI recognition broken?
Hi odklizec,
Okay I understand, but I was unfortunately not able to reproduce your issue on my machine.
I had to change the row to 4 and the column to 6 but once changed it has always worked: I cannot make any promises but it could be that we will natively support SWT in a future version.
Regards,
Markus
Okay I understand, but I was unfortunately not able to reproduce your issue on my machine.
I had to change the row to 4 and the column to 6 but once changed it has always worked: I cannot make any promises but it could be that we will natively support SWT in a future version.
Regards,
Markus
You do not have the required permissions to view the files attached to this post.