"Run Keyword In Seperate Thread" Problem

Robot Framework
1

Hi there,

im testing a Java-Swing-Desktop-Application on a LINUX. For this I am using robot-framework with RemoteSwingLibrary.

So far it works amazing!

Yesterday tho i stumbled upon a problem which I just cant seem to solve, even tho im super confident with my solution.

so the problem is:

in the desktop application that im testing, there is a “SaveButton”.
When i click on it, a popup appears with “OK” and “CANCEL” button. (i click on it with the keyword: “Click On Component saveButton 1”)

Unless the “OK” and “CANCEL” button have not been pressed, robotframework is stuck and not continuing the script. It also doesnt timeout. it just waits FOREVER for the “OK” and “CANCEL” button to be pressed.

I assume that robotframework is waiting for a return value and will not do any action before it returns.

So i thought to myself, ok, lets use the keyword “Run Keyword in Seperate Thread” so that one thread clicks on the “SaveButton”, while the other thread sends keyboard event “ENTER” to take care of the popup, but it does not work.

this is the script:

image
image1920×616 53.2 KB

this is the log:

image
image1920×852 94.7 KB

this is how he is stuck, if i use “Click On Component jButtonFirmSave 1” without the “Run Keyword in Seperate Thread”:

image
image1968×1384 220 KB

as you can see, he is stuck at the stage “click on component” forever, instead of continueing with “Sleep 5s” and “send key event ENTER”

2

I realize this is an old question by now, but hopefully this is helpful to someone.

There are 2 issues worth talking about here

1) The error message about the expected number of arguments
In my opinion this is a swing library bug, but not one that is hard to work around. I submitted an issue on the swinglibrary github project for this, so we’ll see if it gets fixed down the road. Basically, the Run Keyword in Separate Thread keyword does not properly support keywords that have default parameters. It sees that Click On Component takes 3+ arguments (identifier, times, buttonString and *keyModifierStrings) but it ignores the fact that times and buttonString are optional arguments.

So you can fix this error by simply changing it to Run Keyword In Separate Thread Click on Component jButtonFirmSave 1 BUTTON1_MASK

2) Why it didn’t work originally: Modal dialogs will block the EDT

This is the original problem that you were trying to solve. All user interactions with swing GUI components should be handled by the Event Dispatch Thread (EDT). When the EDT displays a modal dialog, it should block until that dialog is closed. So ignoring robot framework for a second and just going back to plain old Java, if you have:

```
System.out.println(“About to show confirm dialog”);
JOptionPane.showConfirmDialog();
System.out.println(“Done”);
```
You would see that it prints out the first line, then shows the confirm dialog, and then does not print out “Done” until the dialog is closed. So you might wonder how the OK button on the dialog works if it must be executed on the EDT and the EDT is blocked. The way that works is actually pretty cool and it uses something called sub-loops, but basically the whole EDT isn’t blocked, it just goes into a new event dispatching loop and keeps going there until the dialog is closed. If that went over your head, that’s fine, it’s beyond the scope of this answer.

So this poses a problem for robot framework because robot framework must run the part of the Click On Component keyword that actually clicks on the component on the EDT, but then it gets blocked waiting for it.

Your solution is the right approach by running that keyword on a separate thread. It will still end up running the actual clicking part on the EDT, but you won’t have to wait for it so you can continue onto the next keyword which will eventually execute on the EDT, but inside an event sub-loop.

So, long story short: your solution is the right one but hopefully this helps explain why it is the right one. The actual error you saw has to do with the Run Keyword in Separate Thread keyword and how it handles optional arguments. The fix is to just add in the default values for each argument.