In TestComplete 3 there were two standard ways to reference objects; native names for Open applications and the Window method for those exceptions where the application is not open.
These methods have obvious advantages, short names and uniform object naming in different applications, however both also have several annoying disadvantages, especially when applied to .NET Open applications.
These problems are now solved with a new object access approach added in TestComplete 4. I'll outline the problem then show you how we deal with it now in version 4.
The Problem
The .NET Framework is a very flexible environment that allows developers to disregard naming objects in their applications. It's true, in .NET names are not required object properties and do not identify them uniquely.
If object names are not used in .NET, this can make the first approach of working with objects in TestComplete quite challenging.
When the TestComplete recording tool runs into an unamed object it uses a generic name, Object. Each unnamed object is named in sequence, so you can end up with a lot of names like Object_3 and Object_25.
What about using Win32 class names like the second object reference method? Unfortunately, the second approach was also limited for unnamed .NET objects due to their unhelpful Win32 class names. It was just impossible to say exactly which object the following code works with:
parent.Window("WindowsForms10.Window.8.app3", "", 4).Click(34, 55)
Moreover, the window class names could change depending on the computer and the .NET Framework version installed.
Even if an object has a 'nice' name, there was a real probability that this name will conflict with a property or method of the object's parent.
These problems can now be addressed with a new way to objects in TestComplete 4. In the new version, it's possible to use a corresponding parent object method to get an object created in a specific environment,.
The WinFormsObject method should be used for getting .NET objects. For .NET objects that have a native name, the WinFormsObject(Name) method works just like accessing the objects directly by this name. For example, parent.MydotNETObject and parent.WinFormsObject("MydotNETObject"), reference the same object.
The longer object name may be a little confusing, but this is a really good improvement since working with objects this way is more safe and reliable. You shouldn't be afraid of name conflicts or too complex native names (e.g. with '_' as the first character).
But this approach still has a possible problem, what to do if there are several objects with the same native name? Here the second implementation of the WinFormsObject comes into play. This method is very like the second implementation of the Window method in TestComplete 3, but there is one important difference, this method accepts a native .NET class name as the first parameter instead of a stupid .NET window class name.
Using this method, you can easily address separate objects with the same native name - the set of the method parameters will uniquely identify any object. Compare:
parent.Window("WindowsForms10.Window.8.app3", "", 4).Click(34, 55)
and
parent. WinFormsObject("PictureBox", "", 4).Click(34, 55)
Unfortunately, the .NET class name of a .NET object cannot be found in the Object Browser in the current version of TestComplete (4.11). However, there is a simple method to find it, each .NET object has the GetType method. So, just call the GetType method of the desired object and see its value:
[JScript]
Log.Message(obj.GetType().ToString().OleValue);
This code will post something like 'System.Windows.Forms.PictureBox' to the log. The final part of this full class name is the short class name we need - 'PictureBox'.
There is another, more simple, way of getting the short class name of a .NET object. However please note that this approach can cause a crash of the application under test. Find the desired object in the Object Browser, press ellipsis button ('...') next to the NativeClrObject property and then set a new value for the 'name' property - let it be an empty string. Upon doing this, just refresh the Object Browser (Shift-R) and get the name of the object in the second WinFormsObject implementation within the object tree. :)
Please let me know if this note helped you or if you have any more questions about referencing ojbects in TestComplete 4.