Same application on different OS giving different object spy results

[Mark1]

Recently we have started to test our application which has always been on 32 bit OS on 64 bit with a 64bit version of the application. However while the majority of the scripts writen originally for the 32bit version work on the 64 bit, we have found an instance where a button is not recognised as a button via the object spy when it is on 32bit and the code used for 32bit will not work when called to click that button on 64 bit. Is there any reason for this and way to fix it to avoid it should it appear for other buttons in the application? 

[Mark1]

32bit64bit

Yes that seems to be the main issue, if i use the object spy on that button on 32 bit it is recognised as a button and gives me the .clickButton option but that doesnt not appear on 64 bit for the exact same button.

I am also curious as to is it possible this issue with TC identifying the same button on two different OS occuring again? There are alot of buttons in this exe and I didnt not get a chance to test every single one yet. I would very much like to avoid having to rewrite my many tests which were made for 32 bit when they should in theory all work on 64 bit.

[RUDOLF_BOTHMA · Accepted solution]

Hmm, those two mappings aren't even looking at the same properties to identify them.  I'm not sure the 64bit property will even manage to find the button correctly.  Pointing to just the CLrFullClassName as control probably just brings back one of the child controls.  What if your grid contains more than one control ?  What if your button is actually an item inside that 64bit control ?  That means the 32bit property finds an actual button, but the 64bit one just finds a "control" which is located in the same place, but isn't the actual button.  The most likely resolution would be to open object browser for the button in a 32 bit environment and take note of those properties.  Then open the same button in the 64 bit environment and take note of that. You will be able to identify something that's almost the same (or with luck identical) eg. NativeClrObject.Name is button10 in 32bit is button10x64 in 64 bit (just examples pulled from thin air)  Now, get rid of the 64bit one which is just a control and change the 32 bit one to NativeClrObject.Name "button10*"  Your KWTs and scripts can now always refer to that mapped object no matter the OS.  TC will be able to figure out what exactly the button is called no matter what OS.  Now to your question :

Is it possible TC will do this again ? Yes, definitely.  You are always going to have to tweak the mapping properties for your objects.  Fortunately once it's done, you shouldn't have to review this unless the developers rename buttons or move them about.  Some general things you should consider.

Creating a KWT from recording is a good starting point, but don't rely on it to do your mappings and tests.  It's best to turn off automatic mappings and manualy do it before you start recording tests

Manually map items

Turn off

Automatic Mapping

so TC won't create these unwanted objects while you are working.

[Mark1]

Ok, I am about to finish for the day so I will let you know tomorrow how I got on. Out of curiosity, is this issue with finding the exact same button on two different OS a fault of TC or the 64 version of the application?

[RUDOLF_BOTHMA]

---

@Mark1 wrote:

Out of curiosity, is this issue with finding the exact same button on two different OS a fault of TC or the 64 version of the application?

---

It's none of these ones that cause this fault.  I'm not sure you could even call it a fault as such.  Just a quirk of how object naming works.  Some objects get their names generated automatically, such as splashforms etc.  This is determined by the OS, workstation or even user e.g. we have an application that gives it one name if you run the installer from command line and another when you use the clickonce installer.  TC spots this name the first time and maps it.  Change over to the other OS/installation and TC spots the name - in a a slightly different location or with a slightly different name.  TC thinks it's something new because it's not in the mappings yet, so maps it.  Now you have two mapped objects.  One which works in one OS and another that works in another.  You can't really blame TC for getting this one wrong.  It can ony work with what it's got.