cancel
Showing results for
Did you mean:
Level 1
8 6 0 0
Message 1 of 10
1,326
Flag Post

Solved!

Problem with reset values on INPUT form

HP Recommended
HP Prime Graphing Calculator

I ran into some trouble using the INPUT command. Here is the code that causes an unexpected issue when using the reset feature on the INPUT form:

INPUT({{a,[0],{40,50,1}}, {b,[0],{40,50,2}}, {c,[0],{40,50,3}}, {d,[0],{40,50,4}}},

"Test", {"a ", "b ", "c ", "d "}, {"", "", "", ""} , {844., 1000, 15.55, 5.}, {a, b, c, d});

If I populate the fields using the reset on all values (Shift-Esc), all values are reset properly (a to 844, b to 29.92, etc.). However, if I use the individual field reset (backspace) the input value looks correct (with the exception that instead of 1,000 for b 1000 is shown without the grouping comma), but INPUT does not accept the value.

This causes some irritation using my app since the values look like correct numbers but are not accepted without retyping them. How can I fix this?

Tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Level 1
5 3 1 0
Message 5 of 10
Flag Post
HP Recommended

Hi Thomas,

Here you go, give this a try...

INPUT( {{AA,[2]}}, "AA", "AA", "AA", -1, -2 );     //<--- change [0] to [2]

AA:=EXPR(STRING(AA));       // Add this line per variable

PRINT(2*AA); WAIT;

INPUT(BB,"BB","BB","BB",-2,-3);

BB:=EXPR(STRING(BB));      // Add this line per variable

PRINT(2*BB); WAIT;

This will get around the inconsistency of the Del and Clear actions, but it requires moving to string type for the fields. INPUT returns different types in the various cases you've highlighted - returning a mix of real (0), string (2) and function (8.) (You can check this yourself using TYPE(AA) for example. The Del function is is the oddest, in that it only passes validation if [-1] is used in the allowed_types_matrix. It fails validation if [2] (string) is used even though a string gets returned (and even supplying all non-CAS types [0,1,2,3,4,5,6,8,9]!) It also doesn't appear to make any difference whether a '-' ASC(45) or '+/-' ASC(8722) is supplied to INPUT as the initial value or reset value - regardless it seems to always be treated as a string.

Changing the types matrix from [0] to [2] and adding var:=EXPR(STRING(var)); after each INPUT ensures that where a number - including any of the minus signs ('-' or '+/-' key) - is entered, a number is available from INPUT. You can pull this out into a function and potentially roll up validation into it as well.

Anyway, the above may give you a little ammo for getting the functionality you want until INPUT is fixed.

As an aside; I suspect you know, but the syntax of your INPUT is not quite as per the help page, though it is being tolerated - and correcting it doesn't make any difference to your issue.

I think...

INPUT({{AA,[0]}},"AA","AA","AA",-1,-1);

should look more like this:

INPUT({{AA,[0]}},"AA",{"AA"},{"AA"},{-1},{-1});

Regards

Steve

Tags (1)
9 REPLIES 9
Level 1
5 3 1 0
Message 2 of 10
Flag Post
HP Recommended

I've not tested the precise INPUT scenario you mention, but you may want to try extending the types that are accepted. You're accepting just real numbers i.e. [0]. Changing this to include integers as well (i.e. [0,1], or [-1] to accept anything) may get past the validation issue. This obviously doesn't help with the underlying problem you highlight.

Level 1
8 6 0 0
Message 3 of 10
Flag Post
HP Recommended

No this did not help.  I also run into another problem with the input form that has become an even more serious issue for me. My project has not grown to over 2000 lines of code with several input forms that depend on pre-calculated default values. There is a problem with negative numbers. When I enter them by hand, this works fine. They appear naturally with the "-" sign that one gets when using the +/- key (it's smaller and above the middle). The pre-calculated reset values, however, appear in the form (after pressing SHIFT-ESC) "-xxx", with the "-" sign that one gets when typing e.g. 3-2. This crashes the program as the INPUT forms don't except this input. Is there a fix or a clever workaround? [I really hope ...].

Thanks and all the best,

Thomas

Level 1
8 6 0 0
Message 4 of 10
Flag Post
HP Recommended

I narrowed the problem down. Here is a sample code that highlights the issue. (In fact it does not seem to be related to function calls as I previously thought.) The first INPUT when filled using reset (SHIFT ESC) imports the -1 as a string, the PRINT command shows 2*-1. The second works correctly and gives -2. The issue seems to only occur on the HP Prime itself, the emulator works correctly, yielding -2 for both INPUT commands.  Does anyone have a solution? (I need the {,[],,} structure, because there are several inputs on my form.)

EXPORT TST()

BEGIN

LOCAL AA,BB;

INPUT({{AA,[0]}},"AA","AA","AA",-1,-1);

PRINT(); PRINT(2*AA); WAIT;

INPUT(BB,"BB","BB","BB",-1,-1);

PRINT(2*BB); WAIT;

END;

Level 1
5 3 1 0
Message 5 of 10
Flag Post
HP Recommended

Hi Thomas,

Here you go, give this a try...

INPUT( {{AA,[2]}}, "AA", "AA", "AA", -1, -2 );     //<--- change [0] to [2]

AA:=EXPR(STRING(AA));       // Add this line per variable

PRINT(2*AA); WAIT;

INPUT(BB,"BB","BB","BB",-2,-3);

BB:=EXPR(STRING(BB));      // Add this line per variable

PRINT(2*BB); WAIT;

This will get around the inconsistency of the Del and Clear actions, but it requires moving to string type for the fields. INPUT returns different types in the various cases you've highlighted - returning a mix of real (0), string (2) and function (8.) (You can check this yourself using TYPE(AA) for example. The Del function is is the oddest, in that it only passes validation if [-1] is used in the allowed_types_matrix. It fails validation if [2] (string) is used even though a string gets returned (and even supplying all non-CAS types [0,1,2,3,4,5,6,8,9]!) It also doesn't appear to make any difference whether a '-' ASC(45) or '+/-' ASC(8722) is supplied to INPUT as the initial value or reset value - regardless it seems to always be treated as a string.

Changing the types matrix from [0] to [2] and adding var:=EXPR(STRING(var)); after each INPUT ensures that where a number - including any of the minus signs ('-' or '+/-' key) - is entered, a number is available from INPUT. You can pull this out into a function and potentially roll up validation into it as well.

Anyway, the above may give you a little ammo for getting the functionality you want until INPUT is fixed.

As an aside; I suspect you know, but the syntax of your INPUT is not quite as per the help page, though it is being tolerated - and correcting it doesn't make any difference to your issue.

I think...

INPUT({{AA,[0]}},"AA","AA","AA",-1,-1);

should look more like this:

INPUT({{AA,[0]}},"AA",{"AA"},{"AA"},{-1},{-1});

Regards

Steve

Tags (1)
Level 1
8 6 0 0
Message 6 of 10
Flag Post
HP Recommended

Thanks! I'll do it this way until HP fixes INPUT. (With the extra little effort of input value validation.)P

Level 1
8 6 0 0
Message 7 of 10
Flag Post
HP Recommended

This does not work. If I check the TYPE of

AA:=EXPR(STRING(AA));

it's 2, it's a string. It cannot do the arithmetic "*" in the next step.

Level 1
5 3 1 0
Message 8 of 10
Flag Post
HP Recommended

Hi Thomas,

Apologies, I had it working, then simplified it but retested the original, working, version, not the simplified version.

Add this function above the function containing INPUT (or forward declare it and put it after):

InFix(var)

BEGIN

RETURN EXPR(IFTE(TYPE(var)==2, EXPR(STRING(var)), STRING(var)));

END;

And replace...

AA:=EXPR(STRING(AA));

...with a call to the function...

AA:=InFix(AA);

(and same for BB.)

Steve

Level 1
8 6 0 0
Message 9 of 10
Flag Post
HP Recommended

Thanks Steve,

I give this a try.

Best,

Thomas

Level 3
73 71 1 6
Message 10 of 10
Flag Post
HP Recommended