Page 1 of 2
Accelerator keys now a part of text recognition
Posted: Mon Apr 04, 2011 10:08 pm
by Ciege
Just upgraded from 2.x to 3.0.1 and am running into a new issue.
Text with accelerators assigned to them (I.e. the underlined letter on a button text) are now discovered by Ranorex with the "&" symbol in front of the letter that is set as the accelerator. I do understand that the "&" symbol is the proper denotation of an accelerator, but in previous versions of Ranorex that I've used the "&" was never a part of the recognition string. Now that the "&" is a part of the recognition string any of my references to text without the "&" will fail.
Is this by design?
Can I disable it?
Re: Accelerator keys now a part of text recognition
Posted: Mon Apr 04, 2011 11:55 pm
by Ciege
Just as an update I cleaned my machine and installed the 3.0 release and the "&" was not in any of the text recognition strings.
I then upgraded 3.0 to 3.0.1 and the "&" was now there. So it appears that this was introduced in 3.0.1.
This is pretty critical for me as it will create a lot of re-write for me to get all my scripts back in to a useable state.
Since I was unable to upgrade to 3.0 (due to another issue) it's a bit disappointing waiting so long only to hit this issue. I do hope you guys are able to address it quickly and able to get a 3.0.2 out sooner rather than later.
Thanks...
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 12:07 pm
by Support Team
Whether accelerator keys (mnemonics) can be detected and whether they are displayed in element attributes (like "Text"), depends on the technology of the controls and did not change since 2.0. For Windows Forms controls, for example, mnemonics were always indicated in the "Text" attribute using an ampersand ("&").
Ciege wrote:I then upgraded 3.0 to 3.0.1 and the "&" was now there. So it appears that this was introduced in 3.0.1.
This should only be the case if another element is found, e.g. a WinForms element instead of an MSAA element. With Ranorex 3.0.1 we introduced
plugin-specific settings; could it be that you changed one of these settings, most probably the
MsaaFlavor.WinFormsFilterEnabled ("Filter Windows Forms elements"), or that you have some code setting this property?
Regards,
Alex
Ranorex Team
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 4:04 pm
by Ciege
Well I have changed no settings.
All I did was uninstall 2.3 and install 3.0.1.
My first step was to run my scripts that install my AUT and it failed since all the buttons with accelerators are now not found since the "&" is a part of the recognition.
I have attached 2 Ranorex snapshots of the exact same setup dialog for my AUT. One is with 2.3 and one is with 3.0.1. You can see that the Next button in 3.0.1 includes the "&" while it is not included in the 2.3 version. Both of these snapshots are from the exact same computer (Win XP 32bit).
Similar inconsistencies can be seen throughout my AUT that make running my existing scripts impossible.
I will post similar snapshots from 2.3 / 3.0.1 from my AUT if requested...
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 4:24 pm
by Support Team
Ciege wrote:All I did was uninstall 2.3 and install 3.0.1.
Please, read in the Ranorex User Guide on how to upgrade your projects from 2.X to 3.X:
http://www.ranorex.com/support/user-gui ... uites.html
Ciege wrote:I have attached 2 Ranorex snapshots of the exact same setup dialog for my AUT. One is with 2.3 and one is with 3.0.1. You can see that the Next button in 3.0.1 includes the "&" while it is not included in the 2.3 version
The reason is that we added better support for Delphi controls (I saw some in the snapshots you posted). Set the "Enable basic Delphi support" to false in the
plugin settings (as indicated in the "Breaking Changes" section) and your projects will work again.
Ciege wrote:Similar inconsistencies can be seen throughout my AUT that make running my existing scripts impossible.
Please, have a look at the
breaking changes and how to deal with them. When you adjust the plugin specifc settings as indicated in this section, Ranorex will work in compatibility mode with 2.X projects and all of your RanoreXPaths should work again.
As indicated in an earlier post, the downside of setting Ranorex to legacy mode is that you might miss some new features, for example new elements in the element tree like with the new Delphi support.
Regards,
Alex
Ranorex Team
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 4:39 pm
by Ciege
I don't use specific Ranorex projects this have no need to convert any projects, I code right in Visual Studio so it should be a matter of just referencing the new DLLs, or am I mistaken?
Ciege wrote:The reason is that we added better support for Delphi controls (I saw some in the snapshots you posted). Set the "Enable basic Delphi support" to false in the
plugin settings (as indicated in the "Breaking Changes" section) and your projects will work again.
The Setup dialog was just an example, however the same issue is present with my AUT which is not Delphi but standard .NET controls.
Ciege wrote:Please, have a look at the
breaking changes and how to deal with them. When you adjust the plugin specifc settings as indicated in this section, Ranorex will work in compatibility mode with 2.X projects and all of your RanoreXPaths should work again.
As indicated in an earlier post, the downside of setting Ranorex to legacy mode is that you might miss some new features, for example new elements in the element tree like with the new Delphi support.
This is certainly something I do not want to do. I don't want to run in compatibility as it is bound to cause issues in the future for me or anyone who may be taking over this project from me if that time ever comes... So it would seem to me that my only proper course of action is to take the pain and modify all of my existing code to come into compliance with the new version of Ranorex (I assume you are not planning to continue with 2.x development?).
Can't say that I am pleased with this, nor will my boss be pleased with the lack of productivity this will result in.
I appreciate your help... Off to the grindstone...
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 5:02 pm
by Support Team
Ciege wrote:I don't use specific Ranorex projects this have no need to convert any projects, I code right in Visual Studio so it should be a matter of just referencing the new DLLs, or am I mistaken?
You should definitely take a look at the
breaking changes.
Ciege wrote:I don't want to run in compatibility as it is bound to cause issues in the future for me or anyone who may be taking over this project from me if that time ever comes...
"Compatibility mode" might not be the right term. You just have control on how the element tree is created for some special cases that are different in 2.X and 3.X. And you can set the plugin-specific settings in code for single test cases, too.
Ciege wrote:I assume you are not planning to continue with 2.x development?.
If you set the plugin-specific settings as outlined in the
breaking changes, then this is exactly as continuing working with 2.X. With 3.X we fixed some limitations in the element tree created by some plugins, but we added the plugin-specific settings for people that do not need the new elements and are happy with the object recognition in 2.X. So I thought that these settings - together with the ability to change the settings in code if you need new 3.X functionality for some parts of your automation - would be the ideal solution for you
No progress without change - although you don't need to change anything if you are happy with the 2.X object recognition and just set Ranorex 3.X to use the 2.X object recognition
Regards,
Alex
Ranorex Team
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 5:11 pm
by Ciege
Support Team wrote:
No progress without change - although you don't need to change anything if you are happy with the 2.X object recognition and just set Ranorex 3.X to use the 2.X object recognition
I understand that there is a workaround, but as you mentioned in another thread about using compatibility mode there are consequences.
Support Team wrote:However, Ranorex Spy will still show you the 3.X RanoreXPaths. Consequently, using this flag is not recommended if you continue to work on that project, you should rather update the broken RanoreXPaths.
I don't want to get my project off path since issues could arise from things as simple as using Ranorex Spy showing different XPaths than what my code is expecting. And who knows what else future changes/fixes will bring... I am not so naive to believe that I will be the only one in the future working on my automation project here so having this or other possible limitations that I will have to remember myself or remember to explain to any other users in the future is unwise...
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 6:24 pm
by Support Team
Ciege wrote:I understand that there is a workaround, but as you mentioned in another thread about using compatibility mode there are consequences.
But consequences that are no worse than using Ranorex 2.X
Ciege wrote:And who knows what else future changes/fixes will bring...
For sure, in the future there are going to be some changes again that we cannot introduce with 100% backwards compatibility. However, be assured that we do not introduce such changes "just because", but out of necessity for recognizing additional UI elements.
Anyway, if you do not want to use plugin-settings, there should not be too much you have to change. We limited the breaking changes to a very minimum that was necessary to allow further development.
Regards,
Alex
Ranorex Team
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 6:29 pm
by Ciege
Support Team wrote:However, be assured that we do not introduce such changes "just because", but out of necessity for recognizing additional UI elements.
Anyway, if you do not want to use plugin-settings, there should not be too much you have to change. We limited the breaking changes to a very minimum that was necessary to allow further development.
Don't get me wrong, I understand the reasons behind it, still doesn't me I can't be upset. Nor does it mean the my boss understands the reasons... I'll get through it sooner or later but because I have a couple of years worth of work that needs to all be re-checked I will lose some productivity...
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 6:59 pm
by Support Team
Ciege wrote:I'll get through it sooner or later but because I have a couple of years worth of work that needs to all be re-checked I will lose some productivity...
Change the settings and you'll be done in a minute
Seriously, I still think that you should change two settings ("Enable basic Delphi support" to "false"; "Filtering compatibility level" to "V2X") and care about them when you run into a UI element that Ranorex cannot recognize with these settings. Chances are good that you never will have to change these settings if you could live with 2.X until now.
In case you got me wrong about the plugin-specific settings before: It's not that you set all Ranorex plugins to legacy mode, it's just that you tell Ranorex for a very specific decision to take the 2.X or 3.X path. Still you will be open to all future Ranorex improvements and object recognition upgrades. And by the way, I checked the code of your "RanorexFramework" you sent us earlier, and it already uses a plugin-specific setting (MsaaFlavor.FilterEnabled)...
Ciege wrote:Don't get me wrong, I understand the reasons behind it, still doesn't me I can't be upset.
I'm a little disappointed that you do not like the plugin-specific settings. We thought they are a good option for users who are fine with the object recognition in 2.X and are eager to use new Ranorex 3.X functionality
Regards,
Alex
Ranorex Team
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 8:21 pm
by Ciege
Well it looks like I *am* going to have to make those settings... I "fixed" all the "&" issues in my installer script and continued on to my first test script. When I got here I started getting issues where I was unable to find data in my DevExpress grids. For whatever reason, Ranorex is returning a Table element to me when I search for it but it contains no rows or columns. When I flip the two switches you mention below then the Table element is returned to me properly with Rows and Columns...
Frustrating... but it seems that those backwards compatibility switches are my only option now...
That being said, is it possible to force Spy to adhere to those switches as well so that I see the XPaths that I expect with the switches enabled? This is becoming one bad can of worms for me...
So in code I will set the
Code: Select all
Ranorex.Plugin.MsaaFlavor.Instance.FilterCompatibiltyLevel = Ranorex.Plugin.MsaaFlavor.CompatibilityLevel.V2X;
setting, but how do I set the Delphi setting in code as well?
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 9:38 pm
by Support Team
Ciege wrote:That being said, is it possible to force Spy to adhere to those switches as well so that I see the XPaths that I expect with the switches enabled?
Yes, usually you set these settings via the "Settings" dialog in Ranorex Spy or Recorder. It's all documented in the user guide pointed to by the links I already posted before:
http://www.ranorex.com/support/user-gui ... html#c3338
Ciege wrote:Ranorex is returning a Table element to me when I search for it but it contains no rows or columns.
Already told you that I had to change your method searching for rows and columns in a table, too, when I tried to reproduce a problem you posted; see following post:
http://www.ranorex.com/forum/ranorex-3- ... html#p7749
All that changed is that there is another container element inside the table that holds all column and rows. So one small change made your sample working for me, even without the backwards compatibility settings.
Regards,
Alex
Ranorex Team
Re: Accelerator keys now a part of text recognition
Posted: Tue Apr 05, 2011 10:05 pm
by Ciege
Support Team wrote:Already told you that I had to change your method searching for rows and columns in a table, too, when I tried to reproduce a problem you posted; see following post:
http://www.ranorex.com/forum/ranorex-3- ... html#p7749
All that changed is that there is another container element inside the table that holds all column and rows. So one small change made your sample working for me, even without the backwards compatibility settings.
I'm not so sure that is the issue I am facing with the table element now. When I do get the Table element successfully I want to loop through all the rows and columns but it comes back saying it has no rows or columns in the table.
This works to find the table:
Code: Select all
//First we need to find the named table element
HDElement = RanorexFormName.FindSingle(".//element[@controlname='" + strTableName + "']", 60000);
//next we find the table object within the element
HDTable = HDElement.FindSingle(".//table", 60000);
Then I want to loop through Rows/Columns:
Code: Select all
foreach (Ranorex.Row row in HDTable.Rows)
But HDTable.Rows and HDTable.Columns has a count of 0 so I cannot loop through them...
Re: Accelerator keys now a part of text recognition
Posted: Wed Apr 06, 2011 11:07 am
by Support Team
Ciege wrote:But HDTable.Rows and HDTable.Columns has a count of 0 so I cannot loop through them...
That's exactly what I meant. The Table.Rows/Columns properties only retrieve rows/columns that are direct children of the table. The data grid used in your application, however, is represented as a table with only two containers as direct children (depends on the MSAA implementation of the data grid). These containers in turn hold all rows and columns of the actual table (the first container provides the header cells, the second the data rows). With 2.X all header cells and rows were direct children of the table.
The new 3.X MSAA filtering does not filter the two container elements any more (which is not perfect in this case, but in general the new filtering does not throw away useful elements anymore). Instead of Table.Rows/Columns you can use the FindDescendants<Row>() method, e.g.:
Table table = ...;
IList<Row> rows;
// old code
rows = table.Rows;
// new code
rows = table.FindDescendants<Row>();
Regards,
Alex
Ranorex Team