ContributionsMost RecentMost LikesSolutionsRe: Slow object recognition working with swing application The archive contains the demo project and java application. Re: Slow object recognition working with swing application Thanks, Your idea is right, as it seems to me. After some experiments it became clear, that in my case the reason of the long time delay is that the objects being recognized are positioned on the window tabs that have no focus. It was possible as the code only needed to read their state, not to change. After adding to my code the swithching to a tab before accessing its controls the script was performed quickly. Now I'd like to know - is it a bug of TestComplete or of the application under the test? Re: Slow object recognition working with swing application It was not a right thought aboutAuto-wait timeout. If it was reached the script would be stopped with error message. Most likely delay is a little smaller in my case. Re: Slow object recognition working with swing application Hibrumazz, 1) For identifying each object only the unique id is used that is assigned to it by swing. I think, if the problem was in name mapping, it would occur persistently. 2) I am attaching two fragments of the log that refer to the same run of the script. In these fragments the record 'Checking Certificates Tab' is placed to the log by a function which checks controls on specific tab of the window. This tab contains 4 objects of type JTable and 16 objects of type JButton. Function gets the state and content of these objects and compares the data to state saved previously. During the run the window was opened twice for different tasks. During the first opening the objects recognition was slow. It took 10 seconds per object, so the total time for function call was approximately 3 minutes. For the second time the function call was shorter than 1 second. Regards P.S. I wonder, is it occasional coincidence that the Auto-wait timeout in Playback section in project properties contains the value of 10000 ms? Slow object recognition working with swing application Hi everybody, I am working with the automated tests for a swing application. Tests are being developed for rather long time. Usually they are performed with a good speed. But sometimes the objects recognition becomes too long - it takes up to 10 seconds per object. And, that is even more surprising, an object is not remembered after it was recognized. Next reference to its alias in script code forces the recognition again. Another thing that is unusual is that for some windows belonging to application the recognition is fast and for some others it is slow. I have not any guess why this happens. Some time ago this issue encountered after I had installed the new version of TestComplete instead of 14.74. And when I had returned back to 14.74 everything became good. Now I observe this behaviour for both 14.74 and 14.92 versions which I try to use for tests. And one more strange thing is that the tests were running good for current application version for last two weeks. Regards Re: low-level mechanism of modifying the state of java controls 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 theSetTextaction changes the object text programmatically, so, it may take less time to execute. TheKeys,KeyDownandKeyUpmethods, in their turn, simulate actual key presses in the object, taking into account theKey pressing delayproject 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 toSetTextin 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. Re: low-level mechanism of modifying the state of java controls >IfLicenseCustomerCode 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 theSwingUtilities.invokeLater method when changing the state of a control bythe 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 Re: low-level mechanism of modifying the state of java controls Thank you, we have done it and are waiting for reply now 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.LicenseCustomerCode.wText := some_code; In the application's Thread Dump an alien thread is present that was created very likely on behalf of TestComplete. The call stack of that thread is as follows: "Thread-38129" prio=5 tid=950b RUNNABLE [3b88f3d9] at java.lang.Thread.dumpThreads(Native Method) at java.lang.Thread.getAllStackTraces(Unknown Source) at com.sterra.vdb.cache.VdbBase.check_vdb_readable(VdbBase.java:69) at com.sterra.vdb.cache.VdbTypes$VdbVpnProductImpl.name(VdbTypes.java:5380) ..... at java.lang.reflect.Method.invoke(Unknown Source) at com.automatedqa.testcomplete014_007.JavaUtils.Method_invoke(JavaUtils.java:27) As the developers say, the failure occurred because this thread tried to get access to a resource that is not allowed for threads other than main GUI thread. To get the understanding of what is happening, we'd like to know: 1. Why the new thread should be created in the context of the application process under the test? 2. Would the TestComplete lost it's functionality if this thread was not created? 3. What kind of code is executed by this thread? In the call stack this code is named ascom.automatedqa.testcomplete014_007.JavaUtils.Method_invoke(JavaUtils.java:27) 4. If this code is for changing the contents of the window's text field, why the function is called that accesses the inner resource:com.sterra.vdb.cache.VdbTypes$VdbVpnProductImpl.name(VdbTypes.java:5380) ? 5. Are there some specific rules or limitations for developers writing the java applications to guarantee such failures do not occur during the tests? Thanks for you help Solved