Forum Discussion

Mike9's avatar
Mike9
Occasional Contributor
4 years ago
Solved

Not stable object path to the "Programs and Features" window

Hello everyone,

In my test should be checked info about the installed app via the "Programs and Features" window.

I have identified the object path to this window by the "Object Spy" function of TestComplete.

Afterall I faced with next issue:

- If I have opened any projects in TestComplete, the object path to the "Programs and Features" window will be:

Sys.Process("explorer", 2).Form("Programs and Features")

 - If I don't have any opened projects in TestComplete, the object path to the "Programs and Features" window will be:

Sys.Process("explorer", 2).Window("CabinetWClass", "Programs and Features", 1)

 

It reproduces on my PC: win10 x64, TestComplete 14.3 (I have reinstalled TestComplete v 14.4, but is still reproduced)

It doesn't reproduce on my colleague`s  PC with the same basic config - win10 x64 + TestComplete 14.3

 

Will be appreciate for any info about this issue - how it could be fixed or at least why I am getting such behavior...

 

  • If you were using NameMapping, this could probably be resolved using something like a conditional mapping or some subset of properties that would identify the object as a stable object regardless of whether it is "Form" or "Window".

     

    So, you could PROBABLY also find it using a FindChild or FindChildEx method to find the child object that matches a set of criteria.

     

    Go to the Object browser and get us screenshots of the object in question.  Please give the "Advanced" view of properties and include as many as possible.  Also, if you can do that for both the "Form" and "Window" instances, that will help greatly.  We can then assist with some logic to find the object.

     

    My guess, in pseudo-code, is that it will look something like this.  NOTE: THIS CODE IS NOT TESTED AND SHOULD NOT NECESSARILY BE USED AS IS.

     

    var objectToFind
    
    objectToFind = Sys.Process("explorer", 2).FindChild(["ObjectType","ObjectID"],["Form","Programs And Features"])
    if !objectToFind.Exists {
        objectToFind = Sys.Process("explorer", 2).FindChild(["ObjectType","Caption"],["Window","Programs And Feature"])
    }
    if objectToFind.Exists {
       Log.Message("Found it")
    }
    else {
        Log.Message("Object Not Found")
    }

       

5 Replies

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    If you were using NameMapping, this could probably be resolved using something like a conditional mapping or some subset of properties that would identify the object as a stable object regardless of whether it is "Form" or "Window".

     

    So, you could PROBABLY also find it using a FindChild or FindChildEx method to find the child object that matches a set of criteria.

     

    Go to the Object browser and get us screenshots of the object in question.  Please give the "Advanced" view of properties and include as many as possible.  Also, if you can do that for both the "Form" and "Window" instances, that will help greatly.  We can then assist with some logic to find the object.

     

    My guess, in pseudo-code, is that it will look something like this.  NOTE: THIS CODE IS NOT TESTED AND SHOULD NOT NECESSARILY BE USED AS IS.

     

    var objectToFind
    
    objectToFind = Sys.Process("explorer", 2).FindChild(["ObjectType","ObjectID"],["Form","Programs And Features"])
    if !objectToFind.Exists {
        objectToFind = Sys.Process("explorer", 2).FindChild(["ObjectType","Caption"],["Window","Programs And Feature"])
    }
    if objectToFind.Exists {
       Log.Message("Found it")
    }
    else {
        Log.Message("Object Not Found")
    }

       

    • Mike9's avatar
      Mike9
      Occasional Contributor

      tristaanogre, thanks a lot for your suggestion.

      Yeah, it could help, but it tries to resolve an issue with the object path on my PC by code in the test. I am not sure that it's a useful thing to include such kind of a workaround into the test. First of all, nobody else will understand why that code is there...
      I assume that should be some mechanism to "switch-off" mentioned path changing or at least should be the root cause of such behavior...

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor

        I'm not sure why you are arguing against using code to solve an object identity problem that is not related to the application under test at all.  This is a Windows OS situation, I'm pretty certain, and not really impacting the AUT, so it's a solution to allow the automation to continue.

         

        As for other solution to "stablize" windows...  I can't help you there.

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    Can you clarify please what specifically you are testing?  Are you testing whether or not an application has been installed?  Are you testing specifics about how that application shows up in the Programs and Features window?  Depending upon your answer, there may be a more reliable way to meet your need than checking that window.

    • Mike9's avatar
      Mike9
      Occasional Contributor

      Hello,

      I am testing next steps - does app contains correct version, icon, help link, and support link in "Programs and Features" window after installation. I know, that this information could be gathered from another resource e.g. *.dll file etc, but according to our tests, we have to check exactly on the "Programs and Features" window.

      Moreover, I want to understand why I am getting a different object path depending on the opened project...If I will get this understanding it could help me to avoid such situation in the future with any other window/app.

       

      thanks in advance