cancel
Showing results for 
Search instead for 
Did you mean: 

TC 12.3, WinFormsObject(name).Exists raises run-time error instead of false

SOLVED
New Contributor

TC 12.3, WinFormsObject(name).Exists raises run-time error instead of false

Anyone else come across this?

 

I don't know if this happens all the time, but in our automation tool that leverages TC for screen interactions, WinFormsObject(name).Exists now raises a run-time error -2072187182 with message: 

 

Unable to find the object WinFormsObject("myTestObjectName"). See additional Information for Details.
The object with the specified attributes does not exists.
Possible causes of the error: aqa-help://2202

This was not a problem in earlier versions (11.2 and before). The .Exists would simply return a false value and would allow my automation to proceed according to the specified logic.

I have over 250 instances of this, rewriting all the code to trap this correctly is not a pleasant prospect.

 

The WaitWinFormsObject(""myTestObjectName", 100).Exists seems to work as expected.

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Community Hero

Re: TC 12.3, WinFormsObject(name).Exists raises run-time error instead of false

When I first started using TestComplete back in 2001-2002, the behavior was as it is now... a "Wait" method needed to be used for object detection because, otherwise, it would return the runtime error you described.  Understandably, that may have changed, but logically, it makes sense as mentioned above:

 

1) Can't check the "Exists" property of something that is NULL

2) The method is being executed to look for an object that doesn't exist so returns the runtime error.

 

Now, potentially, SmartBear could correct #2 above.  I think I remember a discussion something to that end in the past but I don't recall the result.  In any case, as mentioned, it's always a best practice to "Wait" if you're going to check existence... cleaner code all around.


Robert Martin
[Community Expert Group]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available

View solution in original post

4 REPLIES 4
Highlighted
Community Hero

Re: TC 12.3, WinFormsObject(name).Exists raises run-time error instead of false

The way I look at it, you cannot evaluate the "Exists" property of an object that doesn't exist.  Basically, if WinFormsObject("MyTestObjectName") doesn't exists, it is actually a NULL object which has no properties...

 

For that matter, WinFormsObject is, technically, a Method of the parent object... so, you are calling a method which is intended to return a WinFormsObject with the identifier of "myTestObjectName"... and it's reporting back that it cannot do so.

 

What you posted concerning "WaitWinFormsObject" is actually the best practice for detecting an objects existence if you cannot guarantee it.  I know it's a pain, but I'm thinking, in the long run, you'll get a better test.


Robert Martin
[Community Expert Group]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
Highlighted
New Contributor

Re: TC 12.3, WinFormsObject(name).Exists raises run-time error instead of false

Thanks for the best practice suggestion.

What is strange is that this old code has worked for the better part of the last 10 years I think ... and only started to not work when we tested with 12.3.

This also goes against what I understand from the documentation: https://support.smartbear.com/testcomplete/docs/reference/test-objects/members/window-and-process/wi...

 

I narrowed down the number of cases that where .Exist was used without the WaitWinForms to a more manageable list of about 27. 

I do like that not only does this work in 12.3 but also (when I run in 11.2) it is more performant when the object doesn't exist. The .exist would return false after 2-3 seconds. The WaitWinForms returns false after the specified timeout (I generally use 100).

Highlighted
Community Hero

Re: TC 12.3, WinFormsObject(name).Exists raises run-time error instead of false

When I first started using TestComplete back in 2001-2002, the behavior was as it is now... a "Wait" method needed to be used for object detection because, otherwise, it would return the runtime error you described.  Understandably, that may have changed, but logically, it makes sense as mentioned above:

 

1) Can't check the "Exists" property of something that is NULL

2) The method is being executed to look for an object that doesn't exist so returns the runtime error.

 

Now, potentially, SmartBear could correct #2 above.  I think I remember a discussion something to that end in the past but I don't recall the result.  In any case, as mentioned, it's always a best practice to "Wait" if you're going to check existence... cleaner code all around.


Robert Martin
[Community Expert Group]
Please consider giving a Kudo if I write good stuff
----

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available

View solution in original post

Highlighted
Community Hero

Re: TC 12.3, WinFormsObject(name).Exists raises run-time error instead of false

@p6s:

Hi,

 

I would agree with you that this looks strange and maybe needs to be reported to Support via the https://support.smartbear.com/message/?prod=TestComplete form.

 

Indeed, the documentation that you referenced clearly says that if object is not found by WinFormsObject() method, then an error is posted to the log and stub object is returned. No exception should be thrown.

Also, IIRC, all non-Wait... versions of access methods (WinFormsObject, VBObject, ...) must use auto-wait timeout specified for the project. Usually this timeout is set to 30 sec. The use of methods' Wait-version serves two needs: a) to avoid errors in the log when it is expected that the target tested object may not exists and b) improve test performance by skipping auto-wait timeout (or improve test stability by specifying longer timeout on slow environments).

 

Long in the past I remember there were cases when people started to get objects to be not found by regular non-Wait methods with the release of new version of TestComplete or when migrating to new OS or hardware. In most cases this was caused by the fact that actual time taken by any method (Wait... or non-Wait) consists of some time spent by TestComplete internally to search for an object and of timeout to wait for an object to appear. And in the previous version of TestComplete the internal search time was long enough for the project to appear. But after search performance optimizations made for the newer version of TestComplete and low value of auto-wait set for the project, it could happen that the initial search for the object was so fast and the value of auto-wait was so low that the object did not appear within that time.

I think that this is not your scenario, but nevertheless... (considering mentioned by you timeout of 2-3 secs)

Regards,
Alex
[Community Expert Group]
____
[Community Expert Group] members are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Postings made by [Community Expert Group] members
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
[Community Expert Group] signature is used with permission by SmartBear Software.
http://smartbear.com/forums/f83/t86934/community-experts/
================================