Forum Discussion

marinb's avatar
marinb
Contributor
9 years ago

Object property does not exist right after it passes an exist check?

Given the following piece of code in our script:   Sys.Refresh(); if (aqObject.IsSupported(Sys.Desktop.ActiveWindow(), "MappedName")) { if (Sys.Desktop.ActiveWindow().MappedName != null) //FA...
  • ghuff2's avatar
    ghuff2
    9 years ago

    Well the only place I can think the issue would be is when calling the ActiveWindow() method. You aren't technically checking the same object since you are grabbing a new object with each call to the ActiveWindow() method. That method returns either a Window object or an empty stub object if no top-level window is found. In your code it must return a Window object in the first check then during the second check for whatever reason something changed and TestComplete doesn't think there's any top-level windows so it returns an empty stub object which doesn't have the MappedName property.

     

    I couldn't reproduce the issue myself, but my suggestion is that you return the results for the ActiveWindow() method into a variable, then reference that same variable. So I'd change your code to this:

     

    Sys.Refresh();
activeWindow = Sys.Desktop.ActiveWindow()
if (aqObject.IsSupported(activeWindow, "MappedName"))
{
    if (activeWindow.MappedName != '')  //FAILS HERE
    {
       <...snip...>

    Which BTW, the MappedName property is never null. If you don't have a MappedName for an object it returns an empty string which is different than null.

     

Manfred_F's avatar
Manfred_F
Regular Contributor

It can always occur that a given, valid reference to an application object (control..) is invalidated at the next line of test Automation script code.

 

Our scripting works asynchronously.

You iterating an object's children? Well. How do You know that during Iteration their number has not changed? Are You sure that at least the object still exists afterwards?

 

Some of our Automation script code serves for synchronization. Especially therein, be prepared to react on any Kind of Errors.

marinb's avatar
marinb
Contributor
9 years ago

True, our application can also be quite unresponsive. I try to make it as robust as possible, but you still get dirty loops like this in order to prevent hiccups... if x.exists, then if  x really exists, then if y exists, but really, x should exist! etc etc ;-)

 

     for (var i = 0; i < iMaxWait; i++)
     {
        if (oMapping.Exists)
        {
            if (aqObject.IsSupported(oMapping, "VisibleOnScreen"))
            {
                if (oMapping.Exists)
                {
                    if (oMapping.VisibleOnScreen)
                    {
                        if (oMapping.Enabled || bDoNotCheckOnEnabled)
                        {
                            bFound = true;
                            break;
                        }
                    }
                }
            }
        }
        <snip>

 

If I remove the second exists check, it fails occasionally. With that extra check, it does not.

If I remove the VisibleOnScreen supported action, it fails occasionally, even while every object always should have it.

 

  • Manfred_F's avatar
    Manfred_F
    Regular Contributor
    9 years ago

    Yes, You Need all kinds of caution.

     

    I use the following pattern, see attachment:

     

    • disable error handling
    • try several times
      • execute the steps
      • on success leave Loop,
      • on error
        • reset error
        • wait a Moment
        • stay in Loop
    • enable error handling

     

    This allows me to use rather straight-Forward code..