Post Reply 
Programmatically changing Entry mode crashes iOS Pro App
05-04-2020, 10:05 AM
Post: #1
Programmatically changing Entry mode crashes iOS Pro App
Hi,
I created the following function to automatically switch between Textbook and RPN modes:
Code:

KEY K_Menu()
BEGIN
 LOCAL s := {"Textbook", "Algebraic", "RPN"};
 Entry := ABS(Entry-2);
 TEXTOUT_P(s(Entry+1), 15, 9, 1, RGB(255,180,80));
 WAIT(1);
END;

It works fine on my physical HP Prime, but on the iOS App it crashes every 2 switches.
Am I doing something wrong?

Thanks,
Thibault

PS: yes I know, in case of algebraic mode it stays in this mode, but I never use it.
Find all posts by this user
Quote this message in a reply
05-27-2020, 12:33 AM
Post: #2
RE: Programmatically changing Entry mode crashes iOS Pro App
Well I finally succeeded in crashing the HW Prime with this code assigned to a user key.
Does someone see what I’m doing wrong?

Thanks
Find all posts by this user
Quote this message in a reply
05-27-2020, 12:53 AM
Post: #3
RE: Programmatically changing Entry mode crashes iOS Pro App
I've no idea at all what the problem is, but I recalled that this is one of the first programs I found useful on the Prime, back in 2014:

https://www.hpmuseum.org/forum/thread-801.html

Although slightly different, the program there may offer insights as to why this isn't working.

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
05-27-2020, 07:11 AM
Post: #4
RE: Programmatically changing Entry mode crashes iOS Pro App
Hello,

Well, it took me a couple of hours to chase that one up, but I found the problem!

The geist of it is that, when you do a mode change, the graphical control gets changed from (for example) the RPN stack to the algebraic stack.
So, the system deletes the RPN stack and creates an algebraic stack...
Up to here, no problem...

HOWEVER,
your user key program returns 1. Which, had you read the documentation (I know that I documented it somewhere, but do not ask me where!!!!) means that the system is expected to execute key "1" (symb)....

The problem is that it would send the execution of said key 1 to the now defunct/deleted stack. -> crash!

So, I have added some code to avoid the crash in the future... BUT you can also fix things on your side by adding a return -1 at the end of your program.

Hope this helps...
Cyrille

Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP.
Find all posts by this user
Quote this message in a reply
05-27-2020, 08:39 AM
Post: #5
RE: Programmatically changing Entry mode crashes iOS Pro App
(05-27-2020 07:11 AM)cyrille de brébisson Wrote:  Hello,

Well, it took me a couple of hours to chase that one up, but I found the problem!

The geist of it is that, when you do a mode change, the graphical control gets changed from (for example) the RPN stack to the algebraic stack.
So, the system deletes the RPN stack and creates an algebraic stack...
Up to here, no problem...

HOWEVER,
your user key program returns 1. Which, had you read the documentation (I know that I documented it somewhere, but do not ask me where!!!!) means that the system is expected to execute key "1" (symb)....

The problem is that it would send the execution of said key 1 to the now defunct/deleted stack. -> crash!

So, I have added some code to avoid the crash in the future... BUT you can also fix things on your side by adding a return -1 at the end of your program.

Hope this helps...
Cyrille

Thank you Cyrille, lots of helpful answers.
I turned around the RETURN -1 without finding it in the documentation, and indeed my code generates erratic behavior because of random return values.
I also understood that there was a loss of coherence when changing the view, but there again, without finding the solution. In event oriented programming I should have sent a “redraw” message to the window manager.
Find all posts by this user
Quote this message in a reply
05-28-2020, 05:59 AM
Post: #6
RE: Programmatically changing Entry mode crashes iOS Pro App
Hello,

User keys can return 3 things:
1) a string. In this case, this string will be treated as a "textEvent", which, in most cases means that it gets sent to the command line.
2) a number between 0 and 51*4(?). This number is treated as a keycode which gets executed if possible.
3) -1. In this case nothing else happends...

Now, the problem is that, in the case of string or number, the message gets sent to the window/control that received the original message.
BUT, if your code causes a view change (setview or, in your case a switch of entry mode), said window/control is destroyed before the 2nd action is executed. So the message goes nowhere... Causing the issue.

Cyrille

Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP.
Find all posts by this user
Quote this message in a reply
05-28-2020, 10:42 AM (This post was last modified: 05-28-2020 10:43 AM by pinkman.)
Post: #7
RE: Programmatically changing Entry mode crashes iOS Pro App
Thanks Cyrille.
Yes I had this in mind. I did not know the RETURN -1 option, my code tried to return nothing, but this does not really exist in HPPL.

The issue is clear for me:
- changing view drives to lose what I would call the calling context: it is not a bug,
- not handling such cases when returning from a program: this is the bug.

Now I’m wondering why the crash occurred randomly...
Find all posts by this user
Quote this message in a reply
Yesterday, 05:12 AM
Post: #8
RE: Programmatically changing Entry mode crashes iOS Pro App
Hello,

Yes, in PPL, there is no "no return" function. They all return the latest expression's result. If the function is empty, it returns a 0.

>not handling such cases when returning from a program: this is the bug
Yep, and I am fixing it... But you can "avoid" the bug by returning a -1, which would solve the problem in the meantime.

>Now I’m wondering why the crash occurred randomly...
Here was the code (I have changed it since):
Here we are in a member function of the Window object.
if(!DoUserKeys(m, handled)) return true; // If the key is a user function and fully handled, return. If NOT fully handled, it will have modified the message (m)
return KeyEvent(&m->KeyEvent); // This is a virtual function call to KeyEvent

In our case, DoUserKeys would do a view change, which was deleting 'this', ie: the current window, ie: the object which member function we are executing.
now, of course a memeory free does not mean that the data in the memory is wipped out, just "released"... the memory location can be overridend imediately, or much later...
The call to KeyEvent, in most case would execute nothing. But would still do a virtual function call, which meant that it would read the memory at the start of the window class instance to get the class pointer, and then read the address of the, potentially, overriden KeyEvent virtual function to "jump" there.
Now, if the begining of the now deleted window object memory are was NOT overiden (which seemed to happen most times), then the call would succeed, and do nothing, which is not a big issue...
BUT, if that memory area was overriden between the time of deletion and the time when the call to KeyEvent was executed, then the CPU would jump God knows where, and it would crash.

As you can imagine, things are kind of random ad the call to DoUserKeys is quite complex, executing a PPL user program, doing a view switch and everything! Hence the randomness!

Hope that helps!
Cyrille

Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP.
Find all posts by this user
Quote this message in a reply
Yesterday, 03:43 PM
Post: #9
RE: Programmatically changing Entry mode crashes iOS Pro App
It helps, thanks for the details.
I guess that, running at iPhone X speed, chances that the memory will be overridden are greater on the iOS app than on my (good old) G1.

You said you correct it, could tell us how? I’m just curious...
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)