Post Reply 
42S/Free42 programming: jumping back to the last MENU after RTN
04-30-2019, 07:16 PM
Post: #1
42S/Free42 programming: jumping back to the last MENU after RTN
This has been tripping me up lately. I've got a TVM/finance program on my DM42, with assorted menus that mimic the 17BII/27S TVM menus. This works fine. All the KEYG and KEYX assignments branch to local labels within the program.

I also have a couple of programs that are useful to run within the context of doing TVM work. If I XEQ these programs from the keyboard while the TVM menus are open, the RTN at the end of the secondary program leaves the program pointer within that secondary program. Now all the menu keys spit out "Label Not Found" until I manually XEQ "TVM" again, because they're trying to branch to local labels inside the TVM program.

What's a good way to work around this? Ideally, if a program's MENU is currently displayed on screen, then an RTN with an empty return stack (i.e. inside a program run manually from the keyboard) should jump back to the most recent MENU statement and halt, but that's not how the 42S behaves. Are there any good alternatives that don't require making all the labels used for menu keys global, or doing various elaborate tricks inside any potential secondary program? Should I just attempt to patch this RTN behavior into the DM42 firmware? Smile
Visit this user's website Find all posts by this user
Quote this message in a reply
04-30-2019, 08:25 PM
Post: #2
RE: 42S/Free42 programming: jumping back to the last MENU after RTN
Making RTN return to the program that was active when the XEQ was performed does sound like an obvious idea, both for KEYX and for XEQ performed from the keyboard, but it would probably break many programs that depend on the current behavior. I thought about it while making the changes for local variables and the larger RTN stack, but in the end decided to leave it alone.
Find all posts by this user
Quote this message in a reply
04-30-2019, 08:57 PM
Post: #3
RE: 42S/Free42 programming: jumping back to the last MENU after RTN
Yeah, there are potentially some obscure edge cases where it would cause problems, so a flag to toggle that behavior would probably end up being needed. But it would likely fix more things than it would break if it's limited to only happening when hitting an RTN with an empty return stack while a program has a MENU (or VARMENU?) currently displayed.

Essentially, store a return address any time MENU is called, and make RTN go back there and stop if the return stack is empty and flag 75 is set, so that R/S would begin executing at the step after the MENU instruction. (Programs written to require R/S after working with a menu would need an extra press to get past the STOP following MENU.)
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 




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