In windows, each thread has a message queue, and each message queue processes messages for windows belonging to this thread. This means that it’s quite simple to write an application in which you can create a stream with a message outline and one (or more) windows. Ignoring any problems with applications, now you have application windows that will continue to interact with the user, even if one of the other windows is busy with some kind of modal operation.
Now, porting the application to cocoa, I came across, well, Interface Builder. This is a surprise for those who expect more control over creating windows and building a message pipeline. Nevertheless, I can see where the IB comes from.
My problem, however, is the opaque functionality of NSApplicationMain (). This - in the main application stream, automatically creates the main application window and starts the message pump, all data is managed beautifully from NIB files.
However, this leaves me with a problem: even if I buy the idea that Interface Builder is a way to make my main application window - and I figured out enough objective C to create subframes on the fly - as well as how to create streams - I see how to create pump messages in work streams. I begin to doubt his ability.
Does windows in cocoa even have the kind of thread similarity that they make in Win32? that is, each thread has its own message dispatch cycle for windows belonging to this thread? I am beginning to suspect that perhaps cocoa expects all of my windows to “belong” to the main thread, and I just get the work offset (and drawing) to other threads.
Any tips on how to best translate a Win32 multi-window application to threads into cocoa paradigms?
source
share