When using Simulate Click with Java-programs, UiPath Studio times out after clicking on a button that shows a modal window, unless you close the modal window manually.
I have created a demo to demonstrate the bug. The process is to click a button to show the window and then click OK to close the window. Clicking on the button that shows a regular window works fine but clicking on the button that shows a modal window results in a timeout and a “Click generic error”.
Current behavior: UiPath Studio clicks the button and wait until the modal window is closed or the timeout is reached.
Expected behavior: UiPath Studio should consider the click as successful and not wait for the modal window to close.
Workarounds: switching to Hardware Events or using Parallell activity.
To recreate the bug:
Run the java program (you will need the Java runtime): java -jar DialogTest.jar
That’s not a bug, that’s expected behavior of any application when there is a modal dialog. Modal dialog literally means you can’t do anything else until you clear the dialog. If you need to wait until the dialog disappears you can use Check App State for that.
I don’t agree. A modal dialog box is for preventing the user from interacting with the main window. It shouldn’t however prevent UiPath from considering the click as done.
An example where simulate click works as it should (Notepad, not a java program).
The dialog box “Do you want to save changes …” is a modal window:
And the following workflow works fine because UiPath doesn’t wait until the modal window is closed:
If the click close fails that has nothing to do with the modal dialog because it hasn’t gotten there yet, that’s because you’re using the wrong mode, a mode not supported by the application. As you said, hardware events works. So use that.
The click doesn’t actually fails. The click is performed and the modal window is shown. The issue is that UiPath doesn’t consider it a successful click, thus leading to a timeout and an error. This is the bug I want to report. For now I have used the workaround but it would be nice we didn’t have to resort it.
It depends. Click with Simulate uses native Click APIs that Java objects expose. When a click is done on a modal window, that window opens and blocks the thread, thus blocking the response from the Java application to the Robot and causing a Timeout. If the window would close (in any manner), the thread would continue its execution. The workaround provided is used to make the click on a new thread in the Java app and avoids waiting for an answer.
To answer whether it is or not a bug, I would say that it isn’t, because in a sync manner, one would like to know if the Click with Simulate was executed successfully or not, so the Robot should wait for the answer.
However, we should expose the async flag in a better way.
Ok, thanks for the explanation! This means that Simulate Click in Java programs that results in a modal window is more or less useless since the robot will be waiting for answer that will never come. Since the workaround with UseNonBlockingInput doesn’t wait for an answer, is there any added benefit to use it instead of Hardware Events?
Hardware Events method relies on the element location on the screen to know where to click. Therefore, Simulate still remains the only method for any kind of scenario when the app can’t be on the screen (the app is minimized, the app is covered by other apps, unattended, etc).
This is not correct. I use Hardware all the time for unattended automations. And if the app is minimized or covered by another app, that’s what the Activate property is for.
Anil_G
Yoichi
Chirag_Shetty_Divakar
fernando_zuluaga
Jithesh_R
loi.nguyen
Samraat_Maharjan1
prabin_chand1
supermanPunch
supriya117