LiveCode Forums.

I have nine images on a card. Each is basically a response key. I wrote some code to change the color overlay to red on mouseEnter and to white on mouseLeave for each image individually. This color overlay with a blendMode of multiply is basically how I'm achieving a red hover effect for the images. Now I have added a second mode where the nine images are split into three "clusters" (I am avoiding the use of the term "group" here) of three. I basically want this mode to be a portion of a quiz that is easier for the user because it asks them for a less-specific answer. So when the mode is changed, the three images of each cluster move together so that only space between the large clusters remains. In this mode, my script turns on the red hover for all three keys in a cluster when the mouse enters any one of the keys of that cluster (and changes the overlay to white when the mouse leaves any of the cluster's images). I also wrote code that alters the functions of each of a cluster's constituent keys to be the same when those keys squash together at the mode switch. This way, there are now effectively three larger and more inclusive response keys.

My problem is that when I hover over cluster 2 (which is a block that includes key 4, key 5, and key 6), for instance, and I move my mouse over the border between key 4 and key 5 or key 5 and key 6 (thus staying within the boundaries of the larger cluster), I often get a brief flicker. I know this is because of the mouseLeave message being sent when I exit the area over one key and the mouseEnter message sent immediately after due to the mouse entering the area over the next adjacent image. How can I bypass the mouseLeave message only when I move into an adjacent image key without using location-based commands? I might like to rearrange the keys later, so I don't want to define specific areas in pixels for this task.

I essentially want to group the images and apply mouseEnter/mouseExit functions to the groups directly, but I know this isn't possible because of the way group script is passed to the objects directly.

hi - I probably just need more coffee to be able to understand what you mean - but could you include some screenshots to explain a bit more?

In the clustered mode, i get a flicker at the point of the green rectangle (the image border) when i move my mouse from point A to point B

Hi - I've just experimented and the only way I can get the cursor to change is if there is something setting the cursor shape while in the image

The way I got around this was to include a mouse move handler in the containing control (card or if possible a group) that found the rect of the control and 'added some padding' to it - this way you can have a gap between your images without seeing a 'flicker' (at least I couldn't see a flicker when I tested)
What I've done is a 'quick-and-dirty' way without elegance which just gets the job done - I'm sure others will add refinements

Also - there are a lot of things you could do so that you don't put yourself into this position...

Kind regards

Dave

If two objects are adjacent and I move the cursor from one into the other, which message is sent first: mouseLeave (first object) or mouseEnter (second object)?

Hi Mr. Bassman,

theotherbassist wrote:If two objects are adjacent and I move the cursor from one into the other,
which message is sent first: mouseLeave (first object) or mouseEnter (second object)?

is this s trick question?
I would say, "mouseleve" comes first.


Best

Klaus, another bass player, see my basspage
http://www.major-k.de/bass/index.html

Yes, it seems that would be the case intuitively. But if there is no space between the two objects, the mouseLeave message and the mouseEnter message would be sent at the exact same time. The movement upon which the mouseLeave and mouseEnter are contingent is one and the same. No?

I seem to have solved this by simply delaying the "check if the mouse is outside the group rect" function by 3 ticks inside the mouseLeave.

[Script in one of the nine objects]

Although the processing does slow everything down significantly... because it affects usability in the individual button mode. Of course, I can add in an to stop the delay when it isn't needed, but this extra processing creates a delay of similar proportion anyway.

Klaus:

another bass player, see my basspage
http://www.major-k.de/bass/index.html

Very cool. Music is just the expression of a deconstructed and reconstructed sonic syntax. Get good enough, and we call it a "groove." One day I'll be able to groove with livecode syntax as well. Feel free to check out my music for now though.
http://thevanvons.bandcamp.com

Not sure if it will help, but you might "lock screen" and "unlock screen" around the code that sets and unsets your hilite.
As far as which is first, yeah. Leave fires first. (you can check this with the message watcher under the development menu)

Three ticks is a long time on a computer. I think you could shave it down to a few milliseconds. If you haven't already tried it, start with 1 or 2 milliseconds and adjust from there.