Question about the sensitivity of the mouseMove message

[PlaidFlannel]

I have a stack that displays an image graphic, and I want the user to be able to interact with that image using the mouse.

Somewhat simplified, I have a 100 x 100 grid of cells, each 10 pixels square. I want to use a mouseMove handler to display the row and column numbers of the cell the mouse is over, and to have that display change in real time as the mouse moves.

My handler is mostly successful, except it seems to receive messages only after the mouse has moved about ten pixels or more. I don't seem to get a message for a mouse movement of a single pixel.

Is this the expected behavior? Or is there some interplay with some internal parameters like how often the idle message or mouseStillDown message is sent?

[FourthWorld]

Have you logged the mouseDown events to obtain precise timings? It may be useful to know the exact interval between those messages.

[bogs]

Somewhat simplified, I have a 100 x 100 grid of cells, each 10 pixels square. I want to use a mouseMove handler to display the row and column numbers of the cell the mouse is over, and to have that display change in real time as the mouse moves.

What did you compose the grid of, is this like a field table? Or is it a grid of 100x100 different objects? Depending on the answer to that, would depend on which way I would go.

If it is grid of objects, for instance, I'd probably use mouseEnter instead of mouseMove.

Here is a stack giving a fairly decent amount of mouse information. It isn't polished by any means heh, but hopefully it is of some help.

locationtests.livecode.zip

How did I get HERE ?

(1.62 KiB) Downloaded 196 times

[dunbarx]

Hi.

Something is going on elsewhere. There should be no delay, and nothing in the way of having the mouseLoc report each single pixel change.

We need to see your stack.

Craig

[bogs]

There should be no delay, and nothing in the way of having the mouseLoc report each single pixel change.

Why, what is wrong with that?

[PlaidFlannel]

Thanks to all who replied.

One responder asked, "Have you logged the mouseDown events to obtain precise timings? It may be useful to know the exact interval between those messages."

There are no mouseDown events. I'm using only mouseMove events. My interactions with the graphic are solely based on where the mouse cursor is. No clicking.

And, of course, if there are no mouseMove messages being sent for every pixel move, I can't log them with timing information.

Another responder asked, "What did you compose the grid of, is this like a field table? Or is it a grid of 100x100 different objects? Depending on the answer to that, would depend on which way I would go."

The entire grid is painted into a single image object using the painting tools under script control. That image object is the only object where user interaction is possible, and it is the only object whose script has a mouseMove handler.

Another responder said, "Something is going on elsewhere. There should be no delay, and nothing in the way of having the mouseLoc report each single pixel change.

There is no problem with mouseLoc. The problem is that if there is no mouseMove message sent, my handler is never invoked and thus it cannot get the mouseLoc.

[Klaus]

Please show us your MOUSEMOVE handler!

[stam]

One responder asked, "Have you logged the mouseDown events to obtain precise timings? It may be useful to know the exact interval between those messages."

There are no mouseDown events. I'm using only mouseMove events. My interactions with the graphic are solely based on where the mouse cursor is. No clicking.

And, of course, if there are no mouseMove messages being sent for every pixel move, I can't log them with timing information.

How about setting a global var with the milliseconds on mouseEnter and subtract this from the milliseconds in mouseMove

[PlaidFlannel]

The problem has been resolved.

First, in response to Klaus, here is my mouseMove handler:

Code: Select all

on mouseMove pNewH, pNewV
   showFloater pNewH, pNewV
end mouseMove

The showFloater script is in a front script for the stack. It converts the location parameters to row and column, and then displays them in a floating field.

The problem I was having in my actual stack that I was having trouble reproducing in a small demo stack was simple. The image with which the user interacts was actually two stacked images: the grid lines image below and the cell contents above. Most of the cell contents are empty, some are white, and the grid image has white pixels between the grid lines.

The mouseMove message was usually being sent to the grid image, because the cell contents at the mouse location were empty. Occasionally, the cell contents were colored pixels, so the mouseMove message was sent to the cell contents image. Visually, empty cells and white cells are identical, so it was not obvious why some mouseMove messages seemed not to be sent.

The solution was simple. The cell contents image script now simply "forwards" each mouse message to the grid image, using the "send" command.

[dunbarx]

Hi.

Not sure I understand"

The solution was simple. The cell contents image script now simply "forwards" each mouse message to the grid image, using the "send" command.

If there are no "mouseMove" handlers below the card level, say, how were these messages being trapped and buried?

And if there were, lose them. You should only need a single handler in the card script; no "send" need apply.

Craig

[Klaus]

The problem has been resolved.
First, in response to Klaus, here is my mouseMove handler:

Code: Select all

on mouseMove pNewH, pNewV
   showFloater pNewH, pNewV
end mouseMove

The showFloater script is in a front script for the stack...

Well, of course we meant to ALSO show that handler (showFloater).