12 Startup Actions

▼ |  | The Racket Graphical Interface Toolkit

1 | Windowing
2 | Widget Gallery
3 | Windowing Classes
4 | Windowing Functions
5 | Editors
6 | Snip and Style Classes
7 | Editor Classes
8 | Editor Functions
9 | WXME Decoding
10 | Preferences
11 | Dynamic Loading
12 | Startup Actions
13 | Init Libraries
14 | Platform Dependencies
| Index

Racket
top contents ← prev up next →

## 12 Startup Actions🔗ℹ

The racket/gui/base module can be instantiated only once per operating-system process, because it sets hooks in the Racket run-time system to coordinate between Racket thread scheduling and GUI events. Attempting to instantiate it a second time results in an exception. Furthermore, on Mac OS, the sole instantiation of racket/gui/base must be in the process’s original place.

Instantiating racket/gui/base sets two parameters:

- executable-yield-handler — The executable yield handler is set to evaluate (yield initial-eventspace) before chaining to the previously installed handler. As a result, the Racket process will normally wait until all top-level windows are closed, all callbacks are invoked, and all timers are stopped in the initial eventspace before the process exits.

- current-get-interaction-input-port — The interaction port handler is set to wrap the previously installed handler’s result to yield to GUI events when the input port blocks on reading. This extension of the default handler’s behavior is triggered only when the current thread is the handler thread of some eventspace, in which case current-eventspace is set to the eventspace before invoking yield. As a result, GUI events normally can be handled while read-eval-print-loop (such as run by the plain Racket executable) is blocked on input.

The thread where racket/gui/base is instantiated also becomes the handler thread for the initial eventspace. See also Eventspaces and Threads.

top contents ← prev up next →