LiveCode Forums.

Okay. I've submitted this as a bug report (#7377). When making an image visible and then placing the cursor over the now current visible image, it wigs out. (See steps to produce below.)

Any know workarounds to prevent this from occurring?

1. Create a graphic rectangle.

2. Place inside of rectangle an image (such as an imported PNG; mine had a transparent background if that makes a difference)

3. Name the image "imagezoom".

4. Set a script on the rectangle as follows

on mouseEnter
set visible of image "imagezoom" to true
end mouseEnter

on mouseLeave
set visible of image "imagezoom" to false
end mouseLeave

5. Now test the functionality. Place the cursor outside-inside-outside of rectangle to see the image properly become visible.

6. This time move the cursor into the rectangle but bring it to the location of the now visible "imagezoom" image. Hold it there and you'll notice the imagezoom icon begin to gray out and dance around.

Hi Bill,

you can avoid this if you set the rectangle graphic to the frontmost, at least a layer number higher than the image, make the rectangle opaque and set its blend level in the inspector under ink to 100 %. Then you will get the expected behaviour without the flicker.
Why? lets suppose your image imagezoom is before the graphic rectangle then if you move the cursor over the image, your graphic gets a mouseleave that hides your image, when the image hides, without further doing on the user side the graphic gets a mouseenter and shows the image. Then, since the image appears, your graphic gets a mouseleave and so on. That is what gives you the flicker and in my experience locks up Revolution.
Actually it is no wonder since you send it into an endless loop.

If you put the graphic in front of the image and you hide the image then the graphic does not get the mouseenter when the image hides and you just have the graphic that generates the mouse events.
I set it to opaque because if not opaque the graphic generates a mouseenter at the border and a mouseleave when the border is crossed, since as far a the graphic is concerned you left it right then.
Blendlevel 100%, - well otherwise you couldnt see your image. The border doesnt show either, but for that you could create an other graphic without script just for the border.

So I doubt that this is a bug, it is the expected behaviour just in a combination that can not work.
I you have problems like this it might be worth to open the message watcher to see what is going on.

I uploaded a stack 'flicker of image' to revOnline the username is berndniggemann

I hope I got it all right in the explanation....
cheers
bernd

P.S. If you agree that it is not a bug but a feature of Rev you might want to express this in the QCC

Hi bernd;

Thanks for the detailed feedback. I don't know enough about the platform to understand if this is truly or bug or not. It just didn't work out as expected using a basic approach (with my current basic understanding). I now understand better why it is the way it is. Note: I didn't see any alarming/helpful notices in the Message Box. But, I don't know enough about this puppy yet to know if I'm supposed to send it error messages or if they get auto-generated if something odd occurs. (Yeah, like the software should understand what I consider to be odd? )

The actual intended functionality is to allow someone to click on an image to zoom to a larger version. While entering the image, a faint zoom-in icon/image appears. Looks like to accomplish this I simply need two images (e.g. icon and actual image) and an opaque graphic with 100% blend above everything which handles the mouse control.

Anyway, thanks for the help.

Best,

Bill

bn wrote:Hi Bill,

you can avoid this if you set the rectangle graphic to the frontmost, at least a layer number higher than the image, make the rectangle opaque and set its blend level in the inspector under ink to 100 %. Then you will get the expected behaviour without the flicker.
Why? lets suppose your image imagezoom is before the graphic rectangle then if you move the cursor over the image, your graphic gets a mouseleave that hides your image, when the image hides, without further doing on the user side the graphic gets a mouseenter and shows the image. Then, since the image appears, your graphic gets a mouseleave and so on. That is what gives you the flicker and in my experience locks up Revolution.
Actually it is no wonder since you send it into an endless loop.

If you put the graphic in front of the image and you hide the image then the graphic does not get the mouseenter when the image hides and you just have the graphic that generates the mouse events.
I set it to opaque because if not opaque the graphic generates a mouseenter at the border and a mouseleave when the border is crossed, since as far a the graphic is concerned you left it right then.
Blendlevel 100%, - well otherwise you couldnt see your image. The border doesnt show either, but for that you could create an other graphic without script just for the border.

So I doubt that this is a bug, it is the expected behaviour just in a combination that can not work.
I you have problems like this it might be worth to open the message watcher to see what is going on.

I uploaded a stack 'flicker of image' to revOnline the username is berndniggemann

I hope I got it all right in the explanation....
cheers
bernd

P.S. If you agree that it is not a bug but a feature of Rev you might want to express this in the QCC