I have an application that should show a Wait cursor when an operation (a file download) starts and then return to a StandardPointer when the operation finishes. The wait is initiated by a button press and finishes when the UrlConnection FileReceived event triggers.
This works fine as far as the start and finish events are concerned, but I’ve noticed that one part of the UI (a DesktopListbox) doesn’t show the wait cursor during the operation. If the mouse is outside the listbox it shows a little watch, but if I move the mouse over the listbox it shows the normal north-west pointer. Once the operation is finished the standard pointer shows everywhere.
Can anyone point me to what may be going wrong here?
If you can reproduce it in a sample, report it. https://xojo.com/issues
Every RectControl or DesktopUIControl (each of their descendants) has a MouseCursor property. This property defines the mouse cursor while the mouse is over that control, if set. If the mouse is not over a control, or no control under the cursor has this property set, the corresponding property of the window or the app is used.
So, likely, that listbox sets that property to something other than Nil.
But don’t you then you have two conditions. When over the list box AND when that download is in operation, the watch cursor is desired. Is there an option to put that logic in the MouseCursor property for the listbox?
Yes, obviously. But that’s why there is precedence.
I assume the download condition is covered by setting the cursor on the window or the app. The control has a higher priority.
It sounds like the entire window is supposed to be disabled until the download finished. I would suggest placing a Canvas control over the window’s area that has the appropriate cursor set. This will prevent the user from interacting with the controls until the download finishes and you can hide or destroy the Canvas.
Alternatively, display a modal progress dialog.
Considering the documented way MouseCursor is supposed to work, I’d like to circle back to Rick’s answer. If DesktopListbox.MouseCursor is nil and is overriding either the App or Window MouseCursor property by clearing the cursor, it is misbehaving. File an issues ticket if you can reproduce it.
1 Like
The user would still be able to interact with the controls using the keyboard or accessibility calls, though.
Thanks for the responses. I hadn’t appreciated that individual components can have their own MouseCursor settings. I am using app.MouseCursor. I tried setting wMain.MouseCursor instead to see if that removed the listbox issue, but it didn’t. So now I’m setting both the app.MouseCursor and the lstProjects.MouseCursor and the application now behaves as I would expect. I’m still a bit confused because in the docs it says:
“If the DesktopApplication class’s MouseCursor property is not Nil, then it controls the shape of the pointer and a window’s and any control’s MouseCursor property values are ignored.”
Report it, please, or the bug won’t be fixed.
Yes, I’ve reported this. Thanks.
1 Like
Sorry to resurrect an old thread, do you have the issue number for this? I’m getting bitten by the same bug and I’d like to track the issue.
I asked a search on Wait Cursor (in the Issues page) and get:
1 Like
Thanks @Emile_Schwarz, my search must have been too narrow and I missed it. Cheers.