| || |
Adding methods to testComplete clases
Maybe i am not looking in the right place, but i'm curious if i can add new methods to an TestComplete object class.
For example .. I am testing a .NET application and say I have a ComboBox where Select() is not working .. I have my own select method i can put somewhere to do what i need but I want to be able to do something like this:
var wCB = Aliases.MyApp.FindChild("Name", "myName");
There's two ways to approach the problem, you can do a wrapper object..
var wCB = new SelectWrapper(Aliases.MyApp.FindChild("Name", "myName");
or you can subclass their object that you want, and override the select method, then configure the object recognition rules to prioritize serving up your object. Works similarly like what's described in "Map custom classes to standard classes"
About Improving Object Recognition
Can you please shed more light on your point "you can subclass their object that you want, and override the select method then configure the object recognition rules to prioritize serving up your object"
I have many WPF objects in my .Net application where many such functions do not work! I would be more interested to know about this work around!
Thanks in advance.
Originally Posted by dlai
Thanks for the reply.
This sounds like more of what I am after:
"you can subclass their object that you want, and override the select method, then configure the object recognition rules to prioritize serving up your object"
Any chance you can explain this more? does it use NameMapping or the extension kit ...
Not quite following the information you pointed to on the SmartBear site. I'm seeing that I can add a new Class or modify an existing one, but not really seeing a way I can add my own custom method to that existing Class (like WinButton class and adding my own custom method 'ApplyKeywrd').
I'm trying to see if TestComplete has a complimentary function like QTP's 'RegisterUserFunc' where I can add user-defined methods to the existing base class for an object. Used this to build up wrapper methods that take a keyword/data pair and apply it to that object. That way I can wrap up the validation work (exist, visible, enabled, etc.) in the custom method before I try to do anything with it. For example; for a Dropdown Combobox I can call my custom apply method to see if the object exists/visible/enabled first and then via a Keyword do a select of the item value I pass in.
Thus: object('StateCode').Apply("Select", "CO")
instead of :
If (object('StateCode').Exist = False) Then
If (object('StateCode').Visible = False) Then
If (object('StateCode').Enabled = False) Then
The 'Apply' method for the object has all the code in it for the object validation and other actions on the object itself. The Keyword/data combo becomes a parameter to the custom method and as part of that via OO the object itself is passed in (custom method/function has definition of Apply(object, dataAction, dataValue)). Thus reusable on other objects of same type across the application.
Trying to simplify the code and modularize further the method/action on a particular object type. Keep a 'component' simple to only interaction with an object and all the heavy logic & work in the custom method for that object type.
Jim, yes you're right it's Not the same as RegisterUserFunc, this is rather creating a new object type that extends an existing type vs monkey patching an existing type. It's just simply extending a standard type overriding it with the support you need, then remapping how the object reorganization to prioritize your object to serve up your extended object instead of the standard type. This is fairly common technique that can be used in most automation tools to add custom one off support when calls to low level hooks are needed. The end effect is mostly the same. (except it may not work well with some features like keyword or storyboard testing). I wouldn't recommend this unless you really have to.
Personally I think the wrapper object is a better approach for simple things, such as setting an accessible property. The custom object proxy approach is generally used more with custom controls where you need lower level hooks.
The wrapper will work similarly to your Apply().
Will be expressed like:
If you're using the C# bindings, you can do type checking so the object cannot be applied to the wrong object type at compile time. Maintenance of the code is encapsulated in an object instead of some loose collection of subroutines.
For example, say you also have a method called, GetSelectedValue. And you have other objects that have different implementations of those 2 same methods?
Then you need to figure out name spacing and naming conventions because it's not protected by object level encapsulation.
Thanks David, appreciate the help on this. I'll look into what you suggest, but may just go the wrapper route. Talked with a friend (QTP guy) who is using TestComplete now and is telling me pretty much the same thing. Basically take the method (aliased functions) definition and just call them straight up with the object passed as a variable (just like your wrapper).
So instead of .Apply it would be BtnApply(object, keyword, data) using a component script as the skeleton for it. (combo of components and keywords). Meh, I'll get it to work. Again, thanks for the help. Best to you.
I started looking into doing Test Complete work again (I'm currently evaluating it's ability of extension for working with customized infragistic controls). while researching their full SDK, I ran into an article describing "Script Extensions". Looks similar to that QTP functionality described.