What is up with "lock Cursor"?

[SparkOut]

The lock cursor documentation definitely says (used to say? - I am not able to check) something about the locked cursor state ending after the handler that invoked it finishes, similarly to the ephemeral state of the itemDelimiter.

[richmond62]

Well, if that is so why is my 'paw' persisting when I remove my mouseLoc from the image?

[dunbarx]

Jacque thinks this was a bug that was resolved. It does not seem to be.

I cannot imagine how Richmond made his work. He uses an image, whereas I only changed the cursor to one of the available standard offerings. That should not matter.

But then what is the point of the "defaultCursor"? The issue is fully resolved with that property, since it sticks until the user changes it, just like the dictionary says locking does. So maybe these days locking the cursor is only intended for handlers, like the itemDelimiter as Sparkout mentioned?

Craig

[dunbarx]

Richmond, are you in LC 9.6.9?

Craig

[richmond62]

No, just standard PNG, black and white, and a third color marked as transparent.

WRONG!
-

redHand.png (2.15 KiB) Viewed 303 times

-
Normally I use LC 9.6.3, but today I am using LC 8.1.10

[dunbarx]

Richmond is using an old version of LC to demonstrate that the "lock Cursor" command once worked as advertised. The "defaultCursor" property has been around since LC v.2.

None of this is helpful, but we do have "defaultCursor".

Craig

[richmond62]

I was using an old version of LiveCode to have a coloured cursor!

The Dictionary states that a cursor has to be black and white.

[dunbarx]

I take much back.

Richmond, your latest stack changes and locks the cursor upon mouseEnter into a field. But the cursor reverts once one leaves the rect of the field. What were you trying to show here?

And I just played with the two "Curses" stacks, and neither exhibits any permanence to a cursor. So where did you see that? Did you in fact see it?

Craig

[jacque]

Jacque thinks this was a bug that was resolved. It does not seem to be.

I may be wrong about the fixed version of LC. The team built a custom version for me with the cursor fix because I relied on a constant custom cursor for a client project and defaultCursor wasn't working consistently. I assumed the fix would be added to the public release. Maybe it's in the current DP, I haven't checked yet.

[dunbarx]

This stack shows that one may change and lock a cursor under script control. When that handler ends, the new cursor sticks, as shown by the action of a mouseMove handler that loads a field with numbers. But ONLY while the cursor is within the rect of the object within which it was changed. Once it leaves that rect, it reverts.

Locking only holds in that narrow context. That is undocumented and annoying. This is different than anything so far discussed. I am not sure what to consider a bug, but something sure is.

Craig

Cursor Madness.livecode.zip

(991 Bytes) Downloaded 4 times

[jacque]

The cursor should remain locked across handlers until one of them unlocks it or an idle occurs. At least that's my current understanding. The fact that it doesn't is a bug.

[dunbarx]

Jacque.

The cursor should remain locked across handlers until one of them unlocks it or an idle occurs

"Idle" is not sent unless there is an actual idle handler somewhere. Thank heavens. Didn't HC sent them always?

Anyway, it seems that the cursor only stays locked based on its remaining within the object from whence it was changed. If in the card script, it will happily roam around all over, until, that is, it enters any other control.

Craig

[richmond62]

Richmond, your latest stack changes and locks the cursor upon mouseEnter into a field. But the cursor reverts once one leaves the rect of the field. What were you trying to show here?

Well:

1. On my MacOS 10.7 Lion machine with LC 8.1.10 the red hand remained 'there' even when the mouseLoc was outwith the field in which the cursor-changer script was.

2. On my MacOS 12.7 Monterey machine with LC 9.6.3 the red hand remains 'there' even when the mouseLoc was outwith the field in which the cursor-changer script is.

3. It is too late in the evening, and I am shagged out from teaching tinies ESL from 9 pm to 7 pm to cross to the other side of my study to test the stack on my MacOS 14.5 beta Sonoma machine: but I have NO doubts it will behave in the same way.

Why does this make me think that something has gone wonky post LC 9.6.3 ?

---------------------------------------------

Richmond is using an old version of LC to demonstrate that the "lock Cursor" command once worked as advertised.

Wow: I love it when other people tell me what my intentions are! And my intentions were NOTHING OF THE SORT:

1. I used LC 8.1.10 because at the time I made that stack I only had access to a machine running MacOS 10.7 Lion . . .

2. I have just run that stack at home on MacOS 12.7 Monterey and LC 9.6.3.

3. What I demonstrated is that the Dictionary is wrong insofar as it says you cannot have coloured cursors.

[dunbarx]

Jacque.

I made a new card with a new button and a field, with the following in the card script:

Code: Select all

on mouseMove
   put random(999) into fld 1
   if the mouseLoc is within the rect of btn 1 then
      set the cursor to watch
      lock cursor
   end if
end mouseMove

Moving the cursor loads numbers into the field. When I enter the button the cursor changes to watch and the numbers keep coming. When I leave the button, the cursor reverts to arrow and the numbers just keep coming. The "lock cursor" command is useless, perhaps deprecated in favor of "defaultCursor".

Is there any scenario where setting it changes anything at all?

Craig

[richmond62]

-
Watch the movie.

https://www.dropbox.com/scl/fi/o1jkkdyv ... vxo6p&dl=0