Redefining Keys: Multiple Conundrua

[John R. Graham]

Redefining keys with a special type of function is an interesting choice, the most surprising part of which is that the KEY functions merely feed a string of characters back to the entry line. Just as an exercise, I'm trying to redefine the LOG key to execute CSC (Cosecant). First attempt for RPN mode looked like this:

Code:

KEY K_Log()
BEGIN
  RETURN "CSC(1)";
END;

(Mr. Han explained that the (1) argument causes the command to fetch one argument from the stack.) So the key redefinition is recognized by the calculator, but when I type "1.4" and press the [LOG] key, then I just end up with

Code:

1.4CSC(1)

on the entry line (probably indicating that I should prepend a space character to the returned string). Pressing [Enter] results in the calculation being executed properly, but that's not what you want: you want execution triggered by pressing the key, just like all the other trig keys. So, that leads to my first question. Is there a character that you can append to the string returned by the KEY function to cause the entry line to be executed? Neither CR (0x0D) nor LF (0x0A) appear to work. (I could've sworn that LF worked for a little while but it doesn't work for me now. I'm not sure what I did.)

Now, second related issue. Say I wanted the key to behave correctly in both algebraic and RPN enrty modes. That's where the programmatic nature of the KEY functions could shine. The Entry variable from the home screen settings is global so I could return two different strings, depending on entry method. That would result in something like this:

Code:

KEY K_Log()
BEGIN
  IF Entry = 2 THEN
    RETURN " CSC(1)"; // Plus some magic to cause execution.
  ELSE
    RETURN "CSC()"; // Plus some different magic (see below).
  END;
END;

However, in algebraic mode, when you hit, for instance the [TAN] key, whan ends up on the entry line is

Code:

TAN()

with the cursor in between the parentheses. So, that leads me to my second question. Is there a character that can be appended to the string returned by the KEY function that will cause the entry line cursor to back up? The most obvious candidate would appear to be BS (0x08) but that doesn't work.

Now all this leads me to my third question. These little example programs to merely accomplish key reassignment (as yet incomplete or incorrect though they may be) have met or exceeded the size of many a useful little program I've written on other HP programmables. Shouldn't there be an easier way?

- John

[Craig Thomas]

When you figure out how to successfully reprogram a key based on entry mode, please post an example.

Thanks.

[rprosperi]

You can extend the key definition to return the redefined command plus the keycode for the Enter key, which "activates" the string sent back. Using your example:

Code:

KEY K_Log()
 BEGIN
   RETURN "CSC(1)";
   RETURN(30);   // 30 is keycode for Enter (count them, starting with Apps=0)
 END;

I'm still experimenting, but it looks like you can build up a complex series of strings/or and keycodes and have pretty thorough control of what is sent back.

Tim/Cyrille - any practical limits on what can be returned?

Thanks for asking a good question prompting some fun research, and thanks to Han for a hint in an earlier post.

[John R. Graham]

Bob, did you try your example on the calculator? I've never seen a programming language where control flow passes through a RETURN construct like that and, in my own tests of your example, it didn't appear to.

- John

[rprosperi]

Yes, I too have problems with it now John.

It was indeed tested prior to posting. I normally will test something 3-4 times before posting, but on the Prime I test about 10 times first to be sure; in this case especially since the procedure is indeed so odd and counterintuitive.

It worked until I changed my machine RPN->Textbook (and other settings, but don't recall the sequence) and doing some CAS stuff. I also modified the key settings PPL file for some other changes, to consolidate some settings.

Gotta go figure out what settings and/or sequence work. Hope it's me and not a bug that mysteriously allowed it to work only long enough to complete the post. I hate when that happens.

[rprosperi]

After much (!) testing there is good news and bad news about the technique I posted above.

The Good News: It does happen, so I'm not crazy.

The Bad News: It only happens sometimes, most likely due to a bug, since I agree it isn't intuitive it should work that way.

Starting with the CSC() argument on the stack (RPN mode per the original prblm) and this code:

Code:

KEY K_Tan()
BEGIN
//RETURN "CSC(1)";
RETURN(30);
END;

in a program in the catalog (note 3rd line is initially commented out).

6-7 out of 10 times, if you do this:

Delete the slash characters in line 3 to remove comment and restore the command
Press ESC to exit/compile the file
Press HOME
Press TAN to the invoke new assignment.

Prime will insert the CSC(1) and execute the enter returning the CSC of the original argument to the stack.

VERY USEFUL for creating key assignments, but unfortuntely, it's only a bug.

Tim/Cyrille - it would be great if this bug could become a feature