Prev: alpha-enter
Next: HP 48SX does not switch on
From: John H Meyers on 17 Jan 2010 07:14
On Sat, 16 Jan 2010 10:27:28 -0600:

> I noticed that the FREEZE command does not work when followed by INPUT

The display is normally re-drawn only when user interaction is required,
such when a program halts or exits, although some commands exist
which can write immediately to the screen (e.g. DISP).

FREEZE indicates only
which screen areas _not_ to re-draw upon the next halt or exit,
such as areas to which you earlier wrote things via DISP,
which you may want to persist on the display after a halt or exit.

INPUT will re-draw the screen anyway, to perform its intended function,
but the INPUT command includes a text message to display as a title,
as you know, in addition to a text string to be edited,
so you might place what you want displayed into that string.

Now let's explore further, about using INPUT:

INPUT OBJ\-> or INPUT STR\-> implicitly assume that your edited string
will produce the number of objects you anticipate (perhaps just one),
but it's rather easy to accidentally produce unintended results.

For example, if you mean to type "1234" but leave a space
while making corrections, perhaps leaving "12 34" before pressing ENTER,
then OBJ\-> will produce two separate numbers on the stack.

If you press ON and thus "blank out" the entire string,
then react with surprise by pressing ENTER,
then OBJ\-> will put _nothing_ on the stack.

For quick, personal, or one-time programs, one may not care,
but if more care is desired for a lasting and more predictable
user interface, you can make it a bit more stable like this:

"title" "to be edited" INPUT "{" SWAP + OBJ\->

After this, you are reasonably sure to get a final result
of exactly one thing, which will be a list, containing
the number of objects which your edited string would have produced
using OBJ\-> directly. This could be a single item, two items,
or even zero items (in other words, an empty list).

Continuing with DUP SIZE would then tell you exactly how many objects
you did create, in case that has any importance to you.

With the list on the stack, 1 GET (or HEAD) would always result
in just the first object, or 2 GET would always result in the second object, etc.

Another thing you can do with a list
is to perform another OBJ\-> (or LIST\->) on it.

This would split up the list into individual items, almost as if
you had done OBJ\-> immediately after INPUT, but the item count
would also be appended to the stack, so that you would also have
a definite count of how many items were pushed onto the stack above that.

By the way, an additional value to making the result a list
is that this prevents any alphabetic words from being evaluated
as commands, or as variable names which might already have a stored value.

For example, "X" OBJ\-> would result in 5 if variable 'X'
already contained 5, but "{X" OBJ\-> will always result in { X }

If you find the idea of using INPUT "{" SWAP + OBJ\-> to be appealing,
and find yourself using it in many different programs,
perhaps you might like to make yourself a helper program, e.g.

\<< INPUT "{" SWAP + OBJ\-> \>> 'INPUTL' STO

Now you can just use INPUTL in your other programs,
making them shorter and less tedious to create
(just one more letter, rather than several more commands).

What if we start thinking further, and wonder what might happen
if we accidentally pressed CANCEL once, thus blanking out
the entire original (or edited) input string?

Perhaps we can devise a way to get the original string back
(in case there was any) and repeat the INPUT operation in such a case,
saving us the trouble of having to re-run our entire program,
by automatically repeating the original INPUT
any time that the input area is left entirely empty:

\<< 0 DO DROP DUP2 INPUT "{" SWAP + OBJ\->
UNTIL DUP SIZE END ROT ROT DROP2 \>> 'INPUTL' STO

What if we want to add automatic syntax checking,
so that INPUT will identify any syntax errors
and not continue until they have been fixed,
thus sparing the following OBJ\-> from aborting?

Finally, let's also add the ability to cleanly cancel the program instead,
leaving nothing extra on the stack, by pressing CANCEL twice:

\<< -55 CF { V } + 0 DO DROP DUP2 IFERR INPUT THEN
DROP2 DROP2 ERRN DOERR END "{" SWAP + "}" + STR\->
UNTIL DUP SIZE END ROT ROT DROP2 \>> 'INPUTL' STO

Well, that would certainly be far too much to keep inserting
into every individual program, so it's a good thing
that we have created this permanent helper for ourselves,
usable on all HP48/49/50 calculators.

So now a pretty weak original INPUT OBJ\-> has been "hardened"
into something usable by "industrial strength" calculator software,
using nothing more than UserRPL, yet this is still
only the very simplest of user interfaces for accepting input.

There are also built-in PROMPT and INFORM commands, there are more UserRPL
programs which can accept input via a menu of variable labels (INMENU)
or an unlimited vertical "form" of any length (INLIST),
there are SysRPL internals to make special screen forms,
and... anything else? Oh well, thats enough input for one post :)

"INLIST, INMENU, and INPROMPT"
(more alternate user interfaces for data input)
http://groups.google.com/group/comp.sys.hp48/msg/c18173a5066b36f9

[r->] [OFF]
From: Michael Kuyumcu on 18 Jan 2010 09:22
On Jan 17, 1:14 pm, "John H Meyers" <jhmey...(a)nomail.invalid> wrote:
> On Sat, 16 Jan 2010 10:27:28 -0600:
>
> > I noticed that the FREEZE command does not work when followed by INPUT
>
> The display is normally re-drawn only when user interaction is required,
> such when a program halts or exits, although some commands exist
> which can write immediately to the screen (e.g. DISP).
>
> FREEZE indicates only
> which screen areas _not_ to re-draw upon the next halt or exit,
> such as areas to which you earlier wrote things via DISP,
> which you may want to persist on the display after a halt or exit.
>
> INPUT will re-draw the screen anyway, to perform its intended function,
> but the INPUT command includes a text message to display as a title,
> as you know, in addition to a text string to be edited,
> so you might place what you want displayed into that string.
>
> Now let's explore further, about using INPUT:
>
> INPUT OBJ\-> or INPUT STR\-> implicitly assume that your edited string
> will produce the number of objects you anticipate (perhaps just one),
> but it's rather easy to accidentally produce unintended results.
>
> For example, if you mean to type "1234" but leave a space
> while making corrections, perhaps leaving "12 34" before pressing ENTER,
> then OBJ\-> will produce two separate numbers on the stack.
>
> If you press ON and thus "blank out" the entire string,
> then react with surprise by pressing ENTER,
> then OBJ\-> will put _nothing_ on the stack.
>
> For quick, personal, or one-time programs, one may not care,
> but if more care is desired for a lasting and more predictable
> user interface, you can make it a bit more stable like this:
>
> "title" "to be edited" INPUT "{" SWAP + OBJ\->
>
> After this, you are reasonably sure to get a final result
> of exactly one thing, which will be a list, containing
> the number of objects which your edited string would have produced
> using OBJ\-> directly.  This could be a single item, two items,
> or even zero items (in other words, an empty list).
>
> Continuing with DUP SIZE would then tell you exactly how many objects
> you did create, in case that has any importance to you.
>
> With the list on the stack, 1 GET (or HEAD) would always result
> in just the first object, or 2 GET would always result in the second object, etc.
>
> Another thing you can do with a list
> is to perform another OBJ\-> (or LIST\->) on it.
>
> This would split up the list into individual items, almost as if
> you had done OBJ\-> immediately after INPUT, but the item count
> would also be appended to the stack, so that you would also have
> a definite count of how many items were pushed onto the stack above that.
>
> By the way, an additional value to making the result a list
> is that this prevents any alphabetic words from being evaluated
> as commands, or as variable names which might already have a stored value..
>
> For example, "X" OBJ\-> would result in 5 if variable 'X'
> already contained 5, but "{X" OBJ\-> will always result in { X }
>
> If you find the idea of using INPUT "{" SWAP + OBJ\-> to be appealing,
> and find yourself using it in many different programs,
> perhaps you might like to make yourself a helper program, e.g.
>
> \<< INPUT "{" SWAP + OBJ\-> \>> 'INPUTL' STO
>
> Now you can just use INPUTL in your other programs,
> making them shorter and less tedious to create
> (just one more letter, rather than several more commands).
>
> What if we start thinking further, and wonder what might happen
> if we accidentally pressed CANCEL once, thus blanking out
> the entire original (or edited) input string?
>
> Perhaps we can devise a way to get the original string back
> (in case there was any) and repeat the INPUT operation in such a case,
> saving us the trouble of having to re-run our entire program,
> by automatically repeating the original INPUT
> any time that the input area is left entirely empty:
>
> \<< 0 DO DROP DUP2 INPUT "{" SWAP + OBJ\->
> UNTIL DUP SIZE END ROT ROT DROP2 \>> 'INPUTL' STO
>
> What if we want to add automatic syntax checking,
> so that INPUT will identify any syntax errors
> and not continue until they have been fixed,
> thus sparing the following OBJ\-> from aborting?
>
> Finally, let's also add the ability to cleanly cancel the program instead,
> leaving nothing extra on the stack, by pressing CANCEL twice:
>
> \<< -55 CF { V } + 0 DO DROP DUP2 IFERR INPUT THEN
> DROP2 DROP2 ERRN DOERR END "{" SWAP + "}" + STR\->
> UNTIL DUP SIZE END ROT ROT DROP2 \>> 'INPUTL' STO
>
> Well, that would certainly be far too much to keep inserting
> into every individual program, so it's a good thing
> that we have created this permanent helper for ourselves,
> usable on all HP48/49/50 calculators.
>
> So now a pretty weak original INPUT OBJ\-> has been "hardened"
> into something usable by "industrial strength" calculator software,
> using nothing more than UserRPL, yet this is still
> only the very simplest of user interfaces for accepting input.
>
> There are also built-in PROMPT and INFORM commands, there are more UserRPL
> programs which can accept input via a menu of variable labels (INMENU)
> or an unlimited vertical "form" of any length (INLIST),
> there are SysRPL internals to make special screen forms,
> and... anything else?  Oh well, thats enough input for one post :)
>
> "INLIST, INMENU, and INPROMPT"
> (more alternate user interfaces for data input)http://groups.google.com/group/comp.sys.hp48/msg/c18173a5066b36f9
>
> [r->] [OFF]

It's (always) a pleasure to read your thoughtful, thorough replies
full of years of experience. I wish you would bottle your didactic
explorations up as a kind of additional programming reference, not
only for beginners, but I am sure that also intermediate-level hp
programmers would benefit from your condensed hp wisdom.

Regards,
 | 
Pages: 1
Prev: alpha-enter
Next: HP 48SX does not switch on