PPL INPUT function

[orcinus]

Is there a way to make INPUT pre-populate the fields with default values?
You can specify the defaults as the last argument, but those only show up if you hit Shift+Esc while focused on a field. There doesn't seem to be a way to pre-fill them with those defaults, though.

While on the subject, any plans for more complicated input forms (a combination of dropdowns and text fields)?

[Karl-Ludwig Butte]

Hi,

simply store the default value into the variable prior to the INPUT command and it will be displayed in the field:

EXPORT INPUTTST()
BEGIN
LOCAL A;
100▶A;
INPUT(A, "Test","Test","Test",100);
PRINT (A);
END;

In addition you only need to press ENTER to accept the default value instead of pressing SHIFT+ESC and then ENTER
Hope this helps.

Best regards

Karl

[DrD]

Changing the numerical "100" to the (previously set) variable name "A" (at the end of the input statement) might be useful, as well.

Instead of:
INPUT(A, "Test","Test","Test",100);

Use:
INPUT(A, "Test","Test","Test",A);

[orcinus]

Very useful, thanks!

Bizzarrely, i could've sworn i tried setting the variable to a default value before the INPUT (except via := instead of STO) with it not working. I must've made a typo somewhere.

[jlastofka]

I'M having a lot of trouble with the INPUT function. It seems very buggy, working differently on various runs of a simple program. I've got the latest Firmware (flashed it twice), and I've reset the calculator with the pin hole, and Apps Esc On, and the FCO method. I've deleted all the programs and reset the user variables. And I've tried other programs similar to this with the same result.

Program calculates Euler buckling of beams:

EXPORT BUCKLE()
BEGIN
K:=1;
INPUT(E);
INPUT(I);
INPUT(L);
F:=E*I*pi^2/(K*L)^2;
RETURN F;
END;

( pi IS REALLY THE GREEK SYMBOL
AND THE ^2 ARE REALLY SUPERSCRIPTS,
I JUST DON'T KNOW HOW TO PUT THEM HERE)

This will work a few times. Then it will start corrupting the E,I and L variables and causing run errors or bad results. I'll do some editing and it will work a few times and then start corrupting again. I've also tried the longer INPUT(E, "text", "text", "text", 100); optional version. It ignores the 100 value and pretty much misbehaves like the simper version. All else on the calculator seems to work well.

If I take out the INPUT lines and use EXPORT BUCKLE(E, I, L) to get the I/O it works fine, but then of course I have to type in all three values every time I rerun the program. And I want my INPUT function to work right anyway.

-AND- I get the same bogus behavior on the PC emulator, too. I guess I'm doing something wrong, but I don't see it.

Thanks for any help.

-Jeff

[Tim Wessman]

I do see some misbehavior here only on the latest public one. What I see is that the initial value displayed if accepted without entering a new value is defaulting to 0. So if I enter values for each number, it works fine. If I just press ENTER and move on to accept the default then I see something like a 0/0 error in my result. There isn't any sort of corruption though nor any sort of crash. Does that match what you are seeing?

Any reason why you aren't getting all 3 values at once? Is it specifically for the auto-close on enter or were you not aware of the ability to request multiple at a time?

INPUT({E,I,L})

Now to work around this for the moment, you can put your E I L into a program variable. This only appears to happen with the global reals on the last public one. This works correctly for me here.

Code:

e0,i0,l0;
EXPORT BUCKLE()
BEGIN
K:=1;
INPUT({e0,i0,l0},"Buckle EQ",{"E:","I:","L:"});
RETURN e0*i0*pi^2/(K*l0)^2;
END;

Note how those variables are no longer the global E I L vars. For the short term this will allow it to work for you without issues I think. You can also put units on your input too which wouldn't be possible with the global reals.

[jlastofka]

Thank you Tim for the help and tips. The following version does what I need. I now think there's definitely a bug in the INPUT function when used with global variables. I also figured out how to copy the program from the emulator to here:

Code:


LOCAL e0,i0,l0;
EXPORT BUCKLE3()
BEGIN
e0:=E;
i0:=I;
l0:=L;
K:=1;
INPUT({e0,i0,l0});
E:=e0;
I:=i0;
L:=l0;
F:=E*I*π²/(K*L)²;
RETURN F;
END;

It seems that maybe the INPUT function isn't updating values (in or out?) properly outside the program, perhaps until something else happens, and it's resulting in the wrong values being used at times....?

I need the global variables coming in and out because I'm using this program at work to design some beams and make sure they don't buckle and destroy our machine or injure (kill?) someone. I often run the program several times with some or all of the same values while I'm checking loads or converging on a size of a beam. So as you can see, I just forced the global to local variable copying to be done outside the INPUT function and then I use only local variables inside the INPUT function.

I also noticed you didn't need the LOCAL command. I didn't know you could leave that out. Thanks again for your help, and I presume the INPUT function will be repaired in the next Firmware update (unless I still don't understand what's up).

-Jeff

[Han]

You may want to check out:

http://www.hpmuseum.org/forum/thread-215.html

The INPUT() command is quite robust; however its simplest form does is not the form you want given the requirements you listed.

[jlastofka]

Han,

Thanks for the link. Looks like I can learn a lot there.

I'd say the INPUT function is not very robust though. If I use it with the built in global E, I, L variables it usually (not always) works the first time or two I run a program, then starts acting up as I re-run the program several times. It will start prompting with values out of sequence say, the E value showing up in the I prompt, or sometimes a letter, like K, and if I go out to the home screen and use Shift-Mem to look at the list of variables I can click through them and occasionally find a letter k stored in what's supposed to be a Real Variable, like E for instance. I see this on the emulator and the calculator.

Sometimes the program will fail on launch with an Invalid Input (I forget the exact wording) warning. Sometimes it will let me get part way or all the way through the INPUT entry boxes and then error out. I've had it seem to go all the way through and then give me clearly wrong answers from my program.

All this is with that very simple program with only a few inputs and a couple equations.

Fortunately, it seems to work reliably with local variables and I can just do the local to global copying myself. I haven't checked how it does with global variables other than the simple A, B, C, .... Z ones built in. I suppose it does fine, or everyone would be talking about this. It's just that E, I, K and L are the historical notation for the equations I'm working with.

Sure is a nice calculator, though. I assumed the 50g was going to be the end of the line. I'm very glad that HP's kept on developing and I'm relieved they've stayed with a quality keyboard feel and haven't cheaped out there like so many other companies.

The only thing I actually dislike is having to type := all the time. It's very tedious on the keyboard. Odd that = works in practically every other computing language on the planet but not here.

-Jeff

[Han]

(04-13-2014 03:04 AM)jlastofka Wrote:  The only thing I actually dislike is having to type := all the time. It's very tedious on the keyboard. Odd that = works in practically every other computing language on the planet but not here.

-Jeff

The := sequence is just an alternative way of using the STO command for those who prefer to program on a computer and then transfer to the calculator (since the arrow symbol is not a typical character on most PC keyboards). So when programming on a calculator, simply use something like:

0 -> E (where -> is the arrow obtained from the STO command) to do the equivalent of E:=0

[jlastofka]

Quote:The := sequence is just an alternative way of using the STO command for those who prefer to program on a computer and then transfer to the calculator (since the arrow symbol is not a typical character on most PC keyboards). So when programming on a calculator, simply use something like:

0 -> E (where -> is the arrow obtained from the STO command) to do the equivalent of E:=0

Sorry, I missed what you're getting at there, but I meant in the programs.

A=A+5;
instead of
A:=A+5;

It takes me four keystrokes on the calculator for := vs what could have been one key (Two in the present implementation) for = , which is used a lot.

I'll bet Apple would have done it like this:

If you're typing in Alpha mode, and you need the = character, you could press and hold the . key and after a moment it would put in the = character instead. Same thing for the numerals. If you're in Alpha mode typing in a variable name and you need a numeral you could just press its key and hold a moment and you'd get the numeral instead of the letter. This would save an awful lot of shifting in and out of Alpha mode.

Anyway, we're getting away from the original thread here.

-Jeff

[Joe Horn]

(04-13-2014 04:51 AM)jlastofka Wrote:  

Quote:The := sequence is just an alternative way of using the STO command for those who prefer to program on a computer and then transfer to the calculator (since the arrow symbol is not a typical character on most PC keyboards). So when programming on a calculator, simply use something like:

0 -> E (where -> is the arrow obtained from the STO command) to do the equivalent of E:=0

Sorry, I missed what you're getting at there, but I meant in the programs.

He's saying that instead of := you should use the ► character (Shift EEX, the right-pointing triangle). Yes, it works in programs too. Instead of E:=0, use 0►E. That takes only two keystrokes while programming, and only one tap in Home and CAS.