Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!aplcen!haven!umd5!zben From: zben@umd5.umd.edu (Ben Cranston) Newsgroups: comp.sys.mac.programmer Subject: Re: ENTER/Return in Modeless dialog Summary: Bitten by dialog event stuff again Message-ID: <5334@umd5.umd.edu> Date: 18 Sep 89 23:40:58 GMT References: <419@castle.ed.ac.uk> <1721@neoucom.UUCP> Reply-To: zben@umd5.umd.edu (Ben Cranston) Organization: University of Maryland, College Park Lines: 25 In article <1721@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: > ...IM-I p. 417 has some pretty good detail on how to interpret events > in modeless dialogs. What [one] usually [does] is to call IsDialogEvent > each time through the event loop. If it returns TRUE, go ahead and do any > special processing of keys... Some time ago I reported a gotcha about having to trap off activate events before IsDialogEvent in order to properly hilight the scroll bar of a List Manager list embedded in a modeless dialog. I got bit by another gotcha last week. If a modeless dialog event is frontmost, Multifinder events (like suspend and resume) are also considered "Dialog Events". Thus, you have to check for THEM before calling IsDialogEvent... The documentation on I-416/7 is still exactly correct: 'If theEvent is an activate or update event for a dialog window, a mouse-down event in the content region of an active dialog window, OR ANY OTHER TYPE OF EVENT WHEN A DIALOG WINDOW IS ACTIVE, IsDialogEvent returns TRUE...' Emphasis added. ANY type of event. Caveat Codor. -- Sig DS.L ('ZBen') ; Ben Cranston * Computer Science Center Network Infrastructures Group * University of Maryland at College Park