Conversion from CASIO-basic to RPL

[DavidM]

(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!