USER keys in program mode
Tony T. Warnock
not work when I'm writing a program. They just beep. I have to go back
to regular mode which sort of destroys the reason for re-assigning keys.
Buchan Milne
use a library (L1791) which has a command ->TKOVR. Put the pragrom
(typically <<xx.x KEYEVAL>> ) on the stack, run ->TKOVR (you will see no
change), and then assign it.
I then backup up my keys to a variable, habing retreived them with the
RCLKEYS function. TO restore the keys (if I have a memory loss), I would put
the variable (list) on the stack, and run the following program:
<< OBJ-> 1. - 2. / 1. SWAP
FOR a SWAP ->TKOVR SWAP ASN NEXT DROP>>
(typed in from calc screen, cable not available at present)
"Tony T. Warnock" wrote:
--
Buchan Milne B.Eng(Mech) - final year
HP48GX, HP49G, Sharp EL-556D
See Africa's first satellite at http://sunsat.ee.sun.ac.za
Get Matlab in South Africa from Control Models (http://www.control.co.za)
John H Meyers
[do they recruit folks with "war" in their names to work there?]
> When I have re-assigned some keys and I am in USR mode,
> these keys do not work when I'm writing a program.
> They just beep. I have to go back to regular mode
> which sort of destroys the reason for re-assigning keys.
Too bad they didn't arrange the keys in places like Chernobyl
to also beep and not work when they are inappropriately pressed
(or turned, as the case may be).
Many programs are not suitable to be executed while you are in the
midst of editing, so by default, "key objects" which are programs
are not executed in program-editing mode.
However, a system command called TakeOver can be inserted as the
first thing in a program; even though TakeOver doesn't actually
do anything when executed, its mere presence in the program
tells the "key handler" that it is okay to execute the program,
even while in program-editing mode. To insert TakeOver into
a UserRPL program, you need a SysRPL program (included below);
then you can assign the slightly supercharged user program to a key
(you can also do exactly the same with programs in a "custom menu"
list, as is used by the [T]MENU command or the CST/CUSTOM menu).
There is a variety of different approaches which can accomplish this
(that's supposed to be correct grammar for SAT English, isn't it?):
You can create one program at a time, employing an "Insert TakeOver"
function to do what that implies, making just that one individual
key assignment, then repeat for all other assignments, until you
have created the whole collection you want. If you want to save
all of your key assignments, you can finally do RCLKEYS and
save that whole list somewhere, for a possible future STOKEYS
(perhaps executed by your STARTUP program).
Any time you ever edit a UserRPL program (or list) which
includes the "invisible" TakeOver command(s), however,
you will lose the inserted TakeOver commands,
and you will then have to re-apply them, one by one
(and perhaps re-construct your whole saved list).
Another way is not to worry about assigning individual programs;
just make a whole list of all your key assignments,
edit them as you please, and then process the whole batch of them
all at once, passing the final adjusted list on to STOKEYS to
put the actual adjusted assignments into the hidden directory,
from where they actually work. With this approach, you don't
need to preserve the TakeOver commands in your saved list of
key assignments (in fact, you will want to avoid it, as we'll see).
The problem here is, how do I indicate which programs I want
to make executable even while in program-entry mode, and
which other programs I don't want to make executable?
One way to solve this problem (and also to make the key assignment
list smaller and more efficient) is to store all assigned programs
of any significant size into separate variables in HOME, and then
to assign something very short to each key itself.
If you want a program to actually be executed in program-entry mode,
assign \<< progname \>> to its key (or menu label), but if you want
to prevent that program from being executed while editing, assign
'progname' instead (just the variable name, without program delimiters)
With this convention, we are ready to take a list of key assignments
of the form { \<<prog1\>> key1 prog2 key2 command3 key3 ... }
and adjust the whole list in a single automatic process, after which
we may perform a single STOKEYS command to assign all the keys at once;
this is exactly what I do myself in my STARTUP program, to reconstruct
all my key assignments after restoring a backup, say, but allowing
my saved assignment list to be freely edited at any time.
The programs below are all that you need to do this sort of thing.
-------------------------------------------
All of the following HP49G programs
(which also work in HP48G[X,+] with slight adjustments to 'MADJ')
operate upon a list or object on stack level 1.
Adjust a whole key assignment list before doing STOKEYS:
(uses the MADJ program below)
\<< IF DUP 1. GET 'S' SAME @ a list from RCLKEYS starts with 'S'
THEN TAIL MADJ 'S' SWAP + ELSE MADJ END \>> 'KEYPR' STO
The next function adjusts key assignment lists and/or menu lists:
(called by the program above, uses the ATAK program below)
\<< 1. \<<
DUP TYPE 8. == { ATAK } IFT @ add TakeOver to progs
DUP TYPE 5. == { DUP SIZE { MADJ } IFT } IFT @ recurse into lists
DUP TYPE 6. == @ enclose names in a program
{ DUP VTYPE 15. == @ directories (use only in menu lists)
{ DUP { 2. MENU } + \->PRG 2. \->LIST } @ HP49 lib256 function
{ :Ob>Seco: #37073h SYSEVAL } IFTE @ HP49 address
} IFT
\>> DOSUBS \>> 'MADJ' STO @ same name is in the program
SysRPL function to insert TakeOver:
(called by the program above, assemble with MASD or Jazz)
( ATAK - add TakeOver to an object of any type on the stack )
( if not already a program then it is inserted into a program )
:: CK1NoBlame INHARDROM? ITE Ob>Seco ?Ob>Seco
DUP CARCOMP ' TakeOver EQ ?SEMI ' TakeOver >HCOMP ;
SysRPL function to remove TakeOver from programs:
(not used above, but included just in case you want it)
( RTAK - remove TakeOver from a program on the stack )
( if result is a single object then "outer" program is removed )
:: CK1NoBlame INHARDROM? caseSIZEERR DUPTYPECOL? NcaseTYPEERR
DUP CARCOMP ' TakeOver EQ NOT?SEMI CDRCOMP
DUPLENCOMP #1=case CARCOMP ;
---------------------------------------------
The MADJ program includes special handling for a directory name
(intended for custom menus only); a directory name will appear
in an adjusted custom menu with the usual "tabbed" label,
pressing which will take you to the VAR menu in that directory.
All variable names appearing in custom menus adjusted with MADJ
will be protected against being stored into by any shift key;
this feature can be used to make a "safe VAR menu" via VARS MADJ TMENU
(all keys will evaluate their respective variables, but no RCL/STO)
Variable names appearing in key assignment lists adjusted
with MADJ will not do anything when pressed in PRG entry mode
(this is what was intended, but special care was taken to avoid
having the variable name inappropriately echoed in the editor);
actual programs (not just names) assigned to keys will all
have TakeOver added, however, and will execute, as designed.
Programs which cause any change of current directory may confuse
the editor and/or filer, however, so be forewarned (that's why
I avoid executing UP[DIR] or HOME or any directory names, although
you may include UPDIR and/or HOME as *commands* instead, since
these just echo their command names in PRG editing mode).
The kinds of programs most suitable to be executed even in PRG
editing mode are things like \<< 0 MENU \>> (last menu, now
also available as blue-hold+PREV), \<< nn MENU \>> (go to
otherwise unreachable HP48 menus such as I/O, STAT, ...), etc.
To assign the single-quote mark (RPN-mode algebraic syntax thingy)
to unshifted EQW on the HP49G,
assign \<< -43.3 KEYEVAL \>> to key 43.1
(and perhaps the reverse as well, if you like symmetry ;)
Assign \<< STARTOFF \>> to 101.3 to make the OFF key do STARTOFF.
If none of the key assignments work, you are not in USER mode ;)
To suspend key assignments, therefore, use blue+USER.
Set flag -61 if you want "user mode" to be "sticky"
(as almost everyone does); flag -60 similarly makes alpha mode
sticky (there's always someone to whom this is news,
so bear with this extra verbiage here, thanks).
One thing you will *not* want to do is to save your already-
adjusted key assignments back into a variable and then adjust
the previously adjusted list a second time, because the adjuster
changes variable names (names of programs) into actual programs
(which do *not* contain TakeOver, however); if you re-process that
once-adjusted list again, however, then TakeOver will be inserted
into these programs anyway, the second time around, which you
didn't want (you similarly would not want to doubly-adjust
any menu lists, especially if they contain directory names).
Editing a saved list removes all traces of TakeOver, however,
so if you want to make sure that you do not doubly-adjust
any saved lists, always edit them anew
before any new run through the adjuster.
For my custom menus, which I adjust to protect variables
(and/or add TakeOver), these necessarily have to be stored back into
a 'CST' variable, but I always edit that variable's contents again
before re-applying the above programs and re-storing back into CST.
The following little program is what I use every time I want to
change a custom menu which I keep stored in 'CSTM' (store only the
name 'CSTM' into 'CST' to protect against overwriting the saved menu):
\<< 'CSTM' DUP RCL EDIT 'MADJ' RCL EVAL SWAP \>> 'CMADJ' STO
I left out a final STO in the program, to make up my mind
whether I really want to store the changes (note that you can not
abort out of EDIT, folks, so otherwise you could be sorry :)
For my key assignment lists, I simply never store an adjusted list
back into a variable; I only pass it on to a STOKEYS command
(during STARTUP), speaking of which it's getting late,
so I want to start up and head outta here (and find out whether
it's true that the snow is as high as an elephant's eye,
and looks like it's climbing clear up to the sky :)
-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>
Sent via Deja.com http://www.deja.com/
Before you buy.
Pete M. Wilson
this a lot easier.
It seems like a token (or, if absolutely necessary, new program
delimiters) that put TakeOver into a program when compiled would make
all of this a lot easier.
In general, having invisible state like TakeOver is a bad idea. Just
make it visible in the editor.
jhme...@miu.edu (John H Meyers) wrote:
>Tony T Warnock <t...@lanl.gov>:
>[do they recruit folks with "war" in their names to work there?]
>
>
>However, a system command called TakeOver can be inserted as the
>first thing in a program; even though TakeOver doesn't actually
>do anything when executed, its mere presence in the program
>tells the "key handler" that it is okay to execute the program,
>even while in program-editing mode. To insert TakeOver into
>a UserRPL program, you need a SysRPL program (included below);
>then you can assign the slightly supercharged user program to a key
>(you can also do exactly the same with programs in a "custom menu"
>list, as is used by the [T]MENU command or the CST/CUSTOM menu).
>
Pete M. Wilson
Gamewood Data Systems Internet Service
wils...@gamewood.net
John H Meyers
> It seems like a token (or, if absolutely necessary, new program
> delimiters) that put TakeOver into a program when compiled
> would make all of this a lot easier.
> In general, having an invisible [command] like TakeOver
> is a bad idea. Just make it visible in the editor.
\<< TakeOver ... \>> would not work, as it seems you know,
because that would place TakeOver as the *second* object in
that program (the first object being \<<, which is actually
a *command* rather than a "delimiter")
New delimiter symbols?
What's left in the ISO-8859-1 character set to use?
That might entail quite a bit of work for so little general use.
It's actually a great relief (and benefit) that so many things
remain "invisible" to the UserRPL decompiler; more about this
at <http://www.deja.com/=dnc/getdoc.xp?AN=421109488>
OTOH, a separate user command to "insert TakeOver into that object"
could be provided, just as formerly inaccessible system functions
like EDIT (EditLevel1) and EDITB (ViewLevel1) have been offered
in the 49 through user commands (along with NIP, DUPDUP, PICK3,
and various all-time favorites from hacker libraries);
however, too-technical user commands may not be welcomed
by the general user-focused marketing people.
But we can still muddle through with downloading a little program
instead, just as so many HP48 "added features" are accomplished;
in fact, if there was nothing that wasn't already included
in the product, this would be a very dull forum,
and Eric would have to spend more time on classwork ;)
Homer Simpson
>by the general user-focused marketing people.
Hey I was wondering wether there are actually such people as you describe...
I only know HP owners who didn't know their calc did differentiation, and
half-gods. There seems to be no intermediate stage (or at least, they
represent a very small part of owners). Am I wrong?
>and Eric would have to spend more time on classwork ;)
"HP prevented me from studying by not including all possible features in
their products. It was a nightmare... How could they dare doing this to me?"
Homer Simpson
http://zap.to/hsimpson
Pete M. Wilson
Still think it is a bad idea to obscure features that are valuable to
regular users. Being able to remap keys inside other environments is a
valuable feature - people are asking about it. having to do so much
work to support it is ridiculous.
Personally, I'd prefer the 'X format just fine - but, I like Forth!
jhme...@miu.edu (John H Meyers) wrote:
>wils...@drop.gamewood.net (Pete M. Wilson):
>
>> It seems like a token (or, if absolutely necessary, new program
>> delimiters) that put TakeOver into a program when compiled
>> would make all of this a lot easier.
>
>> In general, having an invisible [command] like TakeOver
>> is a bad idea. Just make it visible in the editor.
>
> \<< TakeOver ... \>> would not work, as it seems you know,
> because that would place TakeOver as the *second* object in
> that program (the first object being \<<, which is actually
> a *command* rather than a "delimiter")
>
> New delimiter symbols?
> What's left in the ISO-8859-1 character set to use?
> That might entail quite a bit of work for so little general use.
>
> It's actually a great relief (and benefit) that so many things
> remain "invisible" to the UserRPL decompiler; more about this
> at <http://www.deja.com/=dnc/getdoc.xp?AN=421109488>
>
>OTOH, a separate user command to "insert TakeOver into that object"
>could be provided, just as formerly inaccessible system functions
>like EDIT (EditLevel1) and EDITB (ViewLevel1) have been offered
>in the 49 through user commands (along with NIP, DUPDUP, PICK3,
>and various all-time favorites from hacker libraries);
>however, too-technical user commands may not be welcomed
>by the general user-focused marketing people.
>
>But we can still muddle through with downloading a little program
>instead, just as so many HP48 "added features" are accomplished;
>in fact, if there was nothing that wasn't already included
>in the product, this would be a very dull forum,
>and Eric would have to spend more time on classwork ;)
>
>-----------------------------------------------------------
>With best wishes from: John H Meyers <jhme...@mum.edu>
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
John H Meyers
> it is a bad idea to obscure features
> that are valuable to regular users.
At the time of original design (of the HP48S, circa 1989?),
HP might not have been able to guess that so many hackers would
ever want to dig this far into the inner workings of the thing.
---------
In SysRPL syntax, a program object is: :: contents... ;
If I insert TakeOver into the user program \<< ... \>>
it will have to become: :: TakeOver x<< ... x>> ;
There are good reasons why the "::" and ";" should not be shown
by the built-in decompiler (mainly, the UserRPL compiler
creates lots of "inner" programs which you would not want
to see, whenever you use certain "user" syntax words involving
conditional skips or repeats, etc.); thus there are no
actual "program delimiters" shown by the decompiler,
while the UserRPL compiler relies on the added commands
\<< and \>> to do extra duty as showing the scope of
user-created programs (as opposed to system-created programs).
There is one case where the compiler does insert an invisible
token before \<<, which is whenever you write another inner
\<< ... \>> within an outer program; the inserted token is called
xSILENT' and is what causes the inner program to be put on
the stack, rather than immediately executed in the runstream.
However, this inserted token comes before the subsequent program
object ("secondary") even begins; it is not inserted within
the subsequent program object itself, just before the command x<<,
which is where TakeOver needs to be inserted, so a syntax
and compiler action to represent TakeOver would be a weird thing.
The fact that TakeOver is invisible when decompiled is what makes
the program :: TakeOver ID xxxx ; (containing a variable name xxxx)
appear on the menu key as just "xxxx", which is often desirable
(and my posted program takes advantage of this); changing the
invisibility of TakeOver could possibly impact various other
inner workings throughout the whole system (and existing software),
although I can not be sure myself to what extent this might occur.
> Being able to remap keys inside other environments
> is a valuable feature - people are asking about it.
> Having to do so much work to support it is ridiculous.
The only "work" is to install the small program which you can
invoke whenever you want to add TakeOver to a program;
the whole set of three small programs which I posted
is really a very small amount of work, puffed up
by pages of long-winded explanation to motivate
its creation, its use, and convey what to do with it.
After you have installed these few small things,
all the work is then over, since you can then
edit whatever assignments you want, and
let the adjustments be completely automatic.
Most of the time, the result of executing a program while
editing is not a desired ability; I would bet that a lot more
early complaints might have arisen if there had not been
a general "interlock" to prevent this. Also, if somehow
you find your way back into the [HP48] editor again,
while a previous edit is still underway, I believe that
there are some unique resources which might be clobbered,
as the editor text, cursor location, etc. are not kept
on the stack itself (even if they were, it might be dangerous
to let the user get a chance to mess these up).
Many things of the present are the way they are because of
historical developments, and sometimes it turns out that
they even need to be that way, or that making a hasty change
can lead to unsuspected problems (as sometimes is seen with
the drastic transformation of the HP48 into the HP49);
however, I have spoken and written my good share of fired-off
complaints about everything I first encounter, anyway,
long before I have dug into the background of how it came to be ;)