I have an app in which nearly all of the buttons use some wonderful
graphics made by a contract artist, with up, down, disabled, and
rollover states.
I've set the IDs of the various icon properties appropriately, and
everything's ALMOST working great, except:
Rollover states seem to stick
Hi Richard,
I think it's a bug, and it seems to be worse if your buttons are in
groups. Is that the case by chance? I remember running into the
issue a while back, and I think it's in Bugzilla, but to be honest
I'm not entirely sure. We finally just gave up on having a rollover
on our
Chris Sheffield wrote:
Hi Richard,
I think it's a bug, and it seems to be worse if your buttons are in
groups. Is that the case by chance? I remember running into the issue
a while back, and I think it's in Bugzilla, but to be honest I'm not
entirely sure. We finally just gave up on
Richard,
How about mouseEnter and mouseLeave; assigning the button icon by ID
reference? Obviously not as easy... but if it works...
Paul Looney
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe,
Hi Richard,
Richard,
How about mouseEnter and mouseLeave; assigning the button icon by ID
reference? Obviously not as easy... but if it works...
exactly!
I always use this (mouseenter etc...) even in groups and never had
problems.
Paul Looney
Regards
Klaus Major
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Richard,
How about mouseEnter and mouseLeave; assigning the button icon by ID
reference? Obviously not as easy... but if it works...
Thanks. Tried that. Unfortunately if you move the mouse fast enough
some objects may not get the mouseLeave. :(
--
Richard Gaskin
I'm using MouseEnter MouseLeave and assigning a graphic to a graphic (and
not using a button at all). This lets me have irregular-shaped buttons,
and only have the button proper be active.
I put the MouseEnter mouseLeave code in a group and then group all the
graphical buttons. Seems
Richard,
Bummer!
How about something really crazy: if mouseEnter works use that to set the
rollover state and (the crazy part) mouseWithin to maintain the rollover state
(on idle it reverts to the non- rollover).
Paul Looney
___
use-revolution mailing
[EMAIL PROTECTED] wrote:
Richard,
Bummer!
How about something really crazy: if mouseEnter works use that to set the
rollover state and (the crazy part) mouseWithin to maintain the rollover state
(on idle it reverts to the non- rollover).
I think such a brute-force method may be needed:
Richard,
You can check out my little tutorial on custom buttons:
go URL http://www.altuit.com/webs/altuit2/RunRev/CustomButtonObjects.rev;
There are known issues with buttons close to the edge of a window which
don't 'refresh' properly. Perhaps that's your problem?
-Chipp
Richard Gaskin
Recently, Richard Gaskin wrote:
What are the property settings I should be using for reliable rollovers?
Perhaps you forgot to set the acceptIncantations of your stack to true.
I don't have a great workaround to offer, other than to look at the space
nearest your buttons and see if that can
Sent: Wednesday, August 24, 2005 5:32 PM
To: How to use Revolution
Subject: Re: magic settings for rollovers?
Richard,
If you want a fail-safe, perhaps you can have an idle task that just
goes around and fixes any bad button images if the mouse is not
within them.
Dennis
On Aug 24, 2005
sez [EMAIL PROTECTED]:
Chris Sheffield wrote:
I think it's a bug, and it seems to be worse if your buttons are in
groups. Is that the case by chance? I remember running into the issue
a while back, and I think it's in Bugzilla, but to be honest I'm not
entirely sure. We finally just gave
Richard,
If you want a fail-safe, perhaps you can have an idle task that just
goes around and fixes any bad button images if the mouse is not
within them.
Dennis
On Aug 24, 2005, at 4:41 PM, Richard Gaskin wrote:
[EMAIL PROTECTED] wrote:
Richard,
How about mouseEnter and mouseLeave;
Dennis Brown wrote:
Richard,
If you want a fail-safe, perhaps you can have an idle task that just
goes around and fixes any bad button images if the mouse is not within
them.
Argh. I already have timers floating around to handle other messaging
workarounds, kinda hate to add more
Chipp Walters wrote:
There are known issues with buttons close to the edge of a window which
don't 'refresh' properly. Perhaps that's your problem?
Could be related. These buttons aren't near the edge of window, but are
near the edge of a shared group.
Ah, if only the system message issues
perhaps a mousemove handler in your shared grp might help you?
It certainly would help you track down the problem.
best,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage
Chipp Walters wrote:
perhaps a mousemove handler in your shared grp might help you?
It certainly would help you track down the problem.
You mean correct for it?
Identifying the problem was the easy part: rollovers aren't currently
reliable for buttons near the edge of windows and groups.
Digging deeper, I think I found the root of the problem:
Rev doesn't provide native support for rollovers.
The trick of using the armedIcon is seductive but ultimately
disappointing, as it relied on the traversalOn and autoArm and those
were really designed for other behaviors related to
An enhancement request for rolloverIcon property for buttons has been
submitted to BZ:
http://support.runrev.com/bugdatabase/show_bug.cgi?id=2208
Thanks again for everyone in helping to clarify my thinking on all this.
--
Richard Gaskin
Fourth World Media Corporation
20 matches
Mail list logo
