firing mouseEnter msg of an Image control which was painted
dunbarx at aol.com
dunbarx at aol.com
Mon Feb 2 19:01:24 CET 2015
Well, at least we know that an image can be either empty or merely erased. In other words, if the image data is simply a bitmap, (is it?) there is a difference between no pixels and pixels that have been erased. I can see that there might be a distinction, and that is fine as long as we know about it. The text of an erased image is not empty. I contains a couple of lines of encoded data. The text of even a simple image is a lot of stuff.
But that does not excuse the message behavior. Will you file a bug report, or wait until others chime in?
From: Bernard Devlin <bdrunrev at gmail.com>
To: How to use LiveCode <use-livecode at lists.runrev.com>
Sent: Mon, Feb 2, 2015 12:43 pm
Subject: Re: firing mouseEnter msg of an Image control which was painted
Craig, it is even stranger than that :)
If you use the eraser to remove all paint, then as you say, such messages
(e.g. mouseWithin) are not fired.
If you set the imageData to empty, such messages (e.g. mouseWithin) are not
If you set the text of the image control to empty, such messages (e.g.
mouseWithin) do fire.
On Mon, Feb 2, 2015 at 5:11 PM, <dunbarx at aol.com> wrote:
> This is too much. It is a bug. Though an interesting feature might be the
> addition of new messages, something like "paintEnter" or "paintWithin". But
> these should always be either nonexistent, or separate from the enclosing
> Anyway, I posted earlier that even if you erase all the paint that you
> once placed inside, the message lockout persists in the image. This to me
> is a source of wonder and irritation. It should not be permitted that an
> "overlay" of paint changes the properties of the object over which it lies.
> No other object sandwich works that way, or ought to.
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
More information about the use-livecode