Forum Discussion

ory_z's avatar
ory_z
Contributor
15 years ago

Auto Wait for CMD window can't be changed

Hi there,



I'm currently using an application in my tests that is not the actual SUT but helps me to perform some tasks that are needed. When clicking a certain button in the application it executes a predefined script in a new CMD window. The problem I'm having is that TestComplete seems to be waiting for a defined period of time after clicking the button, before continuing to the next step or line in the test script.

At first I thought it's the project's auto wait period (the wait time is around 10s), but changing the project auto wait timeout property to even a 100 doesn't affect this wait time.

I then tried manupilating it in a script using the following syntax (VB):

    Options.Run.Timeout = 100

    Call Aliases.CardSharkCryptoSW.dlgCardShark.RunESLScriptBtn.ClickButton

    Options.Run.Timeout = 10000



This also didn't help. So I tried to debug, added a breakpoint on the first line, and when the execution was paused, I Evaluated the expression "Options.Run.Timeout" but it returned 50... Stepped over the next two steps and kept evaluating the expression. Turns out it always returns 50, not sure if a bug or not?



So what is causing the test execution to pause for 10 seconds after the execution of the script in the CMD window?



Thanks

20 Replies


  • Hi Ory,





    When your original test is stopped at the breakpoint, the separate thread executing the asynchronous operation is also paused. This is a specific of the script debugger - it pauses all executing script if even only one of them is paused. So, this your experiment shows that the asynchronous call actually works as expected.





    That is why it is necessary to try to get CMD windows several times in a loop. The first attempt of getting the CMD window can fail since the Run ESL Script button is not clicked yet.





    However, I think that it is possible to click the button asynchronously without using the CallObjectMethodAsync method in this case. Probably, this approach will work better for you:







    ...

      '  Call Runner.CallObjectMethodAsync(Aliases.CardSharkCryptoSW.dlgCardShark.RunESLScriptBtn, "ClickButton")

      MyClick Aliases.CardSharkCryptoSW.dlgCardShark.RunESLScriptBtn

    ...





    Sub MyClick(obj)

      x = obj.ScreenLeft + obj.Width / 2

      y = obj.ScreenTop + obj.Height / 2

      

      Call LLPlayer.MouseDown(MK_LBUTTON, x, y, 0)

      Call LLPlayer.MouseUp(MK_LBUTTON, x, y, 100)

    End Sub
  • Hi David,



    Sorry to revive an old thread, but since the history of the situation is recorded in this thread, I think its best if I raise the following issue here.



    For the past few months we have been using the ASynchronous call as you suggested.

    We are now in the process of transferring our common library into script extensions, and it turns out that when wrapped inside a script extension, the CallObjectMethodAsync method does not seem to execute (the button is not clicked).



    Is this a known issue/script extensions specific?
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    As per the help documentation on Script Extensions and supported objects, the LLPlayer object is not available within script extensions.  If you're using the "MyClick" method described above which calls the LLPlayer methods, then this may be the root of your problem.  What you might need to do is investigate using direct calls to the windows API for executing mouse clicks (which is what code like LLPlayer and other things essentially do).  http://msdn.microsoft.com/en-us/library/ms646260(v=vs.85).aspx
  • Hi Robert,



    Thanks for the quick response.



    According to the documentation the Runner object should work in script extensions, therefore I expected the CallObjectMethodAsync method to work...



    Can you provide me with a link to the documentation you are referring to?



    Just to be clear, this is the line that does not work:

    Runner.CallObjectMethodAsync(Aliases.CardSharkCryptoSW.dlgCardShark.RunESLScriptBtn, "ClickButton");



    Also what would the code look like (in JScript) when trying to use the win API?



    Thanks

  • Hi Ory,



    The CallObjectMethodAsync method should work in a script extension. I have just checked this and it works for me. I am not sure why this does not work for your specific case. Could you please check whether this method works for another button in your application and/or in another application (e.g. in Notepad)?



    As Robert has mentioned, the LLPlayer object is not available in a script extension. Unfortunately, calling the mouse_event function from the Win32 API is impossible since the DLL object is not supported by script extensions as well.
  • Hi David,



    Thanks for the response.



    A quick check shows that you are right, the ASynch method works on other buttons.



    I have recorded a video to show the difference in execution between clicking the button and using the ASynch method:

    http://screencast.com/t/nHfxoKIaNz



    Although in the video clicking the button took a long while (almost a minute), other tests (calling the method normally - not through script extensions) show that both the normal method and the ASync method take the same amount of time - about 13 sec (see below I re-recorded how a successful execution looks like). Therefore I'm unsure that we are even saving time using the ASync method...!

     

    Anyway as you can see in the video (I had to pause it btw, it takes quite a long time to execute fully) after the command to click the button, the button does not apear to be clicked (CMD window is not launched), and TC keeps looking for the CMD window (those are all those delays you can see). Eventually an exception is thrown (not sure why, the code referenced appears OK), the CMD window is finally launched but at this stage TC is no longer responding. You can't see it in the vid but clicking Stop does nothing and ends with the same result as closing the CMD windows (which pop one after the other - not sure why?) - TC crashes. Because it crashes I can't see the logs to understand exactly what is happening.



    Anyway I've attached some dumps, maybe you guys can make more sense of them than I.



    Obviously this problem is specific to our scripts and our SUT.



    Here is a second vid of a successful execution, using normal click method in Script Extensions:

    http://screencast.com/t/65z9OZvw6bIB



    You can see in the log that it takes 13s between clicking the button and recognising the CMD window - still much too long for such a mundane simple action (this executes allot during a full run).



    Any suggestion is welcome!



    Thanks
  • Hi Ory,



    I have discussed this situation with our development team and it seems that the CallObjectMethodAsynch was not designed to work in a script extension. However, since it works in other cases, we could try to make it work in your case as well. However, we need to reproduce this behavior locally in order to investigate it. Also, we could try to suggest something else if we had your application here. Is it possible for you to provide us with your application in any way (an installation package or a prepared virtual machine)? If this is possible, please contact us regarding this question using the Contact Support form.
     



    Although in the video clicking the button took a long while (almost a minute), other tests (calling the method normally - not through script extensions) show that both the normal method and the ASync method take the same amount of time - about 13 sec (see below I re-recorded how a successful execution looks like). Therefore I'm unsure that we are even saving time using the ASync method...!



    We have discussed this question before and have found that the time won by using an asynchronous call is significant:


    According to the logs you posted, the asynchronous test works for 16 seconds while the usual test works for 35 seconds. In my opinion, this is a significant difference that shows that the asynchronous approach works in your case. The time spent while the asynchronous test is executed is needed for TestComplete to get the needed information on application objects and build the object tree. I think that there is no way to reduce this time.
  • Hi David,



    Unfortunately it is impossible for us to supply you this specific software as it is internal only (very sensitive) and relies on interaction with hardware (Card Reader) as well as crypto modules.



    However I believe it should be pretty easy to simulate. After all it is a normal CMD window that is being called. I would hazard a guess that any windows application with a button that would call a CMD window execution (maybe a batch file as an example) would be similar, but I could be wrong.



    PS - As par other issues I have raised in regards to the use of Script Extensions, I hope documentation is being updated according to these findings (i.e. ASync not meant to work through Script Extensions). I find the Script Extensions current documentation (I mean mainly the areas involving why to use, limitations, objects available, specifics etc.) to not be in the same level I got accustomed to from other TestComplete docs.

  • Hi Ory,



    However I believe it should be pretty easy to simulate. After all it is a normal CMD window that is being called. I would hazard a guess that any windows application with a button that would call a CMD window execution (maybe a batch file as an example) would be similar, but I could be wrong.
    I have tried creating such a sample some time ago, but I failed to reproduce the problem you are facing with it. I have not tried to test such a sample application with script extensions, but I do not think that there will be any problems as there were no problems like those you reported before.



    It is possible that the problem can be specific to a way the CMD window is opened. Could you please provide us with the application's source code that handles the button click and runs a batch file in a CMD window? I will try to use this code in order to create another sample.



    PS - As par other issues I have raised in regards to the use of Script Extensions, I hope documentation is being updated according to these findings (i.e. ASync not meant to work through Script Extensions).
    I have registered your request to clarify usage of this method from a script extension in our Help system. Thank you.