Follow Cursor

[FourthWorld]

I wonder what the point of

revStackNameIsIDEStack

is, as when I dismiss that notice the script carries on functioning.

Under what circumstances did you encounter it?

[dunbarx]

The main problem as far as I can see is there is no (pseudoCode) on mouseNotMoving . . .

Ah, but there is.

Code: Select all

local mouseTrack

on mouseMove x,y
   put the mouseLoc & return after mouseTrack
   set the loc of btn 1 to line -10 of mouseTrack
end mouseMove

on idle
   if abs(item 1 of the loc of btn 1 - item 1 of the mouseLoc) > 20 or abs(item 2 of the loc of btn 1 - item 2 of the mouseLoc) > 20  then
      move btn 1 to the mouseLoc in 10
   else
      pass idle
   end if
end idle

Not perfect, but getting there. It has been quite a while since I used "idle".

Craig

[richmond62]

Under what circumstances did you encounter it?

If you backtrack in this thread a bit and download Monster2.livecode.zip
you can experience the circumstances for yourself.

[dunbarx]

In a new session, Richmond has a point. The travel of the cursor has to have been recorded for just a bit before it is allowed to track that cursor. Also, the cursor should not drag the chasing object off screen. So a slight improvement to this gadget. A rectangular graphic (grc 1) is set just within the borders of the card window:

Code: Select all

local mouseTrack

on mouseMove x,y
   put the mouseLoc & return after mouseTrack
   if the mouseLoc is within the rect of grc 1 and the number of lines of mouseTrack > 10 then 
      set the loc of btn 1 to line -10 of mouseTrack
   end if
end mouseMove

on idle
   if (abs(item 1 of the loc of btn 1 - item 1 of the mouseLoc) > 10 or abs(item 2 of the loc of btn 1 - item 2 of the mouseLoc) > 10)  and the mouseLoc is within the rect of grc 1 then
      move btn 1 to the mouseLoc in 10
   end if
end idle

Now how to get rid of the annoying stutter when the cursor is moved quickly around the card and abruptly stopped.

Craig

CursorFollower.livecode.zip

(1.17 KiB) Downloaded 194 times

[richmond62]

You probably get rid of the annoying stutter by using move rather than set.

[dunbarx]

Richmond.

I do use "move" in the idle handler, but it does not work well at all in the mouseMove handler.

Since I do not want to actually do any work at my office, I have made a slightly better version, not needing an idle handler at all.

Craig

CursorFollower2.livecode.zip

(1.17 KiB) Downloaded 250 times

[FourthWorld]

Under what circumstances did you encounter it?

If you backtrack in this thread a bit and download Monster2.livecode.zip
you can experience the circumstances for yourself.

Is the word "recursion" in the dialog you see?

[richmond62]

Screenshot 2020-03-03 at 22.57.28.png (16.14 KiB) Viewed 6216 times

[FourthWorld]

Screenshot 2020-03-03 at 22.57.28.png

Recursion errors are inherently problematic for many reasons, not the least of which is that they consume so much memory replicating the execution stack that there's often not enough left to report the error with thorough accuracy to the developer.

I saw the same dialog today in another project, and the mention of "recursion" allowed me to pin down the recent change I'd made to fix it.

The reference to that internal IDE function is probably legit, since the breaking point may have been reached when the routine was triggering IDE actions. But it's no more useful than random gobbledgook, since if it occurs while we're not working in the IDE we may easily become confused as to why it's mentioned functions we haven't called.

Sadly, there's probably little the engine team could do about that, short of rebuilding the foundations of the engine to support the sort of internal multithreading that would keep IDE execution separate from our project's execution. And even then, I'm not sure everything LC does could be made thread-safe, so such a Herculean effort may land us in a position no better off than we are now, but a bit worse off for the opportunity cost.

In short: any error reported about recursion will likely include other details that may not be helpful in diagnosing it, unavoidable given how recursion works. But once you regain control, review you code for source of recursion, and experiment until you find the one that stops that message from showing.

[dunbarx]

What Richard said.

I have a stack that attempts to read data from an external device all day. Recursion occurs because there is a running loop that waits for a change in that device. The recursion limit used to come up about every thirty minutes. I fixed it by adding just a few ticks each time through, and that slowed down the whole thing enough so that the typical intermittent activity would never find the handler hung up with the dialog. Acting on the change "reset" everything, and a new round of waiting could then commence. The delay was not noticeable.

I am not sure that slowing down a loop is good technique, but it works for me in this instance.

Craig

[SparkOut]

The dictionary entry for idle does warn of it not being a good fit for most things where a "send" is likely to work better.
Here's another revision that doesn't use idle. The button will lag behind the cursor at a varying distance according to the speed at which the cursor is being hurtled around - this is subject to experimentation as to how many lines of the cursor history to track, and how often to update the position of the button being "lag-dragged". At rest, the button will "catch up" with the cursor again, until it starts moving once more.