Forum Discussion

Mark1's avatar
Mark1
Contributor
6 years ago

Same application on different OS giving different object spy results

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 ...
  • RUDOLF_BOTHMA's avatar
    RUDOLF_BOTHMA
    6 years ago

    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's avatar
Mark1
Contributor

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's avatar
RUDOLF_BOTHMA
Community Hero
6 years ago

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's avatar
    Mark1
    Contributor
    6 years ago

    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's avatar
    RUDOLF_BOTHMA
    Community Hero
    6 years ago
    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.