What is up with "lock Cursor"?

[dunbarx]

Aha.

In the previous setup, if I do not lock the cursor, it barely ever changes as I move around within the button. It has fleeting instances where it does, but they are really fleeting.

So locking the cursor does indeed have an effect, but you have to work hard to find it. And it proves even more strongly that it is the loc that matters, not the command.

Craig

[jacque]

"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.

Idle is sent all the time, but you won't notice it unless you trap it, like any other message. But it's a remnant of HC and is usually not a good way to handle repeated activities. Idle occurs in the pauses between handlers and is when the engine does its housekeeping. "Wait with messages" also allows an idle for example.

Anyway, the behavior you're seeing is the bug. Since Richmond can keep a custom cursor after locking it, and since he's using older copies of LC, it looks like the problem was introduced somewhere around the time version 9.x was released.

[richmond62]

I have this working with LC 9.6.3

[dunbarx]

@Jacque. The dictionary states:

Note: If there is no idle handler anywhere in the message path, no idle message is sent.

@Richmond. Can you send a stack that shows it? None of your others do, irrespective of the LC version.

Craig

[paul@researchware.com]

If this hasn't already been mentioned, there is a open bug report about Lock Cursor from June 2019. See https://quality.livecode.com/show_bug.cgi?id=22211

There was a cumminity developed fix done in May 2020 (AWAITING_MERGE) that - becuase of the end of the open source version or other reasons - has never been incorporated into Livecode.

Even if they can legally pull the GIT code, you would think they could recreate the fix and knock this bug off the list.

[dunbarx]

Paul.

This surely is still a bug in the latest versions of LC. I would have thought it would get priority, since it is old, present at such a basic level, and I bet, unlike myself, many users change cursors often.

Craig

[jacque]

@Jacque. The dictionary states:

Note: If there is no idle handler anywhere in the message path, no idle message is sent.

Ah. I stand corrected. The engine still uses it though.

[dunbarx]

The engine still uses it though.

Odd, I think. Deesn't the engine already know what time it is and what is or is not happening in its environment? Why is it talking to itself? Not a good sign.

Craig

[jacque]

Well, it doesn't actually send the message to itself, but it does use the time when the app is idle to do housekeeping. And we typically call that an idle period. So there.

[dunbarx]

Jacque.

I am idle most of the day. And I do talk to myself. And I never send messages to myself, because I will never read them.

But you, who were the one decades ago who taught me never to use idle messages unless nothing else would do (this was in HC, way before we had "send in time") cannot all of a sudden tell me you were talking about the way a computer works, as opposed to how my brain works, when speaking not of the idle message, but of the idle time.

There. So?

Craig

[jacque]

My dear Craig.

I concede -- but only because I can't best your clever rhetoric. May all your idle times be rejuvenating. Meanwhile I stand firm on the concepts.

[dunbarx]

Jacque