On Wed, Oct 28, 2009 at 7:08 AM, Dave Keck wrote:
>
> I've hit several other brick walls from recursive run loops, but they
> escape me at the moment. Nonetheless, recursive run loops are a fancy
> way of blocking, and are contrary to the event-driven model that we
> know and love.
>
> I guess th
On Oct 27, 2009, at 11:13 PM, John Engelhart wrote:
While Cocoa might do this, there's probably a few "important
details" that
you're glossing over. Using a different run loop mode for the the
recursive
run of the loop is a good example. I'd be willing to bet there's an
implicit assumptio
Recursive run loops always lead to cleaner but worse code (IMO, of
course :)). Recursive mouse tracking, for example, keeps all the code
dealing with the state changes in one place, and allows for
method-scope variables that keep track of the state rather than ivars.
On the other hand, you have to
On Wed, Oct 28, 2009 at 12:21 AM, Kyle Sluder wrote:
> On Tue, Oct 27, 2009 at 8:53 PM, John Engelhart
> wrote:
> > I would *STRONGLY* advise against doing this. While it may be perfectly
> safe
> > to recursively run a CFRunLoop, this says nothing about the implications
> of
> > doing so. At f
On Tue, Oct 27, 2009 at 8:53 PM, John Engelhart
wrote:
> I would *STRONGLY* advise against doing this. While it may be perfectly safe
> to recursively run a CFRunLoop, this says nothing about the implications of
> doing so. At first glance, it would seem that everything a run loop "does"
> as a r
On Tue, Oct 27, 2009 at 7:37 PM, Jean-Daniel Dupas
wrote:
>
> Le 27 oct. 2009 à 21:47, Alexander Cohen a écrit :
>
>
>
>> On Oct 27, 2009, at 3:42 PM, Jens Alfke wrote:
>>
>>
>>> On Oct 27, 2009, at 12:11 PM, Alexander Cohen wrote:
>>>
>>> 100% agree with you, and that's what i would normally do.
Le 27 oct. 2009 à 21:47, Alexander Cohen a écrit :
On Oct 27, 2009, at 3:42 PM, Jens Alfke wrote:
On Oct 27, 2009, at 12:11 PM, Alexander Cohen wrote:
100% agree with you, and that's what i would normally do. But
unfortunately, this time i must wait in the mainthread for the
callback.
On Oct 27, 2009, at 3:42 PM, Jens Alfke wrote:
On Oct 27, 2009, at 12:11 PM, Alexander Cohen wrote:
100% agree with you, and that's what i would normally do. But
unfortunately, this time i must wait in the mainthread for the
callback. I know it's wrong, but this time i've gotta do it.
T
On Oct 27, 2009, at 12:11 PM, Alexander Cohen wrote:
100% agree with you, and that's what i would normally do. But
unfortunately, this time i must wait in the mainthread for the
callback. I know it's wrong, but this time i've gotta do it.
Then use a while loop to run the runloop until your
On Oct 27, 2009, at 2:04 PM, Jens Alfke wrote:
On Oct 27, 2009, at 10:40 AM, Alexander Cohen wrote:
Now, i would like to be able to wait for that callback on the main
thread like this:
[object addObserverForCallback]
... wait for callback ...
continue on processing with the state of the o
On Oct 27, 2009, at 10:40 AM, Alexander Cohen wrote:
Now, i would like to be able to wait for that callback on the main
thread like this:
[object addObserverForCallback]
... wait for callback ...
continue on processing with the state of the object
The only way i see i can do that is by runn
Hi,
I'm working with and SDK that lets me observe objects. When the state
of the object changes i receive a callback. The docs for the SDK say
that the main NSRunLoop needs to stay active and responsive for me to
receive the callbacks. Now, i would like to be able to wait for that
callbac
12 matches
Mail list logo
