What is up with "mouseEnter"??

[dunbarx]

Bernd.

The handler in the field shows the toolTip, waits, and then hides it. Each of those events invokes both a mouseEnter and a mouseLeave message. This never occurred to me before Jacque's explanation. Remember that mouseEnter is sent not only when the cursor "enters" the field, but also if it just happens to appear there. That is what my earlier second stack shows using the "click at" command.

Know if you reduce the wait time to, say, 1 tick, then after about five seconds LC stops with a recursion safety halt.

The issue is that I always thought that the cursor had to "leave" the underlying field "by hand". That is, leave, like a person does to a room, so the show and hide commands made sense. But if the cursor only has to either "be" in the field or "not be" in the field, however that is done, that whole methodology is invalid.

So much fun...

Craig

[bn]

Craig,
Move the cursor from left to right slowly over the lower field until the tooltip appears.The toolTip is flashing. Now move the cursor slowly back to left. The tooltip keeps flashing although the cursor is not over the lower field anymore. Go on moving the cursor towards the left and notice that the flashing of the tooltip stops when the right side of the tooltip has moved beyond the left side of the lower field.

Could you try that?

The cursor is not within the rect of the lower field when you move slowly to the left, only the toolTip field. The only mouseEnter handler is in the lower field. The mouseLoc works since the tooltip field shows up where it should when you move slowly to the left again.
That is what I don't understand. Everything else is ok.

Kind regards
Bernd

[dunbarx]

Bernd.

The field "remembers" where the entry point was. The toolTip has a certain rect, and as you move the cursor off that point, as long as the rect is over that point, the "hide/show" process proceeds. Hence the "flashing". Try this: You can move directly upwards as well, and you will see that as soon as the toolTip no longer covers the original entry point, it disappears, even though the cursor is still within the rect of the field.

This is the same effect using "mouseEnter" instead of"mouseLeave. They both act this way.

Check out the stack I sent "JacqueWasRight". On the left hand field:

1- Click near the center of the left field, so that the clickLoc is directly below btn "B2.
2- Move the cursor anywhere off that field.
2- The button "B2" will move downward until it reaches the clickLoc.

The underlying control "remembers" where the clickLoc was, and the "mouseLeave" message is only sent when the btn "B2" covers that point. The cursor has already left the field, but it seems LC remembers that point just in case anyone in the audience wants to talk about it.

This is all reproducible, and possibly useful. Again, it all goes back to the fact that one does not have to drag the cursor in and out of a control in order to send either of those two messages. Until now, I always thought you did.

Craig

[dunbarx]

Bernd.

To cement this firmly in my mind, I went to the bottom field in the stack "newToolTip" and slowly entered that field from any side. Since that handler sets the loc of the toolTip to the mouseLoc, if you move slowly and not too far from the original entry point, you can drag the toolTip around all day.

But if you move in any direction so that the toolTip itself runs off the original entry point, it disappears and the madness stops.

Craig

[dunbarx]

This is a cute variation. Same-old scripts in the button and field. Click on the button. The toolTip appears.

Why? Because when the button "clicks" on the field, a "mouseEnter" message is sent from that field, and the toolTip appears at the mouseLoc, which is over the button.

Craig

ToolTip Madness.livecode.zip

(1.07 KiB) Downloaded 49 times

[bn]

Craig,

The field "remembers" where the entry point was

That seems to be the missing link in my understanding.

Thank you for the explanation and the demo stacks.

Kind regards
Bernd

[dunbarx]

Bernd.

If you think about it, since the machine does not have eyes like we do, but only a table of values in which to work with, what we understand as a cursor "crossing" an edge is seen by the machine as two sets of numbers coinciding. It should not be a surprise that these are stored along with a note that they are important.

Anyway, it is how LC works; I just never encountered it before.

Craig