Legacy Document

Inside Macintosh: Files /

Chapter 5 - Disk Initialization Manager / Using the Disk Initialization Manager

Responding to Disk-Inserted Events

When the user inserts a disk, the Operating System attempts to mount the volume on the disk by calling the File Manager function PBMountVol. If the volume is successfully mounted, an icon representing the disk appears on the desktop. The Operating System then generates a disk-inserted event. If the user is interacting with a standard file dialog box, the Standard File Package intercepts the disk-inserted event and handles it. Otherwise, the event is left in the event queue for your application to retrieve.

Your application must either mask out disk-inserted events or process them by checking to see whether the inserted disk is invalid. If you mask out such events, then each disk-inserted event needlessly occupies a position in the event queue until the user brings an application that can handle such events to the foreground or until your application invokes the Standard File Package. Also, displaying the disk initialization dialog box long after the disk has been inserted is likely to confuse the user. However, you might wish to mask out disk-inserted events when you create modal dialog boxes in which you process events with WaitNextEvent rather than ModalDialog. That way, your application can process disk-inserted events as soon as the modal dialog box closes.

Note

By default, the Dialog Manager's ModalDialog procedure automatically masks out disk-inserted events so that your application can handle them when dialog boxes close. If you wish to accept disk-inserted events in a modal dialog box in which you call ModalDialog, you must supply a filter procedure for the dialog box. See the chapter "Dialog Manager" in Inside Macintosh: Macintosh Toolbox Essentials for information on how to write a filter procedure.

Because handling disk-inserted events is easy, there is no good reason for your application to mask out the events in its main event loop. Listing 5-1 defines a
procedure that your application can call when it receives a disk-inserted event.

Listing 5-1 Responding to disk-inserted events

PROCEDURE DoDiskEvent (myEvent: EventRecord);
VAR
   myPoint:    Point;
   myErr:      OSErr;
BEGIN
   IF HiWord(myEvent.message) <> noErr THEN
      BEGIN                            {attempt to mount was unsuccessful}
         DILoad;                       {load Disk Initialization Manager}
         SetPt(myPoint, 120, 120);     {set top left of dialog box}
         myErr := DIBadMount(myPoint, myEvent.message);
                                       {notify the user}
         DIUnload;                     {unload Disk Initialization Manager}
      END
   ELSE                                {attempt to mount was successful}
      ;                                {do other processing}
END;

The DoDiskEvent procedure in Listing 5-1 checks the high word of the event message to see if the disk is mounted properly. If it has not been mounted, DoDiskEvent calls the Disk Initialization Manager's DIBadMount function, which displays the disk initialization dialog box. Before doing so, DoDiskEvent calls DILoad to ensure that the Disk Initialization Manager and its dialog box are loaded into memory. If you did not call DILoad and the user started up with a floppy system startup disk, the Operating System might require that the user reinsert the system disk and might then attempt to initialize that disk. In Listing 5-1, if the user did start up with a floppy system startup disk on a single floppy-drive system, the DILoad procedure requests that the user insert the system disk so that it can read the necessary resources, and then it ejects that disk so that the user can again put the disk to be initialized into the drive. After calling DIBadMount to handle the uninitialized disk, DoDiskEvent calls DIUnload to release the resources DILoad read into memory.

Beginning with system software version 7.0, the first parameter to DIBadMount is ignored, and the disk initialization dialog box is automatically centered on the screen.

The procedure in Listing 5-1 ignores the result code returned by DIBadMount because ordinarily it does not concern your application. If an error does occur during initialization, DIBadMount informs the user and ejects the disk.