Threaded Mode | Linear Mode

brickviking · 09-01-2017, 10:34 AM

I've got some questions that are particularly new-user style questions, so please bear with me as this is the first time I've really dug in deeper to RPL programming. It may help if you've got a little experience with the Casio fx-9860GII (or 9750GII) but it's not needed.

Introduction
I'm the author of a Casio grocery program (link) on the Casio FX-9750GII and I'm trying to convert it into RPL on the HP-50G.

Funnily enough, the bit I thought was going to be the hardest, was actually the easiest; duplicating (roughly) the Casio screen below as a graphical screen on the 50G. I managed to create a routine for creating the PICT I need, though I should probably leave the bottom 8 pixels free to set up a menu.

[Image: XERSlwk.png]

This screen (taken from the Casio) describes the pieces I want to present:

[Image: BaT5wRo.png]

Q1. Multiple var initialisation
I want to do a wholesale initialisation of variables, but so far all I've been able to come up with is the usual (for me):

\<< 0 'VEGE' STO 0 'MEAT' STO 0 'MISC' STO ... \>>

Now I'm jolly sure there's a far more efficient way of doing multiple variable assignment. Have I missed something in the UM/UG? I even had a look in the AUR, and didn't see what I wanted there either. Basically I want to either set all the categories to zero on initial start (and set the tax to a set rate), or set all the categories from previously stored data (ditto tax).

Q2. Running with a graphical screen and menu (i.e. no stack display)
This is trickier for me, as I had to use a loop and GetKey() on Casio, making the calculator cycle constantly through the loop and hence use more battery. The reason is because Casio's GetKey() returns immediately, regardless of whether a key was pressed or not. I'm looking for a better option on HP-50g, where I can display the graphical screen above, plus a menu, and then the calculator waits (without spinning its wheels like crazy) until I press a menu key. Each menu key fires up a sub-program to request a value from the user, set the relevant variable, then pass back to the main program, which updates the displayed variables, shows a grand total, and waits until I press a menu key (or Exit).

Q2a. Can I display INPUT on top of a graphics screen?
This would be the least visually disturbing, as otherwise I'd be jumping between a cleared out text screen requester, then back to the graphics screen, then a cleared out text screen requester, etc. Yuck. Still, if I have to do it that way, I have to do it that way.

Q3. Speed of GUI vs text
Can I run a graphical interface at nearly the same speed as a stack-based text interface? So far, to write onto the graphics screen, I do PICT RCL, create a tiny GROB with changed data, and use GOR at a specific location, save the PICT back and display it again ({} PVIEW). I can't think of a faster way to do this, and I'm sure it'll be slow. One other thing I haven't yet worked out (though this should be easy) is how to blank-out then write figures anew on the PICT.

Conclusion, at least for now
I think I can probably do most of the other functionality I think I need, it's just tying it all together that may be the issue, at least for RPL. I was thinking the main control could be a DO ...(run main loop) UNTIL (some-end-condition) END but I'll get that done once I've got most of the subprograms written.

If y'all need further explanations (i.e. more detailed workflow for the program), shout out here and I'll see what I can do. I wrote the initial Casio program after all Smile

.

(Post 71)

Gilles59 · (This post was last modified: 09-03-2017 10:25 PM by Gilles59.)

(09-01-2017 10:34 AM)brickviking Wrote: Q1. Multiple var initialisation
I want to do a wholesale initialisation of variables, but so far all I've been able to come up with is the usual (for me):

\<< 0 'VEGE' STO 0 'MEAT' STO 0 'MISC' STO ... \>>

Hi,

0 {'VEGE' 'MEAT' MISC' } STO

See parallel processing in the AUR

Quote:Q2. Running with a graphical screen and menu (i.e. no stack display)
This is trickier for me, as I had to use a loop and GetKey() on Casio, making the calculator cycle constantly through the loop and hence use more battery. The reason is because Casio's GetKey() returns immediately, regardless of whether a key was pressed or not. I'm looking for a better option on HP-50g,

0. WAIT

Quote:[size=medium]Q3. Speed of GUI vs text
Can I run a graphical interface at nearly the same speed as a stack-based text interface? So far, to write onto the graphics screen, I do PICT RCL, create a tiny GROB with changed data, and use GOR at a specific location, save the PICT back and display it again ({} PVIEW). I can't think of a faster way to do this, and I'm sure it'll be slow. One other thing I haven't yet worked out (though this should be easy) is how to blank-out then write figures anew on the PICT.

Why did you " save the PICT back and display it again ({} PVIEW). " ?
There is no need for PICT RCL etc.
You can write directly on the screen like this :

«
{#0 #0 } PVIEW
PICT {#10 #10} "HELLO!!" 1. ->GROB REPL
3 FREEZE
»

Imho I dont think that using graphic is the best way to do what you want. Take a look at INFORM, CHOOSE, INPUT etc. (see AUR 1-37 ...)

To write program in user RPL for the 50g, I use HPUserEdit with Emu48. It's very efficient.

brickviking · 09-03-2017, 11:20 PM

(09-03-2017 08:01 PM)Gilles59 Wrote:
(09-01-2017 10:34 AM)brickviking Wrote: Q1. Multiple var initialisation
I want to do a wholesale initialisation of variables, but so far all I've been able to come up with is the usual (for me):

\<< 0 'VEGE' STO 0 'MEAT' STO 0 'MISC' STO ... \>>

0 {'VEGE' 'MEAT' MISC' } STO

See parallel processing in the AUR

[/quote]

Now that's neat. I hadn't realised that was even there, I'm still working through bits of the AUR, and it's where I found out about WAIT and FREEZE.

(09-01-2017 10:34 AM)brickviking Wrote: to write onto the graphics screen, I do PICT RCL, create a tiny GROB with changed data, and use GOR at a specific location, save the PICT back and display it again ({} PVIEW).

(09-03-2017 08:01 PM)Gilles59 Wrote: Why did you " save the PICT back and display it again ({} PVIEW). " ?

Partly due to inexperience, I'm still new to programming in RPL. In my experience, once something's stored to a variable (for safety), it's normally removed from the stack, hence the RCL. I also thought that PVIEW showed the stored contents of the PICT variable, not the "in-progress" version that hasn't been saved yet.

(09-03-2017 08:01 PM)Gilles59 Wrote: There is no need for PICT RCL etc.
You can write directly on the screen like this :

«
{#0 #0 } PVIEW
PICT {#10 #10} "HELLO!!" 1. →GROB REPL
3 FREEZE
»

I didn't know about REPL when I was looking at GROB stuff, it's probably another section of the AUR to look at.

(09-03-2017 08:01 PM)Gilles59 Wrote: Imho I dont think that using graphic is the best way to do what you want. Take a look at INFORM, CHOOSE, INPUT etc.

I looked at those, and I would be using those for inputting of prices. I wanted to have those displayed over the top of the running grocery screen, but I haven't been able to do that on the HP or the Casio.

The whole idea of this grocery program (at least for me) is to show a running total of categories as I go. In effect, I request a category (Veges, Meat, Misc, etc), ask the user what they paid for that item, then add it to the running total.

Rough flow goes like this (user presses <btn>, program functions are [cmd]):

Code:

...

[Display PICT with updated totals]

[Menu]  (waits for a F1-F6 keypress)

     <F1>  (Vege category)

[display count requester]

     <1.49>   (i.e. 1.49 kg)

[display price per unit requester]

     <3.99>

[multiply the two together, add to VEGE total]

[Display PICT with updated totals]

[Menu]

     <F2>  (meat category)

[display price per unit requester]

     <6.99>

[add to MEAT total]

[Display PICT with updated totals]

[Menu]

...
and so on.

(Post 73)

DavidM · 09-04-2017, 04:32 PM

(09-01-2017 10:34 AM)brickviking Wrote: Q2. Running with a graphical screen and menu (i.e. no stack display)

You can do this, and in some ways this may actually be simpler than what you're thinking. The 50g already knows how to wait for the user to press a menu key, and it does that essentially with the processor turned off (even when the power is on and the display is active). So power drain is minimized if you simply leave it in an idle state waiting for the next user action to take place. If you alter your approach to a slightly different model, you may find that it's easier to achieve what you're wanting to do.

Specifically, instead of thinking of this as one big application with a "loop until done" structure, think of it as a collection of apps (one for each menu key) that all perform their function and then end by updating the display (and a final FREEZE to keep that part of the screen fixed). You'd probably want to put the code for that in a separate program that each menu program calls at the end.

(09-01-2017 10:34 AM)brickviking Wrote: Q2a. Can I display INPUT on top of a graphics screen?

No, INPUT doesn't allow that. It takes over the entire display, as does INFORM. CHOOSE and MSGBOX put their contents in a "box" on top of whatever was already in the display, but off the top of my head I can't think of any other UserRPL commands that work that way.

(09-01-2017 10:34 AM)brickviking Wrote: Q3. Speed of GUI vs text
Can I run a graphical interface at nearly the same speed as a stack-based text interface? So far, to write onto the graphics screen, I do PICT RCL, create a tiny GROB with changed data, and use GOR at a specific location, save the PICT back and display it again ({} PVIEW). I can't think of a faster way to do this, and I'm sure it'll be slow. One other thing I haven't yet worked out (though this should be easy) is how to blank-out then write figures anew on the PICT.

It may depend on how complex and lengthy your drawing routines end up being. As Gilles has mentioned, REPL is probably a better approach than GOR. Also, I think {} PVIEW is a special case that actually stops your program's execution -- it's probably better to use {#0 #0} PVIEW and FREEZE as needed so that you can still execute code after the display has been updated.

I hope you persevere and follow through with this. You'll end up learning a lot about the system (and RPL in general) by the time you finish it, regardless of what approach you use. Please continue to share your progress!

DavidM · 09-04-2017, 06:37 PM

Here's a "proof of concept" of the approach I described above. It's a directory containing several separate programs, and you start the app by executing "GOBV".

The first time it runs, it creates a GROB for the display. Subsequent runs will use the existing one that gets stored in the directory.

The menu keys simply cause a random number to be displayed beside the appropriate category in the list.

I'm not suggesting that this is necessarily the best approach, but I thought an example would be better than me simply describing it.

Code:

DIR

GOBV

\<<

  2 FIX

  IFERR 'BVDISP' RCL THEN DROP NEWDISP END

  PICT STO

  {

    { "Vege" Vege }

    { "Meat" Meat }

    { "Misc" Misc }

    { "Dairy" Dairy }

    { "Clean" Clean }

    { "EXIT" ExitApp }

  } TMENU

  REFDISP

\>>

NEWDISP

\<<

  ERASE

  { #82d #0 } { #82d #72d } LINE

  { #0 #7d } { #82d #7d } LINE

  { #0 #47d } { #82d #47d } LINE

  { #82d #39d } { #131d #39d } LINE

  PICT { #0 #0 } "Last" 1 \->GROB REPL

  PICT { #30d #0 } 0 RJnum REPL

  PICT { #0 #9d } "Veges" 1 \->GROB REPL

  PICT { #0 #17d } "Meat" 1 \->GROB REPL

  PICT { #0 #25d } "Misc" 1 \->GROB REPL

  PICT { #0 #33d } "Dairy" 1 \->GROB REPL

  PICT { #0 #41d } "Clean" 1 \->GROB REPL

  PICT { #0 #50d } "Grand Total" 1 \->GROB REPL

  PICT { #30d #58d } 0 RJnum REPL

  PICT { #85d #0 } "P" 1 \->GROB REPL

  PICT { #85d #8d } "Q" 1 \->GROB REPL

  PICT { #85d #16d } "R" 1 \->GROB REPL

  PICT { #85d #24d } "S" 1 \->GROB REPL

  PICT { #85d #32d } "T" 1 \->GROB REPL

  PICT { #85d #41d } "I% 15.00" 1 \->GROB REPL

  PICT { #85d #49d } "Tax 0.00" 1 \->GROB REPL

  PICT RCL DUP 'BVDISP' STO

\>>

REFDISP

\<<

  {#0 #0} PVIEW 3 FREEZE

  PICT RCL 'BVDISP' STO

\>>

Vege

\<<

  PICT { #30d #9d } RAND 25 * 2 RND RJnum REPL

  REFDISP

\>>

Meat

\<<

  PICT { #30d #17d } RAND 50 * 2 RND RJnum REPL

  REFDISP

\>>

Misc

\<<

  PICT { #30d #25d } RAND 200 * 2 RND RJnum REPL

  REFDISP

\>>

Dairy

\<<

  PICT { #30d #33d } RAND 10 * 2 RND RJnum REPL

  REFDISP

\>>

Clean

\<<

  PICT { #30d #41d } RAND 30 * 2 RND RJnum REPL

  REFDISP

\>>

RJnum

\<<

  #50d #6d BLANK

  SWAP \->STR 1 \->GROB DUP SIZE DROP

  #50d SWAP - #0 2 \->LIST SWAP REPL

\>>

ExitApp

\<<

  2 MENU

\>>

END

brickviking · 09-07-2017, 08:57 PM

That collection of applications is almost exactly what I'd thought of, I realised I could probably call up "Vege" "Meat" etc as separate little input programs early on. What I didn't know how to do is to input values without "leaving" that graphic screen, however I think that's a bit beyond what I'm capable of at the moment. Your idea of using REPL instead is definitely much better than GOR, I just happened to use GOR because it's the first function I actually found.

Your programs will definitely give me a leg up, but what I'm missing now is a way to provide an input to the vars VEGE, MEAT, etc.

My INIT looks a bit like this now:

Code:

\<< 0. { TOTAL SUBTOT VCNT VCOST MEAT MISC DAIRY CLEAN TAXRT TAXTOT

LASTVAL TMP1 TMP2 TMP3 TMP4 TMP5 } STO

\>>

That's now looking pretty simple with a dramatic reduction of whitespace, so thanks for that. And in addition, my GRCBTN program will get some rework to convert all the GOR over to REPL, that may speed things up a little.

I'll let you lot know what else I do.

(Post 75)

DavidM · 09-09-2017, 01:50 PM

(09-07-2017 08:57 PM)brickviking Wrote: ...What I didn't know how to do is to input values without "leaving" that graphic screen, however I think that's a bit beyond what I'm capable of at the moment.

I don't know of a way to do that with INPUT, PROMPT, or INFORM. Perhaps someone else knows of a way, but as far as I can see all of those will "take over" the display when activated. It's possible that a way could be crafted with SysRPL/Saturn code, but if you were to go that route, you'd probably be better off re-working the whole thing into a POL-based app (Parameterized Outer Loop) or more likely a form-based approach (a more versatile version of the INFORM command).

(09-07-2017 08:57 PM)brickviking Wrote: ...what I'm missing now is a way to provide an input to the vars VEGE, MEAT, etc.

Honestly, I think your best bet for now is to simply use something like INPUT for that. The display will be reset to show the prompt that you supply, but you can then re-display PICT after the input has been processed. It may not be as clean as you had originally hoped, but it should work.

(09-07-2017 08:57 PM)brickviking Wrote: I'll let you lot know what else I do.

Please do!

brickviking · 09-09-2017, 10:27 PM

(09-09-2017 01:50 PM)DavidM Wrote:
(09-07-2017 08:57 PM)brickviking Wrote: ...what I'm missing now is a way to provide an input to the vars VEGE, MEAT, etc.

Honestly, I think your best bet for now is to simply use something like INPUT for that. The display will be reset to show the prompt that you supply, but you can then re-display PICT after the input has been processed. It may not be as clean as you had originally hoped, but it should work.

Yeah, I had to do that with the original Casio environment as well. I used the framework and words as the background (i.e. stuff that won't change), and just wrote extra bits into the screen when I updated the totals. I found I had to do that simply for speed's sake, and it looks like I'll need to repeat the same here.

(Post 77)