Does anyone know how to achieve the same effect as GetKey (that is, built-in key debouncing, and returning GetKey keycodes instead of program/matrix codes), but while blocking the user from getting into the Menu?

I need the exact same behavior GetKey has, because it's going to be used as a parameter to EditMBStringChar. This also means it's the GetKey-alike function that must be responsible for handling the shift/alpha/alpha-lock modes.

I tried dozens of combinations of GetKeyWait_OS along with GetKey, PRGM_GetKey and custom matrix-reading routines.

Blocking the Menu along with providing text input is a nightmare; does anyone have any suggestions to achieve it?

Hint: how does the OS block people from getting into the menu while running the first-run wizard, when the calculator reboots? Is there a flag somewhere which says "no menu allowed"? That would be the optimal solution.

Hint 2: after the calculator was rebooted and no mode was selected in the Menu, pressing the Menu key does nothing, either.
I thought the matrix reading routines blocked the MENU key, leaving you to handle it for yourself. You could write a wrapper for that so it returns the key pressed instead of true or false and to handle the Shift and Alpha keys.
GetKey seems to have some kind of magic so that it correlates itself with EditMBStringChar, eventually it's all based in the setup flags but I have no way to confirm. It'd be a lot of work to implement my own GetKey, and I'm leaving that as a last resort option.
I'm now inspecting Bkey_SetFlag and what it may allow me to do; it seems to affect in somehow the way keys are processed (for example, it seems to block all keys from being read while the Low Battery message is shown). If I could get it to work so that Menu is ignored (not only in my own GetKey, but in any GetKey the system may do, for example in the Capture and Character Select screens)...
Out of curiosity, has any progress been made on this, either from the re-writing or the reverse-engineering perspective? Or do you still need assistance and/or code?
I'm using a workaround: I've added individual code to handle each of the number keys, and now I only allow numeric passwords. It's easier to handle numbers only because there's no lowercase to handle.

Of course it would be much better if we found a way to use GetKey without allowing Menu, so it could be used flawlessly with EditMBString. Also, GetKey seems to be responsible for blinking the cursor (or even showing it at all), so right now my add-in does not show a cursor for password input.
The fx legacy syscalls
0x477: void EnableGetkeyToMainFunctionReturn( void );
0x478: void DisableGetkeyToMainFunctionReturn( void );

do exactly what I want, but I'm yet to find out what's their equivalent in the Prizm.

The closest thing I could find to DisableGetkeyToMain(...) was (and I'm taking this right from my code comments):


//with syscall 0x1E78, once you press Menu you're taken to the Link app, and there pressing Menu results in a brief spinning icon but no Menu. Pressing Menu in one of the submenus of the Link screen results in you being taken to the main Link screen. Conclusion: Menu became Link.

Also, there's one interesting comment in the source of INSIGHT:


// if an add-in is run from RAM, the host is LINK

I really need to get to talk with Simon one of these days...
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum