variables in other directories

[Jeffrey_G]

I'm writing programs for the HP-48/49. My problem is that the directory I'm working in is cluttered with other programs and variables.

I wish to keep only a small set of programs in a given directory and all associated variables in a different directory. When running a program, how can I read from or write to a variable which is located in a directory other that the one containing the calling program?

Thanks,

Jeff

[Vieira, Luiz C. (Brazil)]

Hi;

this answer uses only user RPL techniques, O.K.? If there are better solutions with SYS RPL or Assembler, I do not know them.

The way I know to achieve this is by "going to" the directory at the beginning of the program and using an UPDIR at the end of it to get back to the original directory, provided that the variables' directory is a subdirectory of the program's directory itself. (is it clear?).

Say you face the following tree and [prog1] is your main program:

HOME                        (in other systems it may be called ROOT)

  PRGM1 [prog1] [prog2] ... [progn]

    VAR1  [v01] [v02] [v03] ... [vnn]

Consider the names without brackets as directory names and [name] as variables' names, programs included. If [prog1] uses any of the variables in VAR1 directory and you are sure it runs error-free from the first to the last command, them [prog1] should look like this:

«

  VAR1

(program's body)

  UPDIR

»

All commands in (program's body) will store in and recall from variables existing in VAR1. The only BIG warning is that If you refer to any variable that does not exist in VAR1 directory and, for any reason, you have another variable with the same name in HOME or PRGM1, this variable will be reached by the program. This is because the HP48 O.S. searches for existing variables in the current directory AND, if it is not found, up in the directory tree till HOME. Then, if there are no variables with the same name, an error occurs. Even if it sounds awkward, this allows you to read the contents of any variable (even run a program) already existing in any upper directory from another program in a subdirectory. You cannot directly write on these variables without changing the current "path".

What I normally do is to use an input program that creates compiled local variables (the ones with names begining with <-), then I call a "subprogram" that switches to the "variable's directory", like the example above. This "subprogram" is completely safe, runs error-free, may access the compiled local variables and is the only program that will read and write in the variables that exist in the "subdirectory" . At the end of it, the necessary results are placed in the stack and the UPDIR command is executed. When the final » is found, the O.S. is working again in the original directory were the main program is stored. Then the program takes the results from the stack and shows them the way you like it. This structure is functional and applicable when you have many variables and extensive manipulation. Small programs and a few variables may be kept in "small boxes", too. Just a guess.

I hope this helps you.

Cheers.

[MikeN]

Jeff

Glad you asked.

Your intention, placing variables (programs or other "fixed" objects?)in a different directory.
To secure their integrity?
To remove clutter from the "fixed" variables in the "application" directory.
Or both?

Luis
(I am hoping you will read this)
The latter is simple, placing them in a directory above the "application" directory.

Can this directory be hidden, or the variables write protected?

I confess. The left shift key, pressed immedialely preceeding a softkey, has broken my heart on a number of occasions. Overwriting a program (which took hours to create) with just a moments distraction. OUCH! How easy it is to do.

Trusting a user, giving him immediate access to both the program and it's underlying lookups may be the issue. Any suggestions?

[Vieira, Luiz C. (Brazil)]

Hi, Mike;

I agree with the upper position: a directory with the variables with a subdirectory with the programs. What bothers me is that you must pass through the variables to reach the programs, and it may not be wished, I don't know. Even so, deleting a filled directory requires the specific use of PGDIR, that must be "spelled-out" or assigned to a softkey in Custom menu. This is a relative protection, agree?

It seems to me you know how to recover from this unintentional variable erase, but let's mention it, as it may be not known by others. This is a very important resource available in any HP48: recovery from a deletion. The HP28S does not allow such recovery procedure. And many former HP28 users may not know it can be undone in the HP48.

Both S-series and G-series allow such a recovery, even if it happens from a PURGE or a left-shift key + softkey. You just need to recall the last ARGuments. BUT this feature is active ONLY if Save Last Arguments flag, # -55, is CLEARED. If it is SET, last ARGument feature is disabled (inverse logic). If you are in doubt, [MODES] [FLAGS] and roll-down till you find flag 55 and you'll see:

  55 Save Last Args

If you press the check-mark softkey it changes to:

V 55 No Last Args

About protecting data, the only means I know is by generating a library with your original source code. I did it once for the HP48SX as soon as I got the Goodies Disks from EduCalc (1994, I guess). I do not remember how to do it, I must read the docs again, but I remember you could hide whatever you want when defined as hidden for the compiler, running on a PC. Otherwise, all I have no idea on to hide a variable or protect it from being overwritten or erased. All I know is that when you are transferring data from an external device to the calculator you can set overwrite or create a new name, usually prevname.n, were n goes from 1 to as many copies as possible from the original file. But I have not found a way to do it by the keyboard. I also remember this issue was discussed in here about one year ago, and the ones discussing this possibility came to the conclusion that we may not be able to activate it for keyboard entries because it may be more related to a Kermit resource than to an HP48's resource.

I believe this is all I can mention about it.

Sorry not helping the way I'd like to.

Success.