> i forgot/neglected to change the batteries in my memory cards for a
> LOOOOOOOONG time, thinking that they would draw on the Calc's power...
I think only when calc [48GX/SX] is turned on,
as it is advised when changing card batteries
to make sure not only that the card is fully
inserted in slot, but also that calc is ON.
> One of the programs let me look at individual UserKeys, which required
> me to look up the UserKey List in the Hidden Directory...! But when i
> searched this group for the SYSEVAL for it, i found this DOUBLE
> Syseval combo which didn't work...??? # 64037h #6FD1h
In 48[S/G],
#64037h is WithHidden, and #6FD1h is COLA (not what you want).
The usual program for "CDHD" is
:: CK0NOLASTWD SetHiddenRes SYSLCONTEXT ;
which in UserRPL for HP48[S/G] *only* is
\<< #640BEh SYSEVAL #8DC4h SYSEVAL \>>
> comments associated with this suggested that the old FAQ method,
> #15777h [48: NULLID] caused problems, but failed to say what they were...
Conflict with "variable hiders," which may create additional
null-named variables to "hide" whatever else follows;
evaluating a null name then evaluates the first object found,
which can be the object created by the hider, rather than
the null-named "hidden" directory at the end of HOME.
Other ways of safely storing/recalling from hidden directory:
49: http://groups.google.com/group/comp.sys.hp48/msg/8ad9a09874a2d1c1
49/48: http://groups.google.com/group/comp.sys.hp48/msg/f23467dc8825c947
It's a perennial question (apparently in FAQ too):
http://groups.google.com/group/comp.sys.hp48/msg/8bf161298d50a658
[r->] [OFF]
> In 48[S/G],
> #64037h is WithHidden, and #6FD1h is COLA (not what you want).
It dawns upon me that TA may have taken these out of context,
from a program in one of my own postings that I just referred to,
but mistaking the purpose of the program.
The purpose of *my* 'Hidden' program is to *temporarily*
make the hidden directory itself the current directory,
only while evaluating the next single object
that *follows* in a running program, rather than
to navigate into the hidden directory and stay there
(which is what the "CDHD" program was for).
In other words, \<< Hidden VARS \>> would produce a list
of the names of the variables in the hidden directory,
but without leaving the current directory.
\<< 'UserKeys' Hidden RCL \>> would recall the hidden
(and weirdly formatted) *internal* user keys list, etc.
But why not just use the RCKLEYS command instead,
which puts everything into standard format for you,
rather than directly looking into the internal list?
The following program can be used to implement 'Hidden'
(as always, type very carefully, and back up memory first!)
@ "Any calc" version HP50G/49G[+]/48[Gii/S/G][X/+]
\<< RCLF SIZE 3 < #64037h #370C3h IFTE
#6FD1h SYSEVAL SYSEVAL \>> 'Hidden' STO
By the way, you have to arrange the above program
exactly as shown, to obtain the correct effect of COLA,
which then makes WithHidden act on the calling runstream
(ask someone who is just learning SysRPL to explain it :)
The following companion program 'Here' also operates
on whatever single object *follows* it in a program,
but its effect is to prevent any "upward searching"
into higher directories to resolve variable names
or command names, etc.
Try \<< 60 DEG "COS" Here OBJ\-> \>> for example,
but be sure that you run this in a subdirectory,
rather than in HOME;
then remove 'Here' and see the difference.
One potential use is to test whether a named variable
exists in the *current* directory, via
\<< 'X' Here VTYPE \>> @ result -1 if not in current directory
In the absence of using 'Here' the above program
would keep searching until it had even looked in HOME.
Type carefully, and back up memory first!
@ "Any calc" version HP50G/49G[+]/48[Gii/S/G][X/+]
\<< RCLF SIZE 3 < #185C7h #25EC4h IFTE
#6FD1h SYSEVAL SYSEVAL \>> 'Here' STO
[r->] [OFF]
If \<< Hidden VARS \>> works,
then why doesn't \<< Hidden \<< VARS \>> \>> also work?
The answer is that a UserRPL program \<< ... \>>
can not be used as the "following" object
for 'Here' or 'Hidden' to evaluate,
because in that case the user program \<< ... \>>
is actually the *second* object following 'Hidden'
(again, ask someone just studying SysRPL why that happens).
However, you can do it this way instead:
\<< \<< VARS \>> Hidden EVAL \>>
[r->] [OFF]
:: COLA DoHere: ;
:: COLA WithHidden ;
As independently stored programs, these are useful
only to be invoked by UserRPL programs,
because in SysRPL programs you can just directly
use the runstream words DoHere: and WithHidden
which each act on the immediately following runstream object,
the idea of this whole exercise having simply been
to extend that ability to UserRPL programs, via the
creation of similar UserRPL commands "Here" and "Hidden"
[r->] [OFF]
> But why not just use the RCKLEYS command instead,
> which puts everything into standard format for you,
> rather than directly looking into the internal list?
Taking the UserKeys List from the Hidden Directory is ALOT faster,
practically instaneous (?).
As for the comment by (?) that the format is 'Weird', is itself weird.
the list is a straightforward 1::1 list of lists for each of the Keys,
including, i think???, ON.
So the trick then is to activate the program, prompt for a key to be
hit, wait for a key, then figure out which key it is on the UserKeys
list, GET that, tag all six of the internal lists ( keynumber, <-, ->,
a, a<-, a-> ) and leave them on the stack.
It's very quick.
The program also contains a simple and complimentary method of putting
things on the User Keys, but to do that, it simply uses the ASN (???)
function...???