[comp.sys.apple] IIGS filter procedure for dialog box

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.