Hiding the cursor

[dunbarx]

I thought this general enough to break this out into its own thread. it derives from:
viewtopic.php?f=104&t=39195

The question is "how does one hide the cursor?". I found that this works:

Code: Select all

on mouseUp
   set the defaultCursor to hand --or arrow, but nothing else
   set the  cursor to none
end mouseUp

Both lines are needed. A sample stack is attached. The point is that simply setting the cursor to "none" and locking the cursor does not work.

Craig

Cursor madness.livecode.zip

(1.21 KiB) Downloaded 160 times

[richmond62]

Over 'here' (MacOS 12) the following code:

Code: Select all

on mouseUp
   set the cursor to empty
   set the lockCursor to true
end mouseUp

Plays "silly buggers" with the cursor, in that, subsequently, the cursor flashes in and out of visibility!

And this:

Code: Select all

on mouseUp
   set the defaultCursor to hand
   set the cursor to empty
   set the lockCursor to true
end mouseUp

Gives me a flashing hand.

This:

Code: Select all

on mouseUp
   set the defaultCursor to hand
   set the cursor to empty
   --set the lockCursor to true
end mouseUp

works!

So, WTF is the point (if any) of set the lockCursor ?

And why is the Dictionary so 'misleading' (that's another way of saying WRONG)?

Why are Craig and I discovering THIS 20-odd years into the "RunTime Revolution Adventure"?

[dunbarx]

Richmond.

There is something "special" about "hand" and "arrow", in that those two styles actually hide the cursor in the two-line handler I posted, and it sticks as long as the user does not invoke an automatic cursor change like, say, entering a field (in that case the cursor reverts to an IBeam).

No other styles work.

Locking the cursor is supposed to prevent that sort of thing from happening, but it does not seem to. In a cursor gadget that uses anything but hand or arrow::

Code: Select all

on mouseUp
   set the defaultCursor to watch
   set the  cursor to watch
   set the lockcursor to "true"
end mouseUp

run that and then bring the cursor into a field. You get an IBeam. It goes against the dictionary, and what people expect.

So there are two things I am not getting:

1- How does the lockCursor property work?
2- Is the two-liner method the only way to hide a cursor?

Craig

[richmond62]

How does the lockCursor property work?

That's just a polite way of restating what I stated.

[dunbarx]

Richmond.

i have been saying this all along. You are welcome to join me.

Craig

[dunbarx]

OK, there is something wrong with either LC cursors or me.

This stack hides the cursor reliably (remember the original issue?) when clicking on the "Hide Cursor" button. The cursor will change to a watch when clicking on the "View Cursor" button. Any cursor style except arrow and hand will work in that button. Recall those are the only two styles that allow one to hide the cursor in the first place.

Don't even think about what happens if I try to change it to "none".

I hardly ever use different cursors. I just like wasting time, as evidences by the X and Y circles that show where the hidden cursor actually is and the colorization of the target button. The cursor reverts to arrow if you click on an empty part of the card.

Either I do not understand any of this, or there are oddities in all of this.

Craig

cursor insanity.livecode.zip

(1.1 KiB) Downloaded 171 times

[FourthWorld]

1- How does the lockCursor property work?

DefaultCursor and lockCursor solve related but different problems.

LockCursor premiered in early HC, a way to change the cursor beyond idle.

But this poses a problem: cursors are helpful indicators of interaction modes, so what do we do when we want an i-beam for text editing but a custom icon for everything else?

In the olden days we'd have to track mouse position and change the cursor to the image most appropriate for each object's interactions. Tedious, not fun,

So Dr Raney added the defaultCursor to do only what it says: aside from controls where users expect a distinct cursor (i-Beam in fields, pointer in the menubar, etc.), the default can be specified and it will remain in effect until the defaultCursor to is cleared, by setting it to "none", thereby resuming the engine default.

2- Is the two-liner method the only way to hide a cursor?

AKAIK, yes. One line to set the cursor to an empty image, and the other to make that change persistent beyond idle:

Code: Select all

on mouseup
   set the lockcursor to true
   set the cursor to empty
end mouseup

For slightly less typing, you can use the commands "lock cursor" and "unlock cursor" instead of the "set" command, similar to what we can do with the lockScreen property with "lock screen" and "unlock screen".

[dunbarx]

Richard.

The simple two-liner you posted only works once the cursor is outside the control that hid it. Not sure why, but it is unstable while within it. And if the cursor does indeed leave the control that hid it, and it moves around a bit outside invisibly, it will become unstable again if it moves back into its "starting" control.

Also, once outside, it will change into an IBeam if it encounters an editable field.

My two-liner at least works properly everywhere, unless, as you say, it needs to act as a helpful indicator. But this means the dictionary:

If the lockCursor property is set to true, the cursor shape can be set only by a handler, and does not change shape automatically as the mouse moves. (For example, the cursor normally turns into an arrow over a menu, an I-beam over an editable field, and so on.)

Is wrong then?

Not sure how much more we should beat this up, but there was an OP who asked...

Craig

[FourthWorld]

Richard.

The simple two-liner you posted only works once the cursor is outside the control that hid it. Not sure why, but it is unstable while within it. And if the cursor does indeed leave the control that hid it, and it moves around a bit outside invisibly, it will become unstable again if it moves back into its "starting" control.

Also, once outside, it will change into an IBeam if it encounters an editable field.

My two-liner at least works properly everywhere, unless, as you say, it needs to act as a helpful indicator. But this means the dictionary:

If the lockCursor property is set to true, the cursor shape can be set only by a handler, and does not change shape automatically as the mouse moves. (For example, the cursor normally turns into an arrow over a menu, an I-beam over an editable field, and so on.)

Is wrong then?

Not sure how much more we should beat this up, but there was an OP who asked...

What I described was the intention, addressing both use cases, and is consistent with what I see here.

If you see behavior with this long-established feature that differs from the docs, I would encourage a bug report.

I'd also be interested in learning the version you're using and in which OS version, to see if I can reproduce what you're seeing.

[dunbarx]

Richard.

Attached is a stack that shows the erratic behavior while the cursor is within the rect of the button.

I added a handler in the card script so that you can click on an empty portion of the card to restore the arrow cursor. Note the extra step needed to make that work. If you comment out the first two lines of that handler, it will not.

LC 9.6.9 Mac OS 13.4

Craig

WonkyCursor.livecode.zip

(828 Bytes) Downloaded 179 times

[jacque]

The erratic behavior is a bug introduced in LC 7. I needed the original behavior and submitted a bug report and it was fixed. But since the client was paying for a custom build, I'm not sure if the fix was rolled into LC proper. If so, it would be in the latest 9.x version or possibly the latest 10.

The correct syntax for hiding the cursor is"none" so I'm not surprised that "empty" produces unexpected results. This is supposed to work until the cursor is unlocked:

Code: Select all

set the cursor to none
lock cursor 

This did work for the most part but it would never unlock later. Once the cursor was locked to none it stayed that way. I had trouble with the defaultCursor too, which was unreliable.

A locked cursor should stay locked regardless of which cursor is chosen from either the built-in ones or a custom image. I was using a custom image as the defaultCursor which needed to be hidden periodically.

[dunbarx]

Jacque.

Has the same jittery problem. You have to do the two-step thing. I am in 9.6.9.

I found that in order to unlock the cursor when clicking on the card I had to:

Code: Select all

on mouseUp
   set the defaultCursor to plus
   set the  cursor to plus
   set the defaultCursor to arrow
   set the  cursor to arrow
   lock cursor
end mouseUp

change twice. Losing the first two lines did not work at all. Weird. That handler is in the stack I posted earlier.

Craig

[FourthWorld]

defaultCursor and lockCursor solve different problems. You work well be simplified by identifying which one you need, and avoiding the other in the same handler.

[dunbarx]

Richard.

You work well be simplified by identifying which one you need, and avoiding the other in the same handler.

Ain't my work, I just enjoy talking about LC.

But do you not think there are very odd things going on with hiding the cursor? The couple of handlers I have posted all require kludges to make them work, rather more than one would think necessary to simply hide the cursor. And I understand the conundrum LC is in when, say, the cursor enters an editable field.

Craig

[FourthWorld]

But do you not think there are very odd things going on with hiding the cursor?

The method I posted above has worked reliably for me for decades. If it's not working for you I would look elsewhere for the cause, perhaps an engine bug, or a corrupt cursor, or an oddity with a display driver, or something else.

Happy to see if we can come up with diagnostic tests to narrow down the cause, but the sample code should work for you as it's worked for the rest of us for a long time.