DECIDE ON FIRST VALUE OF *PFKEY
VALUE ‘ENTR’
…DO A PROCESS…
VALUE ‘PF8’
…DO A PROCESS
VALUE ‘PF11’
…DO A PROCESS
NONE VALUE
REINPUT 'Requested PF-Key not Allocated. ’
END-DECIDE
in my Natural Program I have this
SET KEY NAMED OFF
SET KEY PF8 NAMED ‘Cancl’
SET KEY PF11 NAMED ‘Addr’
WHEN I am testing my program and map, if I press PF4 I expect to get an error ‘Requested PF-Key not Allocated’
Instead I get a Natural error saying the same thing, with the program name first, the Natural Error number, then a statement. It does not go into my map processing rules.
If add at bottom of this list in my program, the following:
SET KEY PF4 OFF
I get my processing rule.
WHY? Does this mean that if I want to deliver the message for PFKEY handling I have to code each one in a SET statement?
It seems a generic SET KEY ON or SET KEY OFF…goes to Natural first on an error instead of a processing rule.
Michele …low priority question…
When I searched thi forum, I found a posting for PF KEYS and MAPS back in 2006, but got an error , of could not find…when I click on the thread. If the thread is not available why is it still in the bulletin board?
Lets start with your first run.
PF4 is not in any way program sensitive (pgm=on, or equated to data, or a command)
Hence, when you press pf4 Natural “intervenes” and tells you this key doesn’t exist (sort of).
The second run is a mystery. SET KEY PF4 OFF gets you a compiler error. Did you actually have just SET KEY PF4? This would explain what happened. Now PF4 is program sensitive and Natural will not object to hitting it; and you will get to your processing rules.
What do you think SET KEY NAMED OFF does? All it actually does is turn naming off for all the keys; it has nothing to do with sensitivity, etc.
SET KEY PF1 NAMED OFF PF2 NAMED OFF PF3 NAMED OFF
PF4 NAMED ‘CMPL’ PF5 NAMED OFF PF6 NAMED OFF
PF7 NAMED OFF PF8 NAMED OFF PF9 NAMED ‘TOP’
PF10 NAMED OFF PF11 NAMED ‘MENU’ PF12 NAMED ‘MMENU’
When we do this, We do not get a ‘name’ for those PF keys that are set to NAMED OFF, but we are also allowed to have a processing rule for these’ OFF’ KEYS.
We do not get any compile errors. (perhaps we have an option turned on or off?)
I thought any SET KEY function was making the key available to the program. .i.e. ON or OFF,
so I tried
SET KEY NAMED OFF - which i thought made all keys available to processing rules but no ‘name’ was given to any of them.
Then I thought I would only turn on the ones I wanted… with
SET KEY PF4 NAMED ‘CMPL’ (etc from above example.) I thought this turned the KEY ON and NAMED it and also had access to processing rules.
I understand now. Are we doing something Strange? :?:
You had: SET KEY PF4 OFF which is not legal syntax
you meant : SET KEY PF1 NAMED OFF which is legal syntax
What would be easier than the code you have, is:
SET KEY ALL /* all keys made program sensitive
SET KEY PF2 NAMED ‘updat’ /* names pf2
*SET KEY NAMED OFF / turns all names off
INPUT ‘hit any pf key’
END
All keys would be program sensitive and PF2 would be named. If you added the DET KEY NAMED OFF, PF2 would lose its name.
I understand now. Are we doing something Strange?
Not so much strange as tedious to code; too much typing.
So
SET KEY ALL /*
SET KEY PF4 NAMED ‘CMPL’
PF9 NAMED ‘TOP’
PF11 NAMED ‘MENU’
PF12 NAMED ‘MMENU’
is the same as the following:
SET KEY PF1 NAMED OFF PF2 NAMED OFF PF3 NAMED OFF
PF4 NAMED ‘CMPL’ PF5 NAMED OFF PF6 NAMED OFF
PF7 NAMED OFF PF8 NAMED OFF PF9 NAMED ‘TOP’
PF10 NAMED OFF PF11 NAMED ‘MENU’ PF12 NAMED ‘MMENU’
Which means all PF keys can be controlled by processing rules mesages, and only PF4, 9, 11, 12 have a name.
