68k Why call FlushEvents between InitFonts and InitWindows?

Relating to a 68k application

ryandesign

New Tinkerer
May 11, 2024
12
7
3
www.ryandesign.com
Is anyone aware of any Apple documentation that explains the reasoning behind the specific place that they suggested calling 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:

The InitFonts 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 procedure InitWindows; 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;
 

David Cook

Tinkerer
Jul 20, 2023
65
66
18
I agree that the new order makes a lot more sense, particularly since events can be added during interrupts. So, an event can be posted as the other managers are initialized.

In the 1983 (pre-launch) technical notes, they say:
"Before using the Event Manager, you should call the Window Manager procedure InitWindows: 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."
That is not the order recommended by Inside Macintosh.

In Technical Note #135 they recommend a different mask at initialization. If a disk is inserted as an application is started up, that event would originally be flushed if you use the 'everyEvent' mask by itself.
FlushEvents (everyEvent - diskMask,0);

They fixed the disk-inserted-event problem in their code (but probably only in Mac Plus ROMs and forward?) by ANDing the mask supplied by the caller.
MOVE.W D0,D4 ; mask of events to remove
AND.W FlEvtMask,D4 ; only flush masked events <03Mar85>

One other interesting bug fix:
; put a -1 into LastSPExtra (long) for the FontMGR (fixes a bug when under Switcher).
MOVEQ #-1,D1 ; <28-Oct-85>
MOVE.L D1,LastSPExtra ; <28-Oct-85>