I recently have published a webos application and a user protests because the device hangs when he tries to exit. It occurs in palm pre 2 but in hp touchpad works properly.
Yes, this is happening recently to my latest Pre 2 app too. It never used to happen. And it doesn't always hang. You can never be sure if it will or not. Sometimes takes a minute for the Pre to sort itself out. Not sure if this is due to GLB or the Pre firmware.
Did it happen in the previous version ?
I think this it´s for something in the Beta... or the version of O:S in the palm...
I do a lot of test in the palm Pre, and never frozen after push the button... I have the 1.45?¿.. The last update can support the palm Pre ...
I'm not using the beta of the new GLB and I haven't compiled for webOS in a long while, so I'm not sure. None of my old apps have this as far as I know. Just trying them now didn't cause the hang, but neither did my new app after 5 or 6 attempts. But it does happen.
I presume there have been no PalmOS updates recently ?
None for a while, but 2.2.4 is supposedly available, but always fails to install after downloading - tried on several occasions. Trying again now, just to make sure.
[EDIT] Nope. Failed again.
Quote"The update failed to properly validate. This problem may usually be fixed if you wait a little while, then try again. We will try again for you in about a day."
Bull. I've been trying for weeks.
Wonder if you the available free space is less than that needed
I've got 14.3GB available of 16GB. That should be more than enough for the OS.
It happens with both versions of GLB and always at least in my case. If anyone wants to test it, I will send him a promo code by MP.
Hmm. Since some apps do this and others do not I wonder if there is there a way of generating a list of the commands used when compiling a proggy. Maybe there is a particular GLBasic command that will cause an app to hang. Comparing commands used would help.
@Msx, if you want send me a promocode... how you want... I try and tell you if frezze or not :booze:
Enviado, pero hasta las 12 creo no vale ;)
I Found the bug which causes freezing in palm pre 2. The problem occurs when the app is working on a virtual screen and then try to get out of it. For the device does not freeze is necessary to change to the back buffer.
Thank you.
So using CREATESCREEN .... and then USESCREEN causes it ?
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 :)
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.
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.
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.
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?
I hope Gernot can fix it, it does not seem very complicated.
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.
QuoteNormally 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.
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.
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.
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)?