(07-23-2023 10:09 PM)johnb Wrote: There's also a block character in "chars" (right-shift PRG).
I've built self-referential functions that move the character from menu item to menu item as an indicator. For example, in the menu below, it moves it between Hex, Dec, Oct, and Bin. Ignore all the other menu items here (it's a general purpose / 16c set of menus). I'm showing the exact code so you can see how it might be used in practice. This is function SETB:
Code:
«
{ S→U U→S BDISP STWS RCWS
{ "»FMT" SETF }
{ "HEX" « HEX SETB » }
{ "DEC" « DEC SETB » }
{ "OCT" « OCT SETB » }
{ "BIN" « BIN SETB » }
R→B B→R }
IF 'CSMNU' VTYPE -1 ≠ THEN CSMNU + END
DUP BASEN 6 +
GET DUP 1 GET "▀" + 1
SWAP PUT BASEN ^ +
SWAP PUT MENU 1.02 MENU
»
The first bit (between the external set of braces {}) is the menu.
The first row of button assignments are just signed/unsigned conversions, a function that shows 'x' in all 4 major bases, set/recall word size, and "switch to format menu. Ignore this part.
The CSMNU stuff adds on additional rows to the menu shown, and can also be safely ignored.
The interesting part are the Hex/Dec/Oct/Bin buttons (which fall on the next page of the softbutton menu), and their assigned function calls. The bottom few steps of the program get the 3-character name, append the block character, assign it as the button label while assigning the default labels to the rest, and install it all as a menu. Every time you press one of the hotkeys assigned to Hex/Dec/Oct/Bin, SETB edits the menu and replaces it in place.
Hope this helps!
John, do you have a much simpler (less of it) program that can show how this works in practice?
Does this method rely on having other menus already created?