On Jul 25, 2009, at 9:42 AM, Benjámin Salánki wrote:
hm, a quick answer to my own question:
inserting
[self performSelector:@selector(updateTrackingAreas) withObject:nil
afterDelay:0.01];
into scrollWheel: seems to fix my problem.
I missed the rest of the thread, so may be out of school here but, as
a general rule, having to call [foo performSelector:afterDelay] with
the intent being to wait[1] until the OS has done something else, then
sending the correct signal[2] just seems like a bad design pattern,
all around. It may be a nice test to help indicate that there's
something else going on, but the REAL solution has to be getting
things to happen in the right order in the first place.
NOTE: if your system happens to block (say, on I/O) for 0.01s (not
unreasonable) at exactly the wrong time (ok, less likely... ;), you'll
get the world's weirdest un-reproducable bug.
We *HATE* those!
---
[1] Say, 1/100th of a second
[2] As opposed to because you like the "look & feel" of inserting a
delay before something happens.
--
Build a man a fire and he will be warm for a day. Set a man on fire
and he will be warm for the rest of his life.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
