Post Reply 
How to handle "On" key - & - Safe file storage
10-25-2017, 03:58 AM
Post: #1
How to handle "On" key - & - Safe file storage
It appears the HP Prime's "On" key always interrupts a program and there's no way to handle this situation with WAIT(-1), or other methods that I've tried. I can see potentially why this might be a good thing, but for me the "On" key was always the same as "Cancel" (50g), while there's an "Esc" key on the Prime. Question, is it a matter of re-training myself not to use "On" for the purpose of "Cancel"/"Esc" or is there a way someone has found to handle this key press?

This started giving me grief because I was using a method to save a list of variable values to AFiles on EXIT of an app, then restoring on start-up, but the synchronize is broken if the program is interrupted. The reason I saved to AFiles in the first place was because an "update" to the app's program clears the variables (global variables) and I need a reliable way to save data associated with an app, regardless if the app is updated over time. For that matter, a method to save files to a safe area would be fantastic. Maybe HVars is intended for this? App variables do make a lot of sense, however unreliable as they are very vulnerable to total loss when an app is "updated".

AFilesB is handy, is there a HVars equivalent?
Visit this user's website Find all posts by this user
Quote this message in a reply
10-25-2017, 05:40 AM
Post: #2
RE: How to handle "On" key - & - Safe file storage
Have you looked at the on calculator help for HVars to see if it'll do what you want?
Find all posts by this user
Quote this message in a reply
10-25-2017, 06:39 PM
Post: #3
RE: How to handle "On" key - & - Safe file storage
After looking further into HVars it appears that it may be a better way to store user variables than in AFiles (or AVars for that matter).

AFiles still seems like the best (only?) way to import/export data to/from an app, it's just user-beware that should you update at some point to a new version, those files are bye-bye. I suppose some utilities could be developed to backup and restore around such a procedure. I'm thinking of all these things from the perspective of a third-party app developer, being able to provide a reliable experience to an end user of an app which could get regular updates. The update procedure of any application (calculator, PC, mobile device) should not destroy user data and I'm simply trying to find the most reliable method of ensuring that I can meet that expectation. The HP Prime does things a lot differently in relation to user (or program) created variables than what I might consider intuitive, especially when involving the Connectivity Kit.

Other options:
- Maybe the Connectivity Kit could be improved to allow the user to simply overwrite the *.hpappprgrm and not the rest of the data associated with an app.
- If the above were done ,possibly AVars could be used instead of HVars.
Visit this user's website Find all posts by this user
Quote this message in a reply
10-25-2017, 06:50 PM
Post: #4
RE: How to handle "On" key - & - Safe file storage
You are correct in that the applications are treated as a unit. Just like any other "app" based system such as your phone, delting/removing/uninstalling/replacing an app does remove the data.

There is currently not a way to just "store to a file" outside of an app. This is something I'll have to think on more and ties in to the whole file structure/vars/user organization unfortunately which makes it trickier.


Its been a while since I've done any programming on userRPL stuff for the 50g, but I'm pretty sure the ON key works the same way there as on Prime and always will interrupt. Is this not the case?

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
10-25-2017, 07:14 PM
Post: #5
RE: How to handle "On" key - & - Safe file storage
(10-25-2017 06:50 PM)Tim Wessman Wrote:  Its been a while since I've done any programming on userRPL stuff for the 50g, but I'm pretty sure the ON key works the same way there as on Prime and always will interrupt. Is this not the case?

With SysRPL you could do this for example:
Code:

        kcOn
        ?CaseKeyDef
        ::
          TRUE
          AppExitCond!
        ;
and then handle some things afterwards.

With WAIT(-1) on the Prime, something like:
Code:
EXPORT TEST_ON()
BEGIN
  LOCAL m;
  m:=WAIT(-1);
  MSGBOX(m);
END;
will never return 46.
Visit this user's website Find all posts by this user
Quote this message in a reply
10-25-2017, 07:31 PM
Post: #6
RE: How to handle "On" key - & - Safe file storage
(10-25-2017 07:14 PM)Jacob Wall Wrote:  With SysRPL you could do this for example:

Well, yes. I was assuming only talking userRPL here.

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
10-25-2017, 09:02 PM
Post: #7
RE: How to handle "On" key - & - Safe file storage
(10-25-2017 06:50 PM)Tim Wessman Wrote:  Its been a while since I've done any programming on userRPL stuff for the 50g, but I'm pretty sure the ON key works the same way there as on Prime and always will interrupt. Is this not the case?

It always generates a system interrupt, but will not interrupt a running program if an IFERR is active. Inside an IFERR, pressing ON generates an error (ERRN = #0) and branches to the THEN clause. This lets the programmer control what happens when ON is pressed.

<0|ɸ|0>
-Joe-
Visit this user's website Find all posts by this user
Quote this message in a reply
10-25-2017, 09:33 PM
Post: #8
RE: How to handle "On" key - & - Safe file storage
(10-25-2017 09:02 PM)Joe Horn Wrote:  It always generates a system interrupt, but will not interrupt a running program if an IFERR is active. Inside an IFERR, pressing ON generates an error (ERRN = #0) and branches to the THEN clause. This lets the programmer control what happens when ON is pressed.

Ok, same happens in Prime. Pressing ON generates an error item which can be caught in an IFERR block like you reminded about. Thanks!

However, I am able to get 46 out of that sample code already... so must be something else going on?

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
10-25-2017, 09:33 PM
Post: #9
RE: How to handle "On" key - & - Safe file storage
(10-25-2017 09:02 PM)Joe Horn Wrote:  It always generates a system interrupt, but will not interrupt a running program if an IFERR is active. Inside an IFERR, pressing ON generates an error (ERRN = #0) and branches to the THEN clause. This lets the programmer control what happens when ON is pressed.

Ah, very nice! That solves it then, thanks! Can be demonstrated like this:
Code:
EXPORT TEST_ON()
BEGIN
  LOCAL m;
  IFERR m:=WAIT(-1); THEN
    m:=46;
  END;
  MSGBOX(m);
END;
Visit this user's website Find all posts by this user
Quote this message in a reply
10-25-2017, 10:34 PM
Post: #10
RE: How to handle "On" key - & - Safe file storage
(10-25-2017 09:33 PM)Tim Wessman Wrote:  However, I am able to get 46 out of that sample code already... so must be something else going on?

Really? I always get "... Program Interrupted" error message. I double-checked with physical calculator and Windows version.
Visit this user's website Find all posts by this user
Quote this message in a reply
10-26-2017, 04:56 AM
Post: #11
RE: How to handle "On" key - & - Safe file storage
(10-25-2017 10:34 PM)Jacob Wall Wrote:  
(10-25-2017 09:33 PM)Tim Wessman Wrote:  However, I am able to get 46 out of that sample code already... so must be something else going on?

Really? I always get "... Program Interrupted" error message. I double-checked with physical calculator and Windows version.

Bonjour
Votre exemple fonctionne bien pour moi sur la calculatrice.
C'est super, merci à Joe pour le renseignement.


Hello
Your example works well for me on the calculator.
That's great, thanks to Joe for the information.

Sorry for my english
Find all posts by this user
Quote this message in a reply
Post Reply 




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