hartkopf@tramp.Colorado.EDU (Jeff Hartkopf) (09/30/89)
I'm having problems figuring out how to use a filter procedure for a dialog box (I'm using ORCA/C). I need to pass a filter to the ModalDialog() call so it will filter out certain keypresses: in the dialog I have a line edit which I want to *only* to accept hexadecimal digits (0-9, A-F, a-f), and ignore any other keypresses (unless the keypress is RETURN, in which case I want the dialog to handle that normally, by selecting the default button). So I figured I'd just tell the filter to check if the event is a keypress; if so, if it's an invalid character (anything but RETURN and hex characters), return TRUE (the filter handled the keypress, i.e., did nothing), otherwise return FALSE (let the dialog manager handle the keypress in the standard way). The main problem is, when I call ModalDialog(), it keeps calling my filter procedure repeatedly, never drawing any of the controls in the dialog box. Another question is, once I get that part working, if the event's what field is keyDownEvt, is the message field the character pressed? Here's what I tried: pascal word FILTER(GrafPortPtr dlog, EventRecord *evtptr, int *itemHit) { #define c evtptr->message #define RETURN 13 if (evtptr->what == keyDownEvt) if (c != RETURN && (c < '0' || (c > '9' && c < 'A') || (c > 'F' && c< 'a') || c > 'f')) /* invalid */ return (TRUE); /* just ignore them */ return (FALSE); #undef RETURN 13 #undef c } /* later... */ ... int itemHit; ... /* OK and CNCL are 2 buttons */ while ((itemHit = (int) ModalDialog((WordProcPtr) FILTER+0x80000000)) != OK && itemHit != CNCL) { /* stuff */ } Any suggestions would be greatly appreciated. Jeff Hartkopf Internet: hartkopf@tramp.Colorado.EDU
dlyons@Apple.COM (David Lyons) (09/30/89)
In article <12232@boulder.Colorado.EDU> hartkopf@tramp.Colorado.EDU (Jeff Hartkopf) writes: >[...] if the event's what field is keyDownEvt, >is the message field the character pressed? Yes, the low-order byte is (Toolbox Ref vol 1, page 7-8). Your approach looks good. Change > #define c evtptr->message to #define c (evtptr->message)&0xFF (Or, better yet, try: char c = (evtptr->message)&0xFF; That way you'll avoid having the compiler generate the code to check that field 7 times. > if (evtptr->what == keyDownEvt) > if (c != RETURN && (c < '0' || (c > '9' && c < 'A') || > (c > 'F' && c< 'a') || c > 'f')) /* invalid */ > return (TRUE); /* just ignore them */ My, that's pretty scary to read. Double check that you don't have any precedence problems (and remind me to get a C reference for my cube :-) . [I can never remember where "!=" fits into the precedence hierarchy...usually I use lots of parentheses & don't worry about it.] -- --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
MMPR004@ECNCDC.BITNET (Scott Hutinger) (09/30/89)
Your modaldialog works just like you tell it to. But, do you want to handle any of the events at all? One thing you should do is filter out all possible modifier stuff such as: char ch; ch = (*theEvent).message & 0x7f to clear out any possible modifiers Anyway, I will cut off the rest of my message. But for my sake,(just trying to finally transfer from the Mac to do some GS stuff) so I know whats going on. #define btn0State 0x0080 /* Modifier Flags - set if button 0 up */ Now, would you not get a != if the above was true with a & 0xFF? I am not sure, as I have not finished getting the Free Form sound to work yet. Sort of slow sometimes. scott hutinger mmpr004@ecncdc.bitnet ( I can't read page 7 yet, as they are in the mail )
dlyons@Apple.COM (David Lyons) (09/30/89)
In article <8909292233.aa12233@SMOKE.BRL.MIL> MMPR004@ECNCDC.BITNET (Scott Hutinger) writes: >[...] One thing you should do is filter out all possible modifier stuff >such as: > >char ch; >ch = (*theEvent).message & 0x7f to clear out any possible modifiers Not necessary--the modifiers are in theEvent->modifiers, not theEvent-> message. You also don't have to (and *shouldn't*, actually) strip off bit 7 of the character, since all 256 byte values are legal extended-ASCII characters. (If Key Translation is enabled, as it is by default, the option key will result in key-down events for lots of upper-128 characters; stripping bit 7 would make some weird option key presses appear as *other* lower-128 characters. This wouldn't be disasterous--just Really Strange.) -- --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
MMPR004@ECNCDC.BITNET (Scott Hutinger) (09/30/89)
Hmm, looks like the GS is just like a mac. So, modifiers on the GS are grabbed just like the other machine. Guess I was thinking that the modifiers were within the word, as upper bits. Oh well, something else must live up in them there bits. Does this mean you can grab the raw key code characters too? eg: #define charCodeMask 0x000000FF #define keyCodeMask 0x0000FF00 I promise to keep quite till my books come. :-) But, then again I don't know if my keyboard will put out a key without a modifier > 0x7f. Must have something to do with the way the managers are initialized. Guess I never had to check for errors on initialization before. Scott Hutinger mmpr004@ecncdc.bitnet
dlyons@Apple.COM (David Lyons) (10/04/89)
In article <8909300318.aa14123@SMOKE.BRL.MIL> MMPR004@ECNCDC.BITNET (Scott Hutinger) writes: >[...] So, modifiers on the GS are grabbed just like the other machine. >Guess I was thinking that the modifiers were within the word, as upper >bits. Oh well, something else must live up in them there bits. Does >this mean you can grab the raw key code characters too? eg: > >#define charCodeMask 0x000000FF >#define keyCodeMask 0x0000FF00 > >I promise to keep quite till my books come. :-) But, then again I don't >know if my keyboard will put out a key without a modifier > 0x7f. Must have >something to do with the way the managers are initialized. Guess I never had >to check for errors on initialization before. > >Scott Hutinger mmpr004@ecncdc.bitnet I'm not following you...the modifiers are in the "modifiers" field of the event record; the character typed is in the "message" field. Under System Software 5.0, stuff like Option-D gets mapped into a character in the range $80-$FF (but *not* by simply flipping bit 7 on...there's an actual table), and the Option bit is still turned on in the modifiers field. -- --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.