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