Threaded Mode | Linear Mode

StephenG1CMZ · 07-24-2016, 07:06 PM

So far when I have wanted to check for a user key, I have checked for that keys HP number, thus IF KK==4 for ESC.

If you have a lot of keys to check for, or in the interests of portability, an alternative would be preferred. I had thought to use the key name (listed under user key customisation), but that name is giving me a syntax error if I simply replace the "4" with "K_Esc".

Code:

 //KK

 EXPORT KK()

 BEGIN

  LOCAL KK;

  WHILE 1 DO

   KK:=GETKEY();

   IF KK≠−1 THEN

    PRINT(KK);

    IF KK==4 THEN // I  cannot use K_Esc

     MSGBOX("ESCAPE");

    END;

   END; 

  END;

 END;

Am I missing something obvious to use those key names for checking for keys?
Or is there a better way?

Tim Wessman · (This post was last modified: 07-25-2016 11:41 PM by Tim Wessman.)

There is not any way to do this apart from numbers. The problem basically boils down to not wanting to create "nice names" for every possible variable option in the system. You'd probably be adding another 500 reserved words or so.

The reason it doesn't work is quite simple - 4 is not equal to a string.

What people normally do, is put in a comment or similar.

IF KK==4 THEN // K_Esc

Tyann · (This post was last modified: 07-26-2016 05:36 AM by Tyann.)

Bonjour

Voici ce que j'ai mis en place sur ma machine
si cela peut vous être utile.

Hello

Here's what I 've put on my machine
While this may be useful .

Code:

EXPORT K_APPS:=0;

EXPORT K_SYMB:=1;

EXPORT K_UP:=2;

EXPORT K_HELP:=3;

EXPORT K_ESC:=4;

EXPORT K_HOME:=5;

EXPORT K_PLOT:=6;

EXPORT K_LEFT:=7;

EXPORT K_RIGHT:=8;

EXPORT K_VIEW:=9;

EXPORT K_CAS:=10;

EXPORT K_NUM:=11;

EXPORT K_DOWN:=12;

EXPORT K_MENU:=13;

EXPORT K_VARS:=14;

EXPORT K_MATH:=15;

EXPORT K_TEMPL:=16;

EXPORT K_XTTN:=17;

EXPORT K_ABC:=18;

EXPORT K_BKSP:=19;

EXPORT K_POWER:=20;

EXPORT K_SIN:=21;

EXPORT K_COS:=22;

EXPORT K_TAN:=23;

EXPORT K_LN:=24;

EXPORT K_LOG:=25;

EXPORT K_SQ:=26;

EXPORT K_NEG:=27;

EXPORT K_PAREN:=28;

EXPORT K_COMMA:=29;

EXPORT K_ENTER:=30;

EXPORT K_EEX:=31;

EXPORT K_7:=32;

EXPORT K_8:=33;

EXPORT K_9:=34;

EXPORT K_DIV:=35;

EXPORT K_ALPHA:=36;

EXPORT K_4:=37;

EXPORT K_5:=38;

EXPORT K_6:=39;

EXPORT K_MUL:=40;

EXPORT K_SHIFT:=41;

EXPORT K_1:=42;

EXPORT K_2:=43;

EXPORT K_3:=44;

EXPORT K_MINUS:=45;

EXPORT K_ON:=46;

EXPORT K_0:=47;

EXPORT K_DOT:=48;

EXPORT K_SPACE:=49;

EXPORT K_PLUS:=50;

.

Toutes ces affectations sont à mettre dans un programme.
Vous pouvez écrire ensuite :
All these assignments are put in a program.
You can then write :

Code:

IF 'VAR'==K_ESC THEN

  .....

  .....

Pour accéder aux variables :Touche VAR, menu Utilisateur, option :nom du programme
To access variables : VAR button , User menu, option : name of the program

Martin Hepperle · 07-26-2016, 08:27 AM

(07-26-2016 05:12 AM)Tyann Wrote: Hello

Here's what I 've put on my machine
While this may be useful .

...

All these assignments are put in a program.
You can then write :

Code:

IF 'VAR'==K_ESC THEN ..... .....
To access variables : VAR button , User menu, option : name of the program

... all these EXPORT variables require some memory. A sort of #define or #const keyword which would simply define a placeholder would be more memory efficient. On the other hand there seems to be plenty of memory, so why care?

Martin

StephenG1CMZ · (This post was last modified: 07-26-2016 08:47 PM by StephenG1CMZ.)

(07-25-2016 11:41 PM)Tim Wessman Wrote: There is not any way to do this apart from numbers. The problem basically boils down to not wanting to create "nice names" for every possible variable option in the system. You'd probably be adding another 500 reserved words or so.

The reason it doesn't work is quite simple - 4 is not equal to a string.

What people normally do, is put in a comment or similar.

IF KK==4 THEN // K_Esc

When you said 4 is not equal to a string, I thought K ESC was a string.
But MSGBOX(STRING(K_Esc,))
Doesn't work - which could have been useful if you wanted to say "Press Escape to Escape" but refer to the key name consistently:
"Press "+K_Esc+" to Escape".

As an alternative to having 50 Exports, I was considering having one Export - effectively a list.
Whilst accessing a list would likely be less efficient than a constant, it minimises the number of exports, and also the list sequence associates a number with the key - which might be useful for the keys 0..9 0..F or A..Z.

Code:

LOCAL ZTypeString:=2;

 //HP KEYS: 0..50

 //INCOMPLETE

 ZKEYS:={

  "Apps","Symb", "Up",           "Help","Esc",

  "Home","Plot", "Left","Right", "View","CAS",

         "Num",  "Down",         "Menu"};

EXPORT  ZHPKey(XX)

 //RETURN ITEM (NUM OR KEYNAME)

 //SHIFTNAMES LETTERS DIGITS TBD

 BEGIN

  CASE

   IF TYPE(XX)==ZTypeString THEN 

    RETURN POS(ZKEYS,XX)-1;

   END;

   DEFAULT

    RETURN ZKEYS(XX+1);

  END;

 END;

 EXPORT Z_HP()

 BEGIN

  ZHPKey("Esc");ZHPKey(4):

 END;

Tim Wessman · (This post was last modified: 07-26-2016 08:59 PM by Tim Wessman.)

(07-26-2016 08:26 PM)StephenG1CMZ Wrote: When you said 4 is not equal to a string, I thought K ESC was a string.
But MSGBOX(STRING(K_Esc,))
Doesn't work - which could have been useful if you wanted to say "Press Escape to Escape" but refer to the key name consistently:
"Press "+K_Esc+" to Escape".

What I meant is that if you are doing something like 4 == "K_Esc", it is always false because the string "K_Esc" is not equal to the numerical value 4. There is no mapping exposed between the names used in the user key definitions, and the numerical values.

We've thought about several possibilities, but never have found one that we really liked yet.

StephenG1CMZ · (This post was last modified: 07-26-2016 09:59 PM by StephenG1CMZ.)

Thanks for that explanation Tim.
And thanks Tyann and Martin.

StephenG1CMZ · (This post was last modified: 08-12-2016 06:43 PM by StephenG1CMZ.)

I would like to suggest a useful feature: Some way of enabling or highlighting a list of keys from within a program.

An earlier version of my Periodic Table program allowed the user to choose how to select an element: "Symb" key to input Au, "Enter" to enter "gold", etc.

I needed some way of reminding the users which keys were implemented.

Given the current technology, I tried DRAWMENU("Symb","Enter")..
This listed the keys, but was confusing - so far, my program has no touch interface, so instead of tapping Symb on-screen you have to hit the Symbol key.

What I really wanted was a command like
ENABLEKEYS({"Symb","Enter"})
that on the emulator would highlight the keys the keys that the user can use in some way.

On the real hardware that would not be possible, so one would need a way of bringing up a helpful choose list on-screen:
ENABLEKEYS({""Symb","Press Symb to input symbol"}) etc.

Some users might find it much easier to select from a choose list of a limited number of usable keys, than to hunt for those keys over the full keyboard.

Of course, I could pop-up such a list on--screen myself in response to some key or other...
But then each program's mechanism for accessing the key prompt would be different....
Nicer to have a standard key, and one able to change the colour of the emulator keys too.

Also possible, would be an option for keys not enabled to be ignored by GETKEY/ISKEYDOWN.

My latest version of the program eliminates most keypad entry and uses a choose list instead, but highlighting keys in use would still be useful.

Fortin · (This post was last modified: 08-19-2016 03:50 PM by Fortin.)

(08-12-2016 06:33 PM)StephenG1CMZ Wrote: Also possible, would be an option for keys not enabled to be ignored by GETKEY/ISKEYDOWN.

If the desire is for these functions to ignore key presses that you don't care about, then ISKEYDOWN may have new functionality that could help. ISKEYDOWN includes a feature in 10077 that returns a 64bit value (one bit per key) so you are able to see multiple key presses with one function call. If you then bitwise AND with a proper mask, you can filter out disabled keys.

For example, if you wanted to detect View (9) and Enter (30), you could create a mask of #40000200:64h (2^9 + 2^30). To create this mask, something like this works well: SETBASE(BITSL(#1b,9)+BITSL(#1b,30),4)

BITAND(ISKEYDOWN(-1),#40000200:64h) will return a mask containing only the keys of interest that are pressed.

toml_12953 · 08-19-2016, 03:36 PM

(07-26-2016 08:39 PM)Tim Wessman Wrote:
(07-26-2016 08:26 PM)StephenG1CMZ Wrote: When you said 4 is not equal to a string, I thought K ESC was a string.
But MSGBOX(STRING(K_Esc,))
Doesn't work - which could have been useful if you wanted to say "Press Escape to Escape" but refer to the key name consistently:
"Press "+K_Esc+" to Escape".

What I meant is that if you are doing something like 4 == "K_Esc", it is always false because the string "K_Esc" is not equal to the numerical value 4. There is no mapping exposed between the names used in the user key definitions, and the numerical values.

We've thought about several possibilities, but never have found one that we really liked yet.

How about making the key names constant values (like the value of Pi)?

DISPLAY K_Esc

would display 4

Tom L

StephenG1CMZ · 08-26-2016, 06:19 PM

(08-19-2016 02:57 PM)Fortin Wrote:
(08-12-2016 06:33 PM)StephenG1CMZ Wrote: Also possible, would be an option for keys not enabled to be ignored by GETKEY/ISKEYDOWN.

If the desire is for these functions to ignore key presses that you don't care about, then ISKEYDOWN may have new functionality that could help. ISKEYDOWN includes a feature in 10077 that returns a 64bit value (one bit per key) so you are able to see multiple key presses with one function call. If you then bitwise AND with a proper mask, you can filter out disabled keys.

For example, if you wanted to detect View (9) and Enter (30), you could create a mask of #40000200:64h (2^9 + 2^30). To create this mask, something like this works well: SETBASE(BITSL(#1b,9)+BITSL(#1b,30),4)

BITAND(ISKEYDOWN(-1),#40000200:64h) will return a mask containing only the keys of interest that are pressed.

Yes, that mask would do what I was thinking of when I suggested ignoring keys not enabled.
i had been thinking of a user interface more like ENABLEKEYS({4},True) or ENABLEKEYS({K_ESC},True) where True=ignore other keys, but ANDing a mask is good too.