Is anyone aware of any Apple documentation that explains the reasoning behind the specific place that they suggested calling
The Road Map chapter of Inside Macintosh I suggested the Toolbox be initialized this way:
This order is repeated in many third-party books and sample programs of the 80s and early 90s.
The order of some of these is critical. For example, Inside Macintosh I says:
I understand the purpose of calling
What I don't understand is why Apple suggested calling
Inside Macintosh I even says:
And yet their sample code shows calling
In the rebooted documentation series of the early 90s, in Inside Macintosh: Overview, in Listing 4-2, Apple has changed the order to one that makes more sense to me:
FlushEvents
during application initialization?The Road Map chapter of Inside Macintosh I suggested the Toolbox be initialized this way:
Code:
BEGIN {main program}
{ Initialization }
InitGraf(@thePort); {initialize QuickDraw}
InitFonts; {initialize Font Manager}
FlushEvents(everyEvent, 0); {call OS Event Manager to discard any previous events}
InitWindows; {initialize Window Manager}
InitMenus; {initialize Menu Manager}
TEinit; {initialize TextEdit}
InitDialogs(NIL); {initialize Dialog Manager}
InitCursor; {call QuickDraw to make cursor (pointer) an arrow}
This order is repeated in many third-party books and sample programs of the 80s and early 90s.
The order of some of these is critical. For example, Inside Macintosh I says:
TheInitFonts
procedure initializes the Font Manager; you should call it after initializing QuickDraw but before initializing the Window Manager.
I understand the purpose of calling
FlushEvents
. It clears the event queue to prevent "stray" events. For example, if the user inadvertently triple-clicked an application instead of double-clicking it, you don't want that third click to be interpreted by the new application, especially if the new application opens a window with an active control right where the application icon had been in the Finder.What I don't understand is why Apple suggested calling
FlushEvents
between InitFonts
and InitWindows
. What's the significance or importance of that? Why not call FlushEvents
after all the Init
functions? If the purpose is to clear unintended user input that occurred before the app finished launching, it makes sense that FlushEvents
should be called as late as possible in the application's initialization process, after all the managers have been initialized and after the application has loaded in its menubar and done its other initialization. In other places, like Inside Macintosh II, it just says FlushEvents
should be called "at the beginning of your application" without mentioning sandwiching it between two seemingly arbitrary Init
functions.Inside Macintosh I even says:
Before using the Event Manager, you should initialize the Window Manager by calling its procedureInitWindows
; parts of the Event Manager rely on the Window Manager's data structures and will not work properly unless those structures have been properly initialized.
And yet their sample code shows calling
FlushEvents
—part of the Event Manager—before having initialized the Window Manager by calling InitWindows
.In the rebooted documentation series of the early 90s, in Inside Macintosh: Overview, in Listing 4-2, Apple has changed the order to one that makes more sense to me:
Code:
PROCEDURE DoInitManagers;
BEGIN
MaxApplZone; {extend heap zone to limit}
MoreMasters; {get 64 more master pointers}
InitGraf(@thePort); {initialize QuickDraw}
InitFonts; {initialize Font Manager}
InitWindows; {initialize Window Manager}
InitMenus; {initialize Menu Manager}
TEInit; {initialize TextEdit}
InitDialogs(NIL); {initialize Dialog Manager}
FlushEvents(everyEvent, 0); {clear event queue}
InitCursor; {initialize cursor to arrow}
END;