Re: Rollover Effect
Re: Rollover Effect
- Subject: Re: Rollover Effect
- From: Gen Kiyooka <email@hidden>
- Date: Mon, 29 Aug 2005 15:27:53 -0700
On Aug 29, 2005, at 3:00 AM, Philip Dow wrote:
I am trying to produce a rollover effect, similar to a hover in a
web link but with images. I use a custom NSView that I've added
target-action behavior to. From within drawInRect: I check the
state of the button and draw the image accordingly. To set the
state of the button, I use a tracking rectangle, standard
mouseEntered: mouseExited type stuff.
This works, except that the tracking rectangles are flaky as hell.
The mouseEntered: seems to register every time, but the
mouseExited: misses a beat if I move the cursor too quickly over
the view. The effect is a button that hangs. It continues to
indicate the hover/rollover state after the mouse has passed
through it.
This is not a terrible bug, but it's not pretty either. Is there a
better way to implement a rollover effect?
-Phil
http://phildow.net
One of the downsides to an OS-wide input event stream is that the
modal-type mouse
tracking from OS9, which had a really crisp feel is anathema to multi-
tasking / multi-threading.
My suggestion is to use an NSTimer to check the state of the mouse
and reset your finite
state machine if the mouse state is not consistent with the stored
state.
On 27.08.2005, at 11:46, Mason Mark wrote:
On Aug 27, 2005, at 6:16 PM, Finlay Dobbie wrote:
On 27/08/05, James Bucanek <email@hidden> wrote:
This is news to me. I've never had any problem with LS until I
ran your test code. Admittedly, I haven't really tested any of
my code since Tiger, so maybe it's a 10.4 issue. Have you filed
a bug report?
I wouldn't be surprised if the problem was that it's resolving the
symlinks at /tmp, /var, /etc and so on to their corresponding
directories in /private, and then examining the target's HFS
attributes...
The only errors you're getting are because you can't get FSRefs to
/.vol and /dev. If you use URLs rather than FSRefs then LS will
correctly report them as invisible.
-- Finlay
Huh, that's an interesting theory! But, not all those files are
symlinks.
By "errors", in this case I meant "Launch Services reporting a
different visibility than what shows up in the Finder", not the
errors getting the FSRef. (Bad choice of words, I suppose.)
Anyway, I am leaving the office right this minute so if somebody
else wants to test Finlay's theory, that'd be cool. ;-) Or I will
do it tomorrow. Now that I think about it, though, I bet that's
surely true because IIRC FSPathMakeRef() always resolves symlinks.
But, that still doesn't explain why "mach.sym" is reported as
visible but hidden in the Finder.
But if that's the only file that's problematic, then the 10.4
situation is a lot better than I thought... maybe that's the only
special case left then.
Cheers,
--
Mason Mark
Five Speed Software, Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden