issue when cancelling INPUT

[primer]

Hello,
I saw complex usage of INPUT command in this forum, but I have an issue with a quite simple INPUT usage, I'm surprised nobody reported it already. (I searched but I may missed)

I simply try to cancel an INPUT with the cancel soft key (or by pressing ON key, result is the same btw)

I made the INPUT as simple as possible, one argument.
I usually cover all cases (like cancelling), then I started to check INPUT return as stated in builtin help (it's supposed to return 0 on cancellation).

Here is the program :

And here is what's happend when canceled :


Please can you check if your behave like mine ?

Code:

EXPORT failure()
BEGIN
LOCAL A;
IF INPUT(A)==0 THEN KILL; END; // canceled
PRINT(A);
END;

Firmware 8151,
I tested with EXPORTed var, without the KILL, in every case it behave like this, is it a bug ?

Thank you,
Best Regards.

[Helge Gabert]

With odd characters appearing, you could have a memory corruption issue. You might want to do a hard (paperclip) reset, and reformat.

Anyway, my program runs fine, but I only use lower case variables as local variables in my programs, because single, upper case, letters are reserved for global reals.

EXPORT FAILURE()
BEGIN
LOCAL a;
INPUT(a);
IF a==0 THEN
KILL;
END;
RETURN a;
END;

Does this work for you?

[StephenG1CMZ]

On the Android version I just see <name of program> Program Interrupted.

[primer]

(09-28-2015 10:23 PM)Helge Gabert Wrote:  With odd characters appearing, you could have a memory corruption issue. You might want to do a hard (paperclip) reset, and reformat.

I already paperclip on real prime. But now I perform test on virtual, I reseted it too. Is it possible that both have memory corruption ?

(09-28-2015 10:23 PM)Helge Gabert Wrote:  because single, upper case, letters are reserved for global reals.

yes I know, it's reserved, but :
First : being reserved does not mean you are not allowed to use it on program without a crash,
Second : I'm not using the reserved variaible because I declared locally a variable. It's a different variable.

Nevertheless, I did perform all tests I could : "LOCAL a" , "EXPORT a", "LOCAL ABC", "EXPORT ABC", also using reserved var (without "LOCAL A")... in every case it fails when cancelled.

(09-28-2015 10:23 PM)Helge Gabert Wrote:  Does this work for you?

no.
I mean, program *does* work, but when you cancel INPUT in this program, it behaves wrongly.

Btw, sorry but I think you misuse the input check in your program, you are not checking user cancellation with your :
INPUT(a);
IF a==0 THEN
You are only checking "does user filled 0 ?", which is not the same... as checking cancellation.
In builtin-help, it's written : "If user press cancel menu key, var is not updated and 0 is returned", did you read it ?


Regards

[Tyann]

Bonjour

Je viens de tester vôtre code, sur ma machine cela fonctionne bien.
Les signes bizarres apparaîssent lorsque le KILL est exécuté.
Essayez ceci:

Code:


EXPORT TEST()
LOCAL A;
E:=INPUT(A):
PRINT (E);
END;

Si vous selectionner ok
E vaut 1
Si vous selectionner Annule
E vaut 0

Hello

I just tested your code on my machine at IT Works well .
The bizarre signs appear When the KILL is executed.
Try this:

Code:


EXPORT TEST()
LOCAL A;
E:=INPUT(A):
PRINT (E);
END;

If you select ok
E is 1
If you select Cancel
E is 0

[Didier Lachieze]

(09-29-2015 10:54 AM)Tyann Wrote:  The bizarre signs appear When the KILL is executed.

Yes, it's not linked to the INPUT but to the KILL instruction, for example with the following code Cancel works fine and returns 0, but OK returns the Chinese characters as it executes KILL:

Code:

EXPORT failure()
BEGIN
LOCAL A;
IF INPUT(A)==0 THEN RETURN; END; // canceled
PRINT(A);
KILL;
END;

[Tim Wessman]

In testing only with emu, I have been unable to see this at all with any version of the programs posted.

Has anyone other then the OP seen this yet? (either hw/emu or both)

[Didier Lachieze]

(09-29-2015 02:33 PM)Tim Wessman Wrote:  In testing only with emu, I have been unable to see this at all with any version of the programs posted.

Has anyone other then the OP seen this yet? (either hw/emu or both)

Yes, with the program I posted just above, here is what I get:

   

first line returning 0 is with [Cancel]
second line returning Chinese characters is with an input value of 5 followed by [OK]

[Tim Wessman]

Hello,

I've figured it out. What you are actually seeing is the Chinese translation for "Program Interrupted" that is accidentally in the french strings!

[Helge Gabert]

I do not get any weird characters with this program (running KILL :

   

Regardless whether or not I press OK, Cancel, or input 0 or something else

   

But Tim figured it out - - a language problem!

[primer]

(09-29-2015 04:14 PM)Helge Gabert Wrote:  But Tim figured it out - - a language problem!

That's nice the issue is identified, thank you. hopefully is was only a language issue.

Then I discover that KILL does leave a message "program interrupted",
I was expecting it behave like good old exit() from C, without a message.
Is it possible to exit silently ? (by using an argument to KILL maybe)
Do you know if it's possible ?
RETURN is not a great solution, as it only ends current function.
Thank you.
Regards

[Helge Gabert]

KILL doesn't seem to accept any arguments, otherwise you could pass " ". Maybe someone else knows?

[Tim Wessman]

(09-29-2015 07:30 PM)primer Wrote:  Then I discover that KILL does leave a message "program interrupted",
I was expecting it behave like good old exit() from C, without a message.

Ah, but it isn't actually returning a message. Rather, it is returning an error object which is going to display (nicely) with text. :-)

You can use an error trap to catch an interruption if you'd like. Look at the IFERR error catching stuff.

[Tyann]

Bonjour

Il manque une instruction STOP qui met fin au programme
n'importe où sans erreur.


Hello

It lacks a STOP statement which terminates the program
anywhere without error.

[primer]

(09-29-2015 10:23 PM)Tim Wessman Wrote:  You can use an error trap to catch an interruption if you'd like. Look at the IFERR error catching stuff.

Indeed, but if you have to catch the error to avoid the error message, you are not stopping anymore your program...

Code:


IFERR
IF INPUT(var)==0 THEN KILL; END;
THEN
// you catched the error, well and now how can I stop the program ?
END;
// program continues here

Tyann suggestion would be nice for me, something to nicely end programs, like exit(); from C/C++.

[Tim Wessman]

One of the primary issues here is that *every* function needs to return something. If you don't return anything, the last command or argument left on the runtime stack will be returned. There really isn't the concept of a void function in PPL...

[eried]

(09-29-2015 07:30 PM)primer Wrote:  

(09-29-2015 04:14 PM)Helge Gabert Wrote:  But Tim figured it out - - a language problem!

That's nice the issue is identified, thank you. hopefully is was only a language issue.

Then I discover that KILL does leave a message "program interrupted",
I was expecting it behave like good old exit() from C, without a message.
Is it possible to exit silently ? (by using an argument to KILL maybe)
Do you know if it's possible ?
RETURN is not a great solution, as it only ends current function.
Thank you.
Regards

In which case do you need the EXIT? Could you make a program that follows a sequence that exits naturally?

As an example, with BASIC you could redirect your program execution pointer using GOTO, but this is completely avoidable using proper sequences.

[primer]

(09-30-2015 01:56 PM)Tim Wessman Wrote:  ... There really isn't the concept of a void function in PPL...

Ok I understand. life is life.

Btw, because it's treated as "error", your KILL command is closer from an exception than of a classic exit mechanism.

(09-30-2015 03:01 PM)eried Wrote:  As an example, with BASIC you could redirect your program execution pointer using GOTO, but this is completely avoidable using proper sequences.

Indeed basic from 80's abused the evil GOTO, I was here, but it makes more than 30 years normal people avoid it.
But it's nothing compared to exit() or throwing/catching an exception, theses are perfectly legit.

"30 years" of computering... wow, I'm geting old

Thank all of you for your remarks and advices.
Best Regards.