Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!USU.BITNET!FATQW
From: FATQW@USU.BITNET (Bryan Ford)
Newsgroups: comp.sys.amiga
Subject: Re: One more suggestion...
Message-ID: <8802281741.AA02067@jade.berkeley.edu>
Date: 28 Feb 88 16:36:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 29

>>Make a new Intuition IDCMP class - HELPKEY.  If it's enabled, and the user
>>presses the HELP key, it sends this class rather than RAWKEY.  This way we
>>won't have to worry about RAWKEY just to see if the user pressed HELP.
>
> I would argue against this because it does something that's already
>easy to do (check for RAWKEY code == 0x5f) and because there are only
>31 Intuition message classes possible, and I'd like to preserve as
>many as possible for future message classes. HELPKEY just doesn't seem
>important enough (this assumes that the HELP key is guaranteed to
>generate code 0x5f; if it isn't, then HELPKEY is appropriate).

Oops, forgot to mention the *real* reason for doing this!  Checking RAWKEY
is not hard.  However, take a program that uses RAWKEY to pop up context-
sensitive help.  The user wants to change something in a string gadget.
He clicks in the string gadget, and forgets what it's supposed to be used
for.  He presses HELP.  Nothing.  He presses it again.  And again.  Nothing.
Panic.  He starts pounding and smashing at the keyboard.  Still nothing.

Get the idea?  RAWKEY codes aren't transmitted when string gadgets are
activated.  I think the user should be able to get help while in a string
gadget.  And I DON'T want to create my own string gadget support routines.
Sorry I forgot to put this in my first posting on this subject.

                                Bryan

        Bryan Ford                    //// A computer does what \\\\
Snail:  1790 East 1400 North         //// you tell it to do, not \\\\
        Logan, UT 84321          \\\X///  what you want it to do. \\\X///
Email:  FATQW@USU.BITNET          \XXX/ Murphy's Law Calendar 1986 \XXX/