Re: Method to disable key trigger (Elegant one)

From: Leo Mannhart <mannhart_at_zuv.unizh.ch>
Date: Fri, 2 Sep 1994 07:55:19 GMT
Message-ID: <mannhart-0209940855190001_at_zuvmaclm.unizh.ch>


In article <kenho.32.2E65B835_at_hk.super.net>, kenho_at_hk.super.net (Kenneth Ho) wrote:

> Leo
>
> You explanation is absolutely correct.
>
> When you place a null instruction on the KEY-OTHER trigger, it will suppress
> ALL the key triggers that you have not explicitly define in a form. But I
> still want some default key triggers to fire, for example, KEY-NEXT-ITEM.
>
> Any idea?
>
> Kenneth Ho
> Programmer
> Hospitality Data Resources Ltd., H.K.
Now we're in the "not so elegant method" area. If you define a KEY-OTHER trigger in the form level with "null" I strongly recommend to also define a few other key triggers especially a KEY-EXIT trigger (if you don't, you will find out the hard way why, unless you like ^C or ^Y on a unix box or VMS respectively). So whatever you want a key trigger to do you have to define it yourself. So if you start with a KEY-OTHER trigger in form level I suggest to define it (in the design and test phase) as something message('Key has not been defined yet'). Then you can define your key triggers you need in your application. So a KEY-NXTBLK can test the current block name and go to the next block if there is one or go to the first one (so cycling through all the blocks) or give a message to the operator, or whatever you like the key to do. If you once started with a KEY-OTHER with the "null" procedure defined, you will wonder how many keys are pressed by the users in a "normal" application. But then, you can define every key in every level you like. For a few (like KEY-EXIT, KEY-NXTBLK, KEY-PRVBLK, KEY-NXTREC, KEY-PRVREC, KEY-NXTFLD, KEY-PRVFLD...) it is a "have to".

Hope this helps
LM

-- 
Leo Mannhart
Planning Office
University of Zurich           phone: ++41 1 257 23 34
Kuenstlergasse 15                fax: ++41 1 257 22 12
CH-8001 Zurich, Switzerland    eMail: mannhart_at_zuv.unizh.ch
Received on Fri Sep 02 1994 - 09:55:19 CEST

Original text of this message