Forum Discussion

p6s's avatar
p6s
New Contributor
8 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 er...
  • Largent803's avatar
    Largent803
    4 years ago

    I figured this was a defect in the website I just was hoping there was away that I could get the product to recognize these kinds of defects automatically. Because this is a new website I am dealing with there is going to be a lot of cosmetic defects that I am just starting to find in setting up my automation. I have another section of the product that is behaving very much like this and that too is a problem.

tristaanogre's avatar
tristaanogre
Esteemed Contributor
8 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
    8 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
      8 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.

    • AlexKaras's avatar
      AlexKaras
      Icon for Champion Level 2 rankChampion Level 2
      8 years ago

      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)