Differences in handling Win64 vs Win32 builds: Comboboxes

Ranorex Spy, Recorder, and Studio.
User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Differences in handling Win64 vs Win32 builds: Comboboxes

Post by Stub » Thu Jun 22, 2017 10:17 am

Ranorex v6.2.1
Windows 10 Pro
Windows desktop MFC application, VS2015 SP3.


Earlier I asked how to handle a combobox control in a 64bit MFC applications.

I have been able to work around this by coding up extra conditionals that kick in when I'm working with a Win64 build. They calculate a coordinate on the control to click which gets me to the button. It's a bit unfortunate to have this behavioural difference between Win32 and Win64 builds and to have to code up customised solutions. It's not as clean as invoking Click() on a Ranorex repository adapter.

But now I'm finding yet more differences when Ranorex is used against a Win64 build of an application. I'll document them in separate posts as I find them, but here's the next issue I'm having, again with combobox controls: Ranorex just doesn't control combobox drop-lists identically when you ask it to exercise a Win64 build. As I'm again faced with having to hack up some alternative work-around, I'm wondering if I'm not alone in hitting these differences. Is this a Ranorex issue or can I approach my handling of combobox controls differently?

Attached to this thread is a super-simple VS2015 dialog-based MFC application that demonstrates the issue, plus a Ranorex solution that exercises the 3 comboboxes. If I run the x86 build of the sample application, my Ranorex code works fine, selecting "First", "Second" and "Third" from each list of options in each combobox control. If I run the x64 build of the sample application, Ranorex fails to operate some of the combobox controls on the dialog.

In this sample application I don't click the drop arrow button control, instead I click a coordinate near the right-hand edge of the combobox where I know the drop arrow button control happens to be. That's my work-around for the problem described in the above linked forum post. However, the problem is now that Ranorex cannot find the dropped list controls with the items in them. Note that I have to have Ranorex click the titlebar just to cancel the drop lists before moving on to the next stage of the test.

I've also attached some Ranorex Spy snapshots of the Win32 and Win64 builds of the sample application.
Attachments
VS2015slnPlusRanorexTests.rar
VS2015 MFC sample application.
(193.15 KiB) Downloaded 19 times
ComboboxesWin64.rxsnp
Ranorex Snapshot of the Win64 flavour of the MFC sample application.
(16.85 KiB) Downloaded 22 times
ComboboxesWin32.rxsnp
Ranorex Snapshot of the Win32 flavour of the MFC sample application.
(16 KiB) Downloaded 20 times
Last edited by Stub on Thu Jun 22, 2017 1:12 pm, edited 1 time in total.

User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Re: Differences in handling Win64 vs Win32 builds: Comboboxes

Post by Stub » Thu Jun 22, 2017 1:03 pm

Using live-tracking on Ranorex Spy I was able to create a new drop-list in my sample app's repository. This isn't a child element of the form/combobox such as I was trying originally and shown below:
NestedDropList.png
NestedDropList.png (22.27 KiB) Viewed 845 times
...but rather a root-level item:
TopLevelDropList.png
TopLevelDropList.png (17.67 KiB) Viewed 845 times
(I realise these are SCREENshots and not SNAPshots - my snapshots are attached above)

...with the following RxPath:

Code: Select all

/list[@processname='ComboDropArrow' and @class='ComboLBox' and @controlid='1000']
I can also use "@accessiblename='Editable dropdown control'" in the RxPath if I wanted to make it unique to a specific combobox control.

So rather than a drop-list nested within the combobox hierarchy in my repository I can instead make a top-level non-child drop-list for each of my combobox controls. This appears to work for both x86 and x64 builds.

Unfortunately that's not how I've structured all of my repository comboboxes so I may need to consider some repository surgery.
Last edited by Stub on Thu Jun 22, 2017 1:13 pm, edited 1 time in total.

User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Re: Differences in handling Win64 vs Win32 builds: Comboboxes

Post by Stub » Thu Jun 22, 2017 1:08 pm

So I think my question is becoming how you other folks structure your dialog combobox and drop-list control elements in your repositories? Have I done it wrong by nesting them like Ranorex Spy suggests?
RxSpy64bit.png
RxSpy64bit.png (49.29 KiB) Viewed 843 times
Or is there a way I can make Ranorex recognise the former nested structure for x64 builds?

Attached is a Ranorex Spy (64bit) snapshot of my 64bit sample application build, in case that's relevant.
Attachments
x64SpyAndBuild.rxsnp
(16.62 KiB) Downloaded 21 times

User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Re: Differences in handling Win64 vs Win32 builds: Comboboxes

Post by Stub » Thu Jun 22, 2017 1:35 pm

Okay, I realise this is me rambling on to myself now! :D

I fiddled with the RxPath for my nested drop-list controls in the repository for my sample app. By adding a bit of parent level "../../" to the path I can get them to reference the element correctly in 32bit and 64bit builds of my test application:

Code: Select all

../../list[@accessiblename='Editable dropdown control' and @controlid='1000']
So it looks like this in my fiddling around in Ranorex:
ParentLevelRedirection.png
ParentLevelRedirection.png (24.5 KiB) Viewed 839 times
Which in turn means I can probably adjust my repositories and not have to adjust my code that references those repositories.

I'm not sure if I'm learning how to use Ranorex properly or if this is a massive hack. :shock:

qwertzu
Posts: 178
Joined: Wed Jan 25, 2017 11:08 am

Re: Differences in handling Win64 vs Win32 builds: Comboboxes

Post by qwertzu » Fri Jun 23, 2017 10:09 am

Hi.

Ok, so it seems, you already solved the issue?

I created a simple recording on your 64bit application in which I select different items of your dropdown menu.
It worked perfectly to run it also on your application compiled to 32bit.

Ranorex automatically chose correct coordinates in order to click on the arrow of the combobox item.
Afterwards I could select items of the dropdown list.

regards,
qwertzu

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 3930
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: Differences in handling Win64 vs Win32 builds: Comboboxes

Post by odklizec » Fri Jun 23, 2017 11:07 am

Hi,

One more idea. Is it really necessary to click the arrow button? Usually, it's enough to click anywhere inside the combo box to expand its list.
Pavel Kudrys
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

qwertzu
Posts: 178
Joined: Wed Jan 25, 2017 11:08 am

Re: Differences in handling Win64 vs Win32 builds: Comboboxes

Post by qwertzu » Fri Jun 23, 2017 11:22 am

Hi,

Yes, in this case the error button has to be clicked in order to open the dropdown list.
But as I´ve already said. It worked for me on his 64bit and 32bit app.

regards,

qwertzu

User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Re: Differences in handling Win64 vs Win32 builds: Comboboxes

Post by Stub » Mon Jun 26, 2017 7:59 am

odklizec wrote:Hi,

One more idea. Is it really necessary to click the arrow button? Usually, it's enough to click anywhere inside the combo box to expand its list.
Yes, it is. One of the combobox controls is an editable field as well as having a drop-list of selectable items.

User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Re: Differences in handling Win64 vs Win32 builds: Comboboxes

Post by Stub » Mon Jun 26, 2017 8:05 am

qwertzu wrote:Ok, so it seems, you already solved the issue?
Yes, I found a work-around for the differences in Ranorex handling 64bit vs 32bit applications. The drop-list must hang off the root level in the repository rather than as a child item of the combobox control. If your recording made a new drop-list in the repository, it may used that rather than the nested item I created initially?

The actual application I'm testing has a great many combobox controls in the repository where I've nested the drop-list and its selectable items. This is because that's the way Ranorex Spy shows them, and the Ranorex repository structure works absolutely fine on 32bit applications.

I'm having to code around differences in the way Ranorex handles 64bit applications - I have 2 other issues involving RawText elements that I have yet to document either here or to Ranorex support - which is a bit unfortunate. Luckily in this case it appears all I need do is add the ../../ on the drop-list element in the repository and it still works for both application platforms.

Ideally there would be no differences in Ranorex behaviour.