Forum Discussion

rvg's avatar
rvg
Occasional Contributor
4 years ago

low-level mechanism of modifying the state of java controls

While running a test for  java application we get the unexpected exception at some point. The line of code in TestComplete script which generates the exception is like this:   win.LicenseCustomerCo...
  • AlexKaras's avatar
    AlexKaras
    4 years ago

    Hi,

     

    > win.LicenseCustomerCode.wText := some_code;

    If LicenseCustomerCode is an editable control, you may try something like this:

    win.LicenseCustomerCode.Keys(some_code);

     

    Does it help?

     

AlexKaras's avatar
AlexKaras
Champion Level 3
4 years ago

Hi,

 

> win.LicenseCustomerCode.wText := some_code;

If LicenseCustomerCode is an editable control, you may try something like this:

win.LicenseCustomerCode.Keys(some_code);

 

Does it help?

 

  • rvg's avatar
    rvg
    Occasional Contributor
    4 years ago

    >If LicenseCustomerCode is an editable control, you may try something like this:

    >win.LicenseCustomerCode.Keys(some_code);

     

    >Does it help?

     

    Yes, thank you!

    But the problem is more complex as it seems to me. Not all controls being changed by the test have the 'Keys' method. It seems that there is some kind of inconsistency between the application behaviour and the logic of TestComplete while it uses a new thread to change the application controls.

     

    As it is known from the papers for java writers, the multithreaded gui should use the SwingUtilities.invokeLater method when changing the state of a control by the thread other than the GUI thread. We don't see the call of this method in the call stack of TestComplete thread. From the other side, we see the call of the Listener in the context of this thread. All this is not clear and produces many questions

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3
      4 years ago

      Hi,

       

      > Yes, thank you!

      Great, thank you for the confirmation.

       

      > Not all controls being changed by the test have the 'Keys' method.

      I think that it is better to clarify this with Support using specific control(s) as an example as been suggested by Marsha.

      As for me, wText property may or may not be modifiable. This can be checked in the Object Browser. Direct modification of the wText property sounds like the call to the .SetText() method (which you may also try, BTW) that directly assigns a value to the control, while some controls may be not designed for such scenario. So, if some control does not provide the .Keys() method, for me it looks like it cannot be modified by the human user and thus requires some special attention from the test writer. (Or not be modified from test code at all. Just because human user cannot do this.)

      But the above are just generic thoughts which, as I already wrote, I think better to clarify with Support.

       

      • rvg's avatar
        rvg
        Occasional Contributor
        4 years ago

        Hi,

        my thanks again for proposed simple solution. I realized better that it is useful after I had read the documentation, Simulating Keystrokes | TestComplete Documentation (smartbear.com):

         

        "Note that the SetText action changes the object text programmatically, so, it may take less time to execute. The Keys, KeyDown and KeyUp methods, in their turn, simulate actual key presses in the object, taking into account the Key pressing delay project setting. However, the key pressing methods also ensure that the appropriate keyboard events are raised in the tested application and the associated event handlers, if any, are executed. Therefore, these methods are preferable to SetText in certain cases."

         

        As the result, we have decided to replace the usage of .wText := ... and .setText(...) by the calls of Keys(...) method everywhere it is allowed by the control. The remaining cases are those where the controls have a derived java class that does not support the Keys() method and so it is required to call .setText(). For these cases the initial issue is actual as the calls may be  executed in the context of automation thread and lead to possible failure. We sent the request to support and now are waiting for the results of analysis.