nick@lfcs.ed.ac.uk (Nick Rothwell) (09/15/89)
Modal dialogs interpret Return/Enter as a hit on button item #1, which
avoids newlines going into TextEdit fields. I want to do the same with
modeless dialogs. In particular, I *don't* want Return/Enter to put in
a newline (making the text disappear in a one-line TextEdit box). If
possible, I'd like to see the key event as well. Is this possible?
Will I get flamed for even thinking of trying to do it?
Nick.
--
Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh.
nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick
~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~
Fais que ton reve soit plus long que la nuit.sam@neoucom.UUCP (Scott A. Mason) (09/17/89)
In article <419@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >Modal dialogs interpret Return/Enter as a hit on button item #1, which >avoids newlines going into TextEdit fields. I want to do the same with >modeless dialogs. In particular, I *don't* want Return/Enter to put in >a newline (making the text disappear in a one-line TextEdit box). ... Firstly, IM-I p. 417 has some pretty good detail on how to interpret events in modeless dialogs. What I usually do is to call IsDialogEvent each time through the event loop. If it returns TRUE, go ahead and do any special processing of keys like command-keys, and return. (You'll still have to call your dialog with the proper item that was hit, i.e. 1 if return) You'll know if a key was hit by checking theEvent.what (or whatever your EventRecord is). If it was a keyDown, check theEvent.modifiers for the exact key that was hit. If the key is not one of the special keys you want to process, pass them along to DialogSelect for further handling. Hope this helps. I would highly recommend verifying this with IM-I, though. -- -------------------------------------------------------------------------------- "If it ain't broke, don't fix it," and certainly don't blame me. UUCP: {pitt,scooter,hal,cwjcc,aablue}!neoucom!sam INTERNET: sam@neoucom.UUCP Scott A. Mason, Coordinator of Systems Operations, NEOUCOM
zben@umd5.umd.edu (Ben Cranston) (09/19/89)
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 <zben@Trantor.UMD.EDU> * Computer Science Center Network Infrastructures Group * University of Maryland at College Park