I’m developing an app to run on RPi, so it’s a Linux/Desktop app. I’m using the following in the Activate event of each Window in the app:
app.MouseCursor=System.Cursors.InvisibleCursor
…and it works to ‘hide’ the MouseCursor, but only when the mouse position is moved slightly. The app is a touch-screen piece of instrumentation, and I’d like to keep the interface clean and get rid of the mouse all together. For whatever reason the “arrow” cursor appears onscreen when the apps finished showing the Window, and the moment you move the mouse it then properly hides, and stays invisible for the remainder of the time, until you change screens (do a Show of a new Window in the app).
Is there a way for me to call a function to ‘move’ the Cursor off-screen? My assumption is that if I both move it, and hide it, that this will assure the desired behavior.
I sure have. In fact I’ve placed that line of code in the App Open event, the Windows Open event, and the Windows Activate event. I’ve currently got it in all three places and the behavior is identical. Again it works to hide the cursor - but only if you wiggle the mouse (or in my case, touch any point on the capacitance touch-screen). Which takes me back to asking, is there a way to programmatically move the mouse off-screen?
Are you sure it has to do with moving the mouse? Sounds to me like the cursor view doesnt refresh automatically and the move triggers the refresh. Bad thing is: MouseCursor has no view property. Nothing changed then, without declares I see no way. Maybe time for a feedback request to add an invalidate to a mousecursor change? (If it should be the reason)
I’m seeing this effect on the Pi as well.
It doesn’t matter where you put the System.Cursors.Hide statement or if you use me.MouseCursor=System.Cursors.InvisibleCursor, the mouse doesn’t
dissapear until you manually move/wiggle it.
There is a package for raspbian called unclutter that douses the cursor after a second of non-use.
Once gone, it stays gone.
I’m using unclutter to hide the cursor on Linux (Raspberry Pi, Jessie).
Ultimately I’d rather see the Xojo engineers fix the Linux support to correctly hide the cursor. I submitted a feedback case on this a while back titled “System.Cursors.Hide fails on Linux”: <https://xojo.com/issue/45772>
If you want this fixed in Xojo please add it to your Top Cases to help it get more points.
Sounds like we’re running out of time to use unclutter now based on other posts here about it [url=https://forum.xojo.com/30278-raspian-issue-with-hiding-cursor-not-a-xojo-problem/0]not working on the latest release of Raspbian (Stretch).
From what I have observed, the cursor stays initially because the Xojo app doesn’t automatically get keyboard & mouse focus when it starts. It’s not Xojo’s fault the window manager doesn’t set focus to the app.
The app starts full screen and runs, but the cursor stays ON until you tap/click the screen/window, which forces focus to the app, which then hides the mouse.
I found unclutter to be a simple fix to hide the cursor on startup (before focus changed).
The best solution is to figure out how to grab the focus when the app starts via a declare or shell command.
I’m looking for the solution when I have time.
I found a way to make the mouse pointer disappear without needing to move or click the mouse. What I posted in the link below isn’t a polished final answer (although it might be acceptable).
In my case my app is launched by the user (portable digital signage needs for conferences) so it gets the focus and the cursor properly hides now …
William Yu at Xojo updated my feedback case to suggest using Self.MouseCursor = System.Cursors.InvisibleCursor and that fixes the issue for my needs. Once my Linux (Raspbian Jessie) app starts up and the user enters a bit of data the app then runs in an unattended mode (digital signage) and the cursor is never needed again in the app.
I dont recall how I missed setting the cursor to “System.Cursors.InvisibleCursor” unless this was added recently. I see that using this was also mentioned by Wes in another forum thread.