frankng@basser.UUCP (03/27/87)
I was looking through the sample program *MiniEdit* discussed in Stephen Chernicoff's book *Macintosh Revealed Vol II* when I stumbled across what I think maybe a bug, please correct me if I'm wrong. It involves the interaction between the procedure *CloseAppWindow* and the procedure *DoActivate*: In *CloseAppWindow*, TEDispose is called to dispose of the program window's edit record, which is part of a structure whose handle is the window's reference constant. Then HideWindow is called to force a deactivate event, upon which Chernicoff's Activate/Deactivate event handler is invoked: TEDispose(editRec); ... HideWindow(TheWindow); /* force deactivate event */ if GetNextEvent(ActivateEvt, TheEvent) then DoActivate; /* handle deactivate event */ if GetNextEvent(ActivateEvt, TheEvent) then DoActivate; /* handle activate event */ However, in *DoActivate*, if the event is a deactivate event, the window's edit record is deactivated: if BitAnd(modifiers, ActiveFlag) <> 0 then /* handle activate event */ else begin /* handle deactivate event */ ... TEDeactivate(editRec); ... end; Will this not bomb, since the program is referencing (trying to deactivate) a nonexistent (NULL?) edit record in TEDeactivate? Also, aren't the parameters to GetNextEvent incorrect? Shouldn't the first parameter be ActivMask instead of ActivateEvt? thanks in advance for any help -- Frank Ng ACSnet: frankng@basser.oz Department of Computer Science ARPA: frankng%basser.oz@seismo.css.gov University of Sydney NSW 2006 UUCP: seismo!munnari!basser.oz!frankng AUSTRALIA
pgn@osupyr.UUCP (03/30/87)
I found other burs a Mac Revealed as well. For instance, where the filter function for ModalDialog is explained the DialogRecord is accessed via myDialog^^, but it cannot be done that way since myDialog is a DialogPtr which is the same as WindowPtr. Instead, one needs to introduce a DialogPeek guy and so forth.