Citer : Posté le 13/11/2025 19:24 | #

---

Looks like the problem you had before. Returning to the OS main menu is a complex operation, which involve the OS' own getkey() function. Basically gint calls it and presses MENU for you, bringing you back to the main menu.

Now when you come back, you see your app on the screen again, but the OS is still in charge until you press a key to finish the call to the OS' getkey() function (which pauses when the main menu opens and resumes afterwards). Only then does your application actually resume.

This is a limitation in gint. I have a good candidate for a fix, but I haven't tried it yet.

If you return or don't disable the gint_setrestart() feature then you won't be able to enter the app again. This is an OS limitation. It just doesn't allow that, for some weird reason. If you enable gint_setrestart(), gint will call main() in a loop with gint_osmenu() in-between to imitate the effect, which results in the same limitation as a normal gint_osmenu().

---

Citer : Posté le 13/11/2025 19:44 | # | Fichier joint

---

Before I mess something up you're on G-III right? What I said above applies to the G-III, not the CG-50.

---

Well you can actually go back. Let's say you're in the add-in, then you go back to the main menu. Click on the add-in again. Then press a random key like EXE. Boom, you're back in the add-in, no problem. In fact, if the screen that you do this on isn't animated, the user won't even notice.

You can't use the MENU key for the purpose of resuming the add-in though because on this "waiting screen" just after you click the add-in icon, the OS will pick up MENU as you wanting to go back to the main menu again, and will just bring you there.

For a reference, please check gintctl.g1a attached. You can leave to the main MENU with MENU at almost any point while browsing the app, and it appears seamless. If you go in "GINT" (F2), then "Drivers and worlds", then "OS" (F2), you have a screen for testing return-to-menu. Press [2] to return to the menu. Then press EXE again to come back. You will see the gintctl screen again but gintctl has not actually resumed yet. Press EXE again. You will see the "Return-to-menu" counter increase, showing that gintctl has in fact resumed, increasing the counter and generating a new frame.

You might better understand what happens if you make your app more interactive. Make it display things that move all the time and react to more than one key and it will be much easier to see what's happening.

---

Citer : Posté le 13/11/2025 20:55 | #

---

Oh, that makes sense. keydown() tells you if the key is currently pressed according to the events that have been processed so far. keypressed() tells you if the key changed from not-pressed to pressed according to the events that have been processed since the last time you called cleareventflips(). It's not the most intuitive but the point is that, in a loop,

* keydown() will be true at every iteration while the key is pressed;
* keypressed() will be true only once, at the iteration where the key changes from not-pressed to pressed.

In order for that to happen, you have to cleareventflips() which "remembers" the current state, then read some events, and then keypressed() will tell you if the key changed between the call to cleareventflips() and the call to keypressed().

Which gives you this archetype, which is kind of the "only" way to use these functions:


Typically in a game you'd use keydown() for movement keys, which have an effect for as long as they're pressed, and keypressed() for button or inventory keys, which only have an effect at the moment you press them.

---