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?
Solved! Go to 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
so TC won't create these unwanted objects while you are working.
Can you share the object browser screenshot for both the bit version.
Can you confirm, The .Net Package installed is same?
The one with the name map Cash is 32 bit, the other is 64 bit. As you can see its the same button on both applications but one is seen as a button with a ClickButton option and the other is not. I am not sure what you mean by the .Net package.
It looks like you may have to use a wildcard to map/identify the object, so in stead of ...Grid.Border.Grid.Cash make it ...Grid.Border.Grid.Cash*
That should address this specific issue in multiple environments
Or don't link it the the identifier, but use other unique properties that aren't affected by OS in stead
Hi @Mark1 ,
if the properties are changing for differnt Bit Operating System, try to find the objecs using Regular Expression.
take the part of property values which is same in both the OS and add "*" where ever the needed(Before or After).
in your case the regular expression somewhat look like below code snippet:
assume if the below is the object's propertyname and values of which you are trying to identify : PropNames = "objectIdentifier" PropValue in 32 Bit = "cash" PropValue in 64Bit = "cash64Bit" Sys.Browser("*").Page(*).FindChild("objectIdentifier", "cash*", 10, true)
NOTE: you can use "*" in prefix,suffix and also in between accordingly
I am not entirely sure what you mean. I am just trying to click this button regardless of what OS it is. The application being tested is a local exe by the way, its not a web page or browser, just in case that makes any difference.
The application being tested is a local exe by the way, its not a web page or browser, just in case that makes any difference.
No, the principle is the same. You still need to use the find, just the way you identify is with Sys.Process rather than Sys.Browser
From what I can see is that the button's name changes based on the environment. They both start with"Cash" though. You don't need to get as fancy as regex, as long as you add that "*" It's the same principle as searcing for *.exe which will search all exe files. In this case it will search for all buttons starting with Cash if you use "Cash*" or all buttons ending with Cash if you use "*Cash" or even all buttons that have cash somewhere in the middle like "*cash*"
By using "Cash*" you are telling TC to find the button that ends with anything as long as it starts with Cash and that wil eliminate the variable name.
@Sathish_Kumar_K is showing how to find the object in script
You can also add wildcards in name mapping e.g.:
If my setup was like yours, this will find the button that my application called btnCancel in 32 bit while finding the button called btnCancel64Bit in the 64 bit environment.
Will the fact that the Cash and Cash64 are from name mapping impact this in any way?
No, it's the same object in the same tree. It's just that the application names it differently - or TC gives it a different ObjectIdentifier (TC infers the name, so 64bit may have been added by TC)
By using "Cash*" in your name mapping properties, it can be the same item in NameMapping window no matter which OS version it is. As long as the Properties identifies one button and no more in any environment, you can use as many properties with as many wildcards as you like. If your properties are to broad with too many wildcards in though, you may find ambigious object recognition errors though, so keep it as exact as possible
Hi @Mark1 ,
please look inot the image attached below
there is a button which idstr is "idBtn_Back" you can use the direct value or the regularexpression by selecting the elips in rightcorner and edit the extra part by replacing wiht the "*"("idBtn_*")
the below is the button were i am using regular expression
please apply the same logic in your case and let me know .
if it is working please accept the solution.
Sathish Kumar K