On 25.09.2008, at 01:18, Dan Birns wrote:
So what happened when I used [NSTimer
scheduledTimerWithTimeInterval... I was getting another timer. The
result was that my selector would get called maybe 10X more often
than intended. This didn't break anything, but impaired
performance. So no
On 25 Sep 2008, at 9:18 am, Dan Birns wrote:
I must say, after 20 years of C malloc(), I find retain/release
mysterious. It's probably no better or worse than malloc/free, but
confusing to me. It seems to me that it has exactly the same
advantages/disadvantages, but it's just wildly diff
I have my problem largely resolved, and I thought I'd share the
resolution.
Some have written pointing out that the following code has a bug:
timer = [NSTimer alloc];
[timer initWithFireDate:[NSDate date] interval:t target:self
selector:@selector(mainLoopTimer:) userInfo:hal
On 24.09.2008, at 01:20, Dan Birns wrote:
My application needs to set a timer that causes a function to be
called at a time in the future. This is non-repeating, and
sometimes has be immediate. I need it to be as efficient as
possible, because it's called frequently.
Have you checked ou
On Sep 23, 2008, at 6:20 PM, Dan Birns wrote:
My application needs to set a timer that causes a function to be
called at a time in the future. This is non-repeating, and
sometimes has be immediate.
NSTimer is a good choice. Another thing to consider, if it meets your
needs, is -performS
On Sep 23, 2008, at 19:20 , Dan Birns wrote:
I'm trying to convert from Carbon to Cocoa for a number of reasons
which I won't go into here.
My application needs to set a timer that causes a function to be
called at a time in the future. This is non-repeating, and
sometimes has be immedi
