Mouse cursor always shows Busy.... Used Function : Cursor.Current.ToString

Scenario: when I am trying to get the status of cursor by System.Windows.Forms.Cursor.Current.ToString it is always returning [cursor: waitcursor] even if cursor is not busy

image

Current Behavior: always shows wait

Expected Behavior: should say default if cursor is not busy

Studio/Robot/Orchestrator Version: 2019

OS Version: windows 10 enterprise

@loginerror @lakshman @KarthikByggari

1 Like

On this page you can see all type of cursor… like default, busy, pointer, blocked, resize etc.
https://www.w3schools.com/cssref/tryit.asp?filename=trycss_cursor

one new issue found… I run the function in a do while loop just by setting 1=1 in condition and tried by hovering the mouse on various mouse type on the above w3schoos page. and found that on everytime when we run the workflow ? on 1st loop its show busy status. and in the remaining loop its shows default status. Without knowing the real status of the mouse.

image

Find The Workflow Here Test Workflow.xaml (6.8 KB)

Hi @Tech_Guru

Thanks, I reported the issue for our team to have a look.

1 Like

Thanks Respected Sir… Hope the bug will be fixed in the latest version.

#_I_Love_UiPath

1 Like

Hello! what is the situation? I tried it on 2020.10 and still not working :confused:

Still not fixed yet, and I’m not sure it will make the 21.4 release, as it’s not something we have several other more significant things on the backlog.

May I ask why you see it as worthy of tackling in favor of other issues? Can you describe a use case where this bug is preventing you from achieving what you wanted to do?

ok. I understand.
Well it would be quite useful for some Java applications or custom made applications that makes UiPath robot.executor crash. It happens when the App is loading (mouse cursor changes) and one Window has not yet appeared. but an UiPath activity is looking for it (wait element, find element, click… any activity with selector targeting the new window).
We also openend a ticket for it. but getting the cursor state would have been a nice solution. now we use unfortunately a delay…
It would be a strong way to make the robot wait until the apps are ready (when no loading bar or other exists)

Thank you for your explanation @yrobert!

In your case, there’s a good chance some other app or Windows service will change the cursor as well. Won’t that trick you into thinking that your Java app is still loading? Is there no safer workaround for what you are trying to accomplish? Find Element seems like a good candidate in this case, right?

Well, find element and similar activities make the robot.executor crash…
but you are right, the risk is here that other apps make the cursor change. it is a solution for a specific case.

Crashing executor when finding elements sounds like a problem more worthy of fixing.

Have you reported it anywhere? Can you provide any specifics? Does it reproduce with any Java app? Does it depend on Windows/JVM version? Are you using the latest Robot and UiA pack?

1 Like