Forum Discussion

p6s's avatar
p6s
New Contributor
7 years ago
Solved

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.

  • tristaanogre's avatar
    tristaanogre
    7 years ago

    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.

4 Replies

Sort By
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    7 years ago

    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.

    • p6s's avatar
      p6s
      New Contributor
      7 years ago

      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/winformsobject-method.html#result-value

       

      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).

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor
        7 years ago

        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.