Uli, Thanks for the education. The way you suggest is what I did pre-OS X and Xcode/Cocoa and I didn't have this problem Being self taught (by books, sample code and documentation) in programming in Xcode/Cocoa for OS X and IOS it sounds like I started off on the wrong foot with the versatility of timers.
I'll have to re-architect the app. Thanks again. On Jul 6, 2012, at 7:24 AM, Uli Kusterer wrote: > On 05.07.2012, at 21:57, Charlie Dickman wrote: >> I have a demonstration app that is basically operating on a 0.15 second >> timer loop. The problem I am having is that even with a periodic timer going >> off it is very difficult to get menu events and mouse clicks in window >> controls through to be processed. I have tried setting up an additional flow >> of events using >> (NSEvent) + >> (void)startPeriodicEventsAfterDelay:(NSTimeInterval)delaySecondswithPeriod:(NSTimeInterval)periodSeconds >> >> as well as >> >> [[NSRunLoop currentRunLoop] runUntilDate: [NSDate >> dateWithTimeIntervalSinceNow: t != 0. ? t * 1.01 : .01]] >> >> (where t can be set arbitrarily but is typically called with a value of >> 0.15) but none of this improves response. Is there anything else to try? > > It's not how long you give time to the event loop, it is how often. Also, > startPeriodicEventsAfterDelay: is intended for mouse tracking, not for > general-purpose timers. You're being very vague and fuzzy with your > terminology, so I hope you don't mind if I just spell out how I'd do a > periodic task, and then you can tell whether that's what you're doing and > when you're doing it differently: > > -> Use an NSTimer to get your periodic processing time, not other calls. > -> Let the rest of the app run normally > -> Do the minimum amount of work needed in your timer. Timers run on > your main thread & run loop, so you have to do short bits of work so the OS > can "come up for breath" often enough. E.g. do your pre-loop setup, then put > the loop body in the timer (using instance variables for the counter & other > stuff you need to keep around between iterations), and then do 1 iteration > per timer fire. > -> Don't use blocking calls (like network access) on the main run loop, > use calls that do their work on another thread and then call you back when > they're done (e.g. NSURLConnection, not NSURL -initWithContentsOfURL:). > > Or, if you can run your stuff on a secondary thread, queue up your little > bits of work in an NSOperationQueue or other GCD-backed queue that runs on > another thread. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > Charlie Dickman 3tothe...@comcast.net _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com