any clues on what causes this? | developer.brewmp.com any clues on what causes this? | developer.brewmp.com

Developer

any clues on what causes this?

Forums:

I have an app on the VX6000 that exits the app manager on exit, ISHELL_CloseApplet is called with FALSE when the CLR key is pressed , interesting the docs don't seem to actually specify if its true or false, but thats what works elsewhere.

// CLR Key Exits correctly

Self_HandleEvent( 0x1043b7c, 257, 57392, 0 )
Self_HandleEvent( 0x1043b7c, 512, 5, 0 )
#*gXX=Current
CloseApplet - 16855573
WakeClose 1013215
App_Close (1013215) - RESUME
#*gCL=16855573
Self_HandleEvent( 0x1043b7c, 1, 0, 1244036 )
#*gXX=Current
CloseApplet - 16855573
WARNING: App Callback Pending (01042024)
WARNING: App Callback Pending (0105FF18)
Validating Heap...
------ App Heap Info ------
40 - App #518 File: AEEModGen.c Line: 210 (L)
-------------------------
72176 Alloc - Total
0 OEM
72136 BREW
40 Apps
1972 Wasted
425844 Free - Total
301420 Largest
115432 Largest Non Seq.
124424 Total Non Seq.
-------------------------
App_Cleanup(1013215)
** App Released
** App Unloading
App_Free(1013215)
App_Cleanup(1013215)
WakeResume
#*gRE=16809984
Restart App
App_SendStart(0)...
App Started...
WakeResume Done

// CLR Key Exits too far

Self_HandleEvent( 0x1043b7c, 257, 57392, 0 )
Self_HandleEvent( 0x1043b7c, 512, 5, 0 )
#*gXX=Current
CloseApplet - 16855573
WakeClose 1013215
App_Close (1013215) - RESUME
#*gCL=16855573
Self_HandleEvent( 0x1043b7c, 1, 0, 1244036 )
#*gXX=Current
CloseApplet - 16855573
WARNING: App Callback Pending (01042024)
WARNING: App Callback Pending (0105FF18)
Validating Heap...
------ App Heap Info ------
40 - App #1095 File: aeemodgen.c Line: 210 (L)
-------------------------
72176 Alloc - Total
0 OEM
72136 BREW
40 Apps
1972 Wasted
425844 Free - Total
301420 Largest
115432 Largest Non Seq.
124424 Total Non Seq.
-------------------------
App_Cleanup(1013215)
** App Released
** App Unloading
App_Free(1013215)
App_Cleanup(1013215)
WakeResume
#*gRE=16809984
Restart App
App_SendStart(0)...
App Started...
WakeResume Done
#*gXX=Current
CloseApplet - 16809984

Thats the trace from the emulator the first one is a correct exit, the second one incorrect, the problem lies with that final

#*gXX=Current
CloseApplet - 16809984

Which is called after the app is closed it looks like

Is there a reason or condition where an extra CloseApplet that exits the app manager ?

Did you ever find this out? I've got a problem where the phone selects the GetItNow shop icon upon exit. Is there some weird way you have to quit out of apps on the VX6000?

Did you ever find this out? I've got a problem where the phone selects the GetItNow shop icon upon exit. Is there some weird way you have to quit out of apps on the VX6000?

in general, ISHELL_CloseApplet was used only corresponding to ISHELL_StartApplet

in general, ISHELL_CloseApplet was used only corresponding to ISHELL_StartApplet

In response to charliex's query, I had the same problem too. It seems like one of the key handlers for AVK_CLR returns FALSE. You should return TRUE after handling the CLR button press. It causes the extra
#*gXX=Current
CloseApplet - 16809984
in the emulator, and quits too far out of the app manager.
Hope this helps.

In response to charliex's query, I had the same problem too. It seems like one of the key handlers for AVK_CLR returns FALSE. You should return TRUE after handling the CLR button press. It causes the extra
#*gXX=Current
CloseApplet - 16809984
in the emulator, and quits too far out of the app manager.
Hope this helps.

I use to trap AVK_CLR and set an aux var, such as, exitRequest in case this key shall exit the APP or do something else (like return to menu or clear a char on a field etc).
In the EventHandler call back I check the if the user has pressed AVK_CLR and return (exitRequest) that will reflect the fact of exiting or not the APP...
It works fine and force the APP to exit in a "natural way".

I use to trap AVK_CLR and set an aux var, such as, exitRequest in case this key shall exit the APP or do something else (like return to menu or clear a char on a field etc).
In the EventHandler call back I check the if the user has pressed AVK_CLR and return (exitRequest) that will reflect the fact of exiting or not the APP...
It works fine and force the APP to exit in a "natural way".

The AEE will automatically cause the app. to exit if your AVK_CLR handler returns FALSE.
Quote:ISHELL_CloseApplet is called with FALSE when the CLR key is pressed
Are you calling ISHELL_CloseApplet from your AVK_CLR handler then returning FALSE after ISHELL_CloseApplet returns (if it returns)? Returning FALSE after calling ISHELL_CloseApplet could be causing an extra ISHELL_CloseApplet to show up in the queue.

The AEE will automatically cause the app. to exit if your AVK_CLR handler returns FALSE.
Quote:ISHELL_CloseApplet is called with FALSE when the CLR key is pressed
Are you calling ISHELL_CloseApplet from your AVK_CLR handler then returning FALSE after ISHELL_CloseApplet returns (if it returns)? Returning FALSE after calling ISHELL_CloseApplet could be causing an extra ISHELL_CloseApplet to show up in the queue.

just switched from keypress to key, the handling of the return value stayed the same,.

just switched from keypress to key, the handling of the return value stayed the same,.

Quote:Originally posted by flarb
Did you ever find this out? I've got a problem where the phone selects the GetItNow shop icon upon exit. Is there some weird way you have to quit out of apps on the VX6000?
I'm having this problem too, both on the VX6000 and the Kyocera KX414. If I quit in response to a AVK_CLR from my top level menu, it exits back to the phone's main screen (not the Get It Now Menu). If I quit in response to a AVK_SELECT from the top level menu (on the "exit" option), it exits back to the Get It Now Menu but then activates the shop icon, as flarb describes.
What this looks like to me is that whichever key I exit with is still somehow on the system event stack when my app finishes.
Quote:Originally posted by eightyhertz
In response to charliex's query, I had the same problem too. It seems like one of the key handlers for AVK_CLR returns FALSE. You should return TRUE after handling the CLR button press. It causes the extra
#*gXX=Current
CloseApplet - 16809984
in the emulator, and quits too far out of the app manager.
I have double checked that I return TRUE from my main event handler whenever I get an AVK_CLR. I exit via a call to ISHELL_CloseApplet(), and do my cleanup in the EVT_APP_STOP that follows.
In the emulator I only see one "CloseApplet" type line.
So did anyone get a different solution from "be sure to return TRUE from the event handler" idea?
Thanks,
-Jesse

Quote:Originally posted by flarb
Did you ever find this out? I've got a problem where the phone selects the GetItNow shop icon upon exit. Is there some weird way you have to quit out of apps on the VX6000?
I'm having this problem too, both on the VX6000 and the Kyocera KX414. If I quit in response to a AVK_CLR from my top level menu, it exits back to the phone's main screen (not the Get It Now Menu). If I quit in response to a AVK_SELECT from the top level menu (on the "exit" option), it exits back to the Get It Now Menu but then activates the shop icon, as flarb describes.
What this looks like to me is that whichever key I exit with is still somehow on the system event stack when my app finishes.
Quote:Originally posted by eightyhertz
In response to charliex's query, I had the same problem too. It seems like one of the key handlers for AVK_CLR returns FALSE. You should return TRUE after handling the CLR button press. It causes the extra
#*gXX=Current
CloseApplet - 16809984
in the emulator, and quits too far out of the app manager.
I have double checked that I return TRUE from my main event handler whenever I get an AVK_CLR. I exit via a call to ISHELL_CloseApplet(), and do my cleanup in the EVT_APP_STOP that follows.
In the emulator I only see one "CloseApplet" type line.
So did anyone get a different solution from "be sure to return TRUE from the event handler" idea?
Thanks,
-Jesse

As Charlie points out above, handling your event in EVT_KEY instead of EVT_KEYPRESS usually solves the problem.

As Charlie points out above, handling your event in EVT_KEY instead of EVT_KEYPRESS usually solves the problem.

Charlie, Dragon, thanks. I misread Charlie's message, mistaking it to mean that he saw no change in behavior when he switched from key to keyPressed.

Charlie, Dragon, thanks. I misread Charlie's message, mistaking it to mean that he saw no change in behavior when he switched from key to keyPressed.