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 as com.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
That's a question that should be directed to Support. Here's the link: