Forum Discussion

SangeetNenwani's avatar
SangeetNenwani
Contributor
4 years ago
Solved

"WaitAliasChild" is taking too much time with TC 14.9. Tried other wait method but it didnt help

During Opening of an application, we check for different popup windows if we are expecting error or something other type of popup.
With TC 14.7 and previous version it was working fine. But with 14.9 it started to take a lot of time. and on different PCs if it taking time for waiting for different popups.
I tired "WaitProperty" but It didnt help. WaitChild didnt help because of subchilds and we are using Alias names

7 Replies

Sort By
  • KGP_Softing's avatar
    KGP_Softing
    New Contributor
    4 years ago
    Copy Link

    We have the exact same issue with Version 14.92.596.7.

    Some testing showed, that if the Window that is waited for is visible WaitAliasChild works as expected. But if the Window only exists but is not visible it waits for (I guess) the AutoWait time and then returns with the correct window. I checked that the NameMapping does not contain the visible attribute as criteria (Just WindowsClass and WindowCaption) and no "Required Children" are marked. So Mapping is simple and no childs are in between the object that calls WaitAliasChild and the Child that is searched for.

     

    Is there already a solution or workaround? Or do I also have to create a SupportTicket?

     

    Thanks

    • sonya_m's avatar
      sonya_m
      Icon for Alumni rankAlumni
      4 years ago
      Copy Link

      Hi KGP_Softing , here's the official support team's reply:

       

      >>

      I would try to add some extra Log operations inside the loop and IF statements, just to see how many times TC goes through the loop and different IF statements. Thus, in the log, you will be able to see something useful - e.g. at which point TC spends too much time posting the message in the log.
       
      Also, you can try using the suggestions from these articles:
      * https://support.smartbear.com/articles/testcomplete/test-playback-performance-tips/
      * https://support.smartbear.com/testcomplete/docs/working-with/best-practices/performance-tips.html
      * https://support.smartbear.com/testcomplete/docs/working-with/best-practices/tips.html
      Also, you can try to disable unnecessary plugins in the Install Extensions [https://support.smartbear.com/testexecute/docs/working-with/extending/installing-extensions.html] dialog.

      <<

      • KGP_Softing's avatar
        KGP_Softing
        New Contributor
        4 years ago
        Copy Link

        Hi Sonya Mihaljova,

         

        I found a property in the TestComplete Settings that influences this behavior which is not exactly related to WaitAliasChild. 

        Tools->Options->Engines->Name Mapping-> "Search for visible objects first"

         

        I created a small Demo that uses Notepad++ because here the "Find" dialog is always available but not always visible. (See attached project)

        When I call "Aliases.NotepadPP.dlgFind.Exists" its ok that it waits for the AutoWait Timeout if another Window with the NameMapping criteria will exist that is visible. As its described in the Documentation for the property mentioned above.

         

        But when I save the object that is returned by "WaitAliasChild()" I would expect (and like it was in the previous Versions of TestComplete (14.7 and previous)) that accessing a property it does not wait again the AutoWait Timeout.

        Example:
        set wnd = Aliases.NotepadPP.WaitAliasChild("dlgFind", 0)

        Log.Message wnd.Exists

        WaitAliasChild returns immediately but accessing the Exists property waits for the AutoWait Timeout, which makes the WaitAliasChild in this case useless. I would expect that the saved object will not wait again because the window was found and this was the behavior in TestComplete before even if the property "Search for visible objects first" is enabled.

         

        Can you please clarify how this should work, because the documentation does not explicitly talk about it. If we know that this behavior is now fixed and correct we have to handle this when we want to keep this update.

         

        Thanks in advance.