[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

#### 6.1.1.2 Run-Loop

The typical Crystal Space application assumes that the programmer has full control over the application's run-loop. For many platforms to which Crystal Space has been ported, this is not a problem since the main run-loop is generally implemented in this fashion:

    bool csDefaultRunLoop(iObjectRegistry*)
    {
      while (!shutdown)
        event_queue->Process();
    }

With Cocoa, on the other hand, the main run-loop is not accessible to the programmer and is essentially a black-box. A simple-minded implementation of the above functionality for Cocoa might look like this:

    bool csDefaultRunLoop(iObjectRegistry*)
    {
      [NSApp run];
    }

This code launches the Cocoa run-loop but does not address the problem of periodically processing Crystal Space's event queue. To solve this problem ``OSXDelegate'` artificially injects application-defined events into the Cocoa event queue and then triggers an invocation of `iEventQueue::Process()` for each such received event. A single application-defined event is injected into the event queue in order to begin the process, and then an event is injected into the queue after each invocation of `iEventQueue::Process()`.

Note that `csDefaultRunLoop()` is provided as a convenience for applications which do not otherwise supply their own run-loop. Existing Cocoa applications which already employ the `NSApplication`'s black-box run-loop should not invoke `csDefaultRunLoop()`; but should instead arrange to have `iEventQueue::Process()` invoked on a periodic basis via some other mechanism.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ]

This document was generated using texi2html 1.76.