HP48G soft menu toggle: How?

[johnb]

Quote:John, do you have a much simpler (less of it) program that can show how this works in practice?

Apologies for not responding sooner. I'm recuperating from hip surgery and my rising energy levels are competing with my gradually reducing pain levels. I don't have an example, but maybe I can find some time to work one up for you.

In the meantime, I'll give some guidance here and it may turn out you won't need the example program. (Easier to write English than RPL!)

Quote:Does this method rely on having other menus already created?

No. My example sort of does because it's part of a whole suite of programs that let me shift between menus for 16c-type programmer operations and 2-3 other things: an interval arithmetic mode, some quick shortcuts for display mode (just press all|fix|sci|eng and it remembers the last precision you had set), and (I forget) maybe one other group of things.

The only gripe I have about RPL is that it's hard to read -- even your own code (after a while).

My example contains its own menu. That first list in {} is the menu; you could strip out everything but hex/dec/oct/bin for an example. It's just the raw menu without any block indicators.

Those sub-lists within it are each a label and a program. So, if you press the button labeled "Hex" it runs « HEX SETB », i.e. stick the text Hex on the stack and call SETB. Notice that the example program is SETB: it indirectly calls itself via the button press.

I don't remember how SETB actually sets the base, but it's buried in the lines DUP BASEN... through SWAP PUT MENU...

What most of that is about, though, is just editing the raw menu to add the block to the end of the label you want (for example, you pressed HEX so you want the button label to change to "HEX▪"). Then it just installs that list as a menu.

So, to answer your question, something else somewhere has to initially call SETB with the appropriate HEX/DEC/OCT/BIN string on the stack... from there, SETB always starts over with a raw copy of the list then edits it and installs it as a soft menu.

AFAICR, the line

Code:

IF 'CSMNU' VTYPE -1 ≠ THEN CSMNU + END

is just checking for the existence of an auxiliary menu, which gets appended to the menu that's about to be installed. You don't need this.
 

(10-02-2023 09:00 PM)DM48 Wrote:  Maybe a more specific question would be better. Once I press the soft-key and the flag status is changed, how do I refresh the soft-key menu to reflect the change?

Perhaps now it will make more sense. You'd need a little program (or a set of them, if it makes more sense to split up functionality) that is just for building and installing the menu. The soft key either runs the very program that it's in, or, in your case, more likely your soft ENGL button runs a little program that sets flag 60 and then tells the menu updater "hey, update to show ENGL active." And your SI button might run a different little program that clears flag 60 and then runs the menu updater program "hey, update to show SI active."

Or maybe both buttons run just one little program but they include a parameter on the stack to indicate which state they want to set up.

[johnb]

Continuing from my last... maybe a better approach is to make the "menu setter" function read flag 60 and build the menu so the appropriate indicator is ON. Then your buttons might just point to little program-lets that set or clear flag 60 and call the menu setter.

That would mean that no matter who or what calls the menu-setter, it can never get out of sync with the actual value of flag 60.

[DM48]

John, thank you for the response and I am glad to hear you are progressing with your recent surgery. Most of my neighbors have had a hip replacement of some kind and it has been amazing to watch the recovery progress improve drastically over the years.

The program I am creating at the moment is very simple. It is to teach me what I need to do. I also understand the use of "helper" programs you suggested while in this learning phase. This makes good sense.

When my program starts up, it checks to see if the FLAG has been set or not. It then gives the soft menu item the correct flag status on item. I am not understanding how to refresh the menu without writing another sub-routine to do exactly that and no more. Is this correct?

Program Starts
Menu created
Key pressed that changes the flag
Program calls upon sub-routine to create the menu

It seems from the above I have to code this up twice. Is this about the go of it? I was hoping I was not looking at this correctly.

[johnb]

(10-02-2023 10:23 PM)DM48 Wrote:  When my program starts up, it checks to see if the FLAG has been set or not. It then gives the soft menu item the correct flag status on item. I am not understanding how to refresh the menu without writing another sub-routine to do exactly that and no more. Is this correct?

1. Program Starts
2. Menu created [ed. by a single subroutine]
3. Key pressed that changes the flag
4. Program calls upon sub-routine [ed. from step 2] to create the menu

With my editorials above, that's pretty much how I'd do it.

Quote:It seems from the above I have to code this up twice. Is this about the go of it? I was hoping I was not looking at this correctly.

No, no need to code anything twice. I'm a software engineer and my dictum is "coding anything twice is bad." Any given functionality should have its home in only one place: then if you change it later, it changes everywhere. Strive to make each separate routine or function general purpose -- this helps. The "code only once" precept is also good for figuring out what code should be split out into a subroutine.

Does that make sense?

[DM48]

(10-02-2023 11:09 PM)johnb Wrote:  No, no need to code anything twice. I'm a software engineer and my dictum is "coding anything twice is bad." Any given functionality should have its home in only one place: then if you change it later, it changes everywhere. Strive to make each separate routine or function general purpose -- this helps. The "code only once" precept is also good for figuring out what code should be split out into a subroutine.

Does that make sense?

Of course it makes perfect sense. I thought about this for a minute. I sometimes have trouble (still to this day) with RPL and the no jumping to a specific line number. I have been programming on my DM42 for a couple of years and I forget how I made things work in RPL.

I through in a call to the program name after each button was pressed. This refreshes the menu with the least amount of effort.

Thank you again. I am going to continue to write a teaching program and then post it up for review and feedback.