Palm Pre 2 frozen when I close my app

[Ian Price]

I did wonder if that might be the case, actually. I've been using virtual screens for scaling for various machines; something I've not done in my other apps.

Still doesn't explain why my app doesn't always freeze though, while it happens all the time to MSX.

Cheers MSX, now we can at least try to work around it

[msx]

I will try to explain. The problem occurs when we are working on a virtual screen by using, for example, USESCREEN 1 and then try to exit of the application. Then there is a freezing of the device and may even crash completely. Before exiting we must return to USESCREEN -1.

[Ian Price]

Yep, that would seem to be why I only get it randomly - the work has been done on the virtual screen and is now displaying via USESCREEN -1.

Unfortunately, when exiting - no further code appears to run, so returning to screen -1 isn't always possible. And a freeze/crash will occur.

[MrTAToad]

It might be worth trying to speed up any routines between CREATESCREEN and USESCREEN so the chances of it happening are reduced - or perhaps telling the user it wouldn't be a good idea to exit the program whilst you are doing anything between the two commands.

[Ian Price]

I'm considering adding an "EXIT GAME" option on the titlescreen - that way you know that the user is not exiting via the gesture area during the virtual screen updating. I know HP aren't keen on this, but they do allow it. And they aren't getting many new apps nowadays anyway...

Perhaps Gernot can fix this problem in the next update?

[msx]

I hope Gernot can fix it, it does not seem very complicated.

[spacefractal]

Can you give a code example to invoke the bug?

It's look like its cause either a null pointer bug or loop issue when usescreen is invoked with no surface. Normally you should not write to buffer when quit have been handled.

[Ian Price]

Normally you should not write to buffer when quit have been handled.

We aren't - it's probably that drawing on the virtual screen has not completed when the exit key is pressed (prior to being drawn on the visible screen), causing the strange freeze/loop. It's not something that we can do much about - it seems like an internal GLB problem.

You can call the USESCREEN -1 at any point BEFORE the user presses exit (uses gesture area), but the moment he presses it, you can't do anything else in code; if it's in the middle of drawing to the virtual screen, then you're stuffed and get the freeze.

As I stated you can control this by adding a physical exit button, as you can ensure the keypress/exit occurs during displaying of the physical screen and not the virtual one.

[spacefractal]

even with onscreen quit, that button might not been used and still quit in the normal metod. In Greedy Mouse I also added the quit button as well (for Android version only), but I still close the app directly by homebutton anyway. So you cant trust how the user close the app. Howover should this thread not been moved to the bug section, since its a real bug?

GLB_ON_QUIT() is not invoked, and I guess its also happens with ALLOWESCAPE FALSE?

Its could also been a OpenGL bug.

Howover this is a real bug, so move it to the bug forum.

[Ian Price]

Indeed, but it wasn't obvious it was a bug at first.

And yes, users can (and do) exit via alternative methods to the Exit menu.

Moving to Bugs forum.

[spacefractal]

its a nice discovered bug after some invistate what its really happens. A code example to showoff the bug would still been in place, so its easier to checkout what it happens.

Im not sure I did that for WebOS version of my game, but should I do that (even its should not accour in my game because I did not use offbuffers at all)?