What is up with "mouseEnter"??

[dunbarx]

This was from a thread about rolling ones own to control tooltip "latency". I thought it worthwhile to do it here again.
https://forums.livecode.com/viewtopic.php?f=9&t=37177

The attached stack shows two fields. Each has a "mouseEnter" handler that shows a "new toolTip" field for a certain time, then dismisses it.

The top field simulates a "new toolTip" field that can linger for any preset time period. Its loc is explicitly set at the botRight of the target field.

The bottom field sets the loc of the new tooltip field near the mouseLoc, as is custom. I cannot understand the action there at all. The "toolTip" field tracks the mouseloc, even though, I would have thought, no new "mouseEnter" messages are sent. In fact, though, many are sent, as the message watcher attests, though by moving the cursor around incrementally in certain ways that repetitive messaging can be made to cease.

What is going on??

Craig

newToolTip.livecode.zip

(1.12 KiB) Downloaded 64 times

[stam]

Hi Craig,
In the other thread you posted this question on, I provided a solution as to how I would solve this. I understand that’s not what you’re looking for exactly.

However I encountered a likely similar issue: mouseLeave, which is meant to be one of the ways to dismiss a custom tooltip, kept firing continuously even though the mouse was still within the bounds of the target.

Within mouseLeave I had to first check the mouseLoc was out of bounds before acting on it. I wonder if this might be a bug?
If you’ve not seen my solutions, its main code and a stack are posted on the original thread you reported this on…

In the meantime maybe bounds checking would help your solution?

S.

[dunbarx]

Stam.

The issue I have with mouseEnter sounds much like yours with mouseLeave. Hmmm. These are pretty closely "related", I think.

If you play with my stack, you will likely find that the action I describe is not stable. It does some things regularly, however "incorrectly, but others randomly.

Like you, my point was that where are these messages coming from??? I guess I will send my stack to Scotland, and see if they say either what I do not understand or what is happening. I will reference your

Craig

[richmond62]

That is really odd: in the lower field, when I move the mouse, but still inwith the field, the tooltip pops up anew
at the mouseLoc.

Why do I get a funny feeling that LC (9.6.3) is interpreting a mouseMove as a mouseEnter?

Also, I notice that (with the lower field) as soon as the mouseEnters the field the tooltip pops up, and then, in a far shorter
interval than a second, it pops up again at the mouseLoc.

Oh, b*gger: changed the code:

Code: Select all

on mouseEnter
   wait 15 ticks
   show fld "newToolTip" at the mouseLoc
   wait 1 second
   hide fld "newToolTip"
end mouseEnter

and am getting the tooltip flashing on and off all the time.

You are NOT going to like this:

Code: Select all

on mouseEnter
   if fld "fTRAP" is empty then
      show fld "newToolTip" at the mouseLoc
      put "x" into fld "fTRAP"
   wait 1 second
   hide fld "newToolTip"
   end if
end mouseEnter

on mouseLeave
   put empty into fld "fTRAP"
end mouseLeave

A very old and 'dirty' trick.

[bn]

Hi Craig,

I could not figure out what is going on either.

However

Code: Select all

on mouseEnter
   show fld "newToolTip" at the mouseLoc
   lock messages
   wait 1 second
   hide fld "newToolTip"
end mouseEnter

works for the lower field.

It is strange that the infinite repeat goes on as long as the "toolTip" field is not completely within the lower field or completely outside of the lower field.
As long as the "toolTip" field overlaps a side of the lower field the "infinite repeat" goes on although the mouseLoc is well outside of the lower field.

Kind regards
Bernd

[richmond62]

Even if nothing else, this shows that mouseEnter does NOT work properly.

[jacque]

When the mouse enters the field he tooltip is shown correctly under the mouse. At that point the tooltip field blocks the mouse so LC sends a mouseleave. When the tooltip disappears, the mouse again enters field so you get mouseEnter again and the cycle repeats.

If you put mouseEnter and mouseleave handlers in the tooltip field you should see those trigger too as the mouse leaves the original field and enters the tooltip.

It should work if the tooltip is displayed offset from the mouseloc so that the mouse position in the field is never blocked.

[richmond62]

That, Jacque, was brilliant!

[dunbarx]

Jacque.

Great catch.

This reminds me of a thread of long ago where it was desired to have a "messageTransparent" property so that a control does not block any underLying control for the purpose of sending messages "through" that control. In that way the mouse would not think it had been "isolated" from the underlying field.

Craig

[jacque]

Maybe we need a defaultControl.

[dunbarx]

So if there is any doubt about Jacque's interpretation. this demo should put it to rest.

It does not make much sense, at least to me, in that the mouse doesn't "leave" the perimeter of the button, an action I always ascribed to a physical movement of the cursor, not just the fact that the cursor was either:

1- No longer "within" the rect of the button, by virtue of there being another control inserted between them. (The left hand case). This is demonstrated by simply clicking in "B1" in the path of btn "B2" and waiting. If one then clicks on a spot inside "B1", but outside the path btn "B2", the small moving button will not stop at the clickLoc and no mouseLeave handler will fire, because the cursor was never isolated from the underlying button.

2- The right-hand case. I just never thought of clicking, under script control, at a point inside a something like a button, and then clicking at a point outside, as invoking messages like "mouseEnter" and "mouseLeave"

I suppose the two cases are indeed similar, assuming I discard that notion about an actually moving cursor, as if it was a physical object, and not just a figment of some program's imagination.

Craig

JacqueWasRight.livecode.zip

(1.12 KiB) Downloaded 63 times

[bn]

Hi Craig,

One thing I do not understand is the case that in your sample stack above "newToolTip" for the lower field:

Move the cursor from left slowly over the lower field until the tooltip appears.The toolTip is flashing. Now move the cursor slowly back to right. The tooltip keeps flashing although the cursor has left the lower field. Go on 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.

Similarily again move the cursor slowly from left over the lower field until the tooltip appears and is flashing. Now keep on moving the cursor to the right slowly and the tooltip keeps flashing until the left side of the tooltip is to the right of the left border of the lower field.

Is that behavior covered by Jacque's explanation? If so how?

Kind regards
Bernd

[richmond62]

Now keep on moving the cursor to the right slowly and the tooltip keeps flashing until the left side of the tooltip is to the right of the left border of the lower field.

I think it is, because the topLeft of the tooltip field is set to the mouseLoc, so when the topLeft of the tooltip is still indied the field
the mouseEnter signal still fires.

[bn]

Now keep on moving the cursor to the right slowly and the tooltip keeps flashing until the left side of the tooltip is to the right of the left border of the lower field.

I think it is, because the topLeft of the tooltip field is set to the mouseLoc, so when the topLeft of the tooltip is still indied the field
the mouseEnter signal still fires.

Hi Richmond,

Did you follow the recipe I gave for the LOWER field of stack "newToolTip"?

In the lower field the code says:

Code: Select all

on mouseEnter
   show fld "newToolTip" at the mouseLoc
   wait 1 second
   hide fld "newToolTip"
end mouseEnter

Note: at the mouseLoc

Kind regards
Bernd

[richmond62]

No, I'm afraid I didn't, I wrote that last message straight after attending a funeral: so, stupidly, did not read your message.