Re: Plea for assistance...

Yes, and it is likely to happen if you are doing "display.setCurrent(menu);
" inside any of the "event delivery methods" and after doing the
setCurrent(menu) you are doing some more stuff utilising the thread while
other keyPressed events queue up. The event handling thread must be free
for setCurrent() to take effect.





                      Mark Young
                      <mark.young@xxxxx        To:       
KVM-INTEREST@xxxxxxxxxxxx
                      OM>                      cc:       (bcc: Debasis 
Das/INFOCOMM/RIL)
                      Sent by: A               Subject:  Re: Plea for 
assistance...
                      mailing list for   Importance: Normal  Sender's OU: 
Reliance |------------------|
                      KVM discussion                                            
   | [ ] Confidential |
                      <KVM-INTEREST@JAV                                         
   |------------------|
                      A.SUN.COM>


                      12/17/2003 04:26
                      PM
                      Please respond to
                      A mailing list
                      for KVM
                      discussion






It looks like you worked it out. The key thing to remember here is that
setCurrent() is not a synchronous call. It is a *request* to the system
to switch screens. That request is honored at some point in the future.

As you discovered, in the time it takes between the call to setCurrent()
and the call to the new screen's showNotify() method, some key events
were encountered and processed. They were correctly being delivered to
the *current* screen - its just that you weren't expecting them ;-)

In general, I've found that coding MIDlets as a type of state machine is
a very effective way in coping with such timing issues. Imagine that, on
a different emulator you may never have experienced such a timing issue,
and your midlet could experience such failure in the field.

Regards,

- Mark


Adrian Hill wrote:
> Hi all,
>
> Many thanks on all the advice given. Your help really is appreciated,
thank
> you :)
>
> I tried changing the methods called to use the synchronized keyword (and
> removed my earlier checks), but the problem pops up again. To try to
> describe what's happening...
>
> menu.loadWinReport(winnings);   // loads up the win report window, sets
state
> to WIN_REPORT
> display.setCurrent(menu);       // menu is a Canvas or Nokia FullCanvas
object
>
> In the keyPressed method...
>
> switch (state) {
>         // a few case statements here, then...
>
>         case STATE_GAME_REPORT: midlet.playAgain(); return;
>         default: return;
> }
>
> The midlet.playAgain method consists of...
>
> public synchronized void playAgain() {
>         if (stake.canRepeatLastBet())
>                 display.setCurrent(gameplay);
> }
>
> So... going through this bit by bit now, I'm assuming that some keys are
> hammered...
>
> The keyPressed method gets called, and then calls the midlet.playAgain()
> method, which checks if we can repeat the last bet (which is where the
stake
> is modified), and this then brings us to the gameplay screen.
>
> Ah, I see now. It's just that the events were getting queued up, and even
> though the display had been switched over to another canvas (the game
> canvas), the events that were left over on the menu canvas still had to
be
> processed (hence the multiple stakes being added on). Does this sound
more
> like it? It does to me at any rate... my apologies for jumping up on the
> list, querying the VM before I query my own code... However, could
someone
> confirm this for me please?
>
> The discussion and advice has been very useful to me, however. Thank you
all
> for your patience, and apologies for my slowness on this one... I'm going
to
> blame it on the overtime :)
>
> Thanks again, and sorry.
>
>
> Adrian
>
> Adrian Hill
> Software Architect
> NRMi
>
> Phone: +44 (0)1482 441142
> Web: http://www.nrmi.co.uk
>
> The information contained in this message is confidential and may be
legally
> privileged. The message is intended solely for the addressee(s). If you
are
> not the intended recipient, you are hereby notified that any use,
> dissemination, or reproduction is strictly prohibited and may be
unlawful.
> If you are not the intended recipient, please contact the sender by
return
> e-mail and destroy all copies of the original message.
>
>
===========================================================================
> To unsubscribe, send email to listserv@xxxxxxxxxxxx and include in the
body
> of the message "signoff KVM-INTEREST".  For general help, send email to
> listserv@xxxxxxxxxxxx and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@xxxxxxxxxxxx and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
listserv@xxxxxxxxxxxx and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@xxxxxxxxxxxx and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
listserv@xxxxxxxxxxxx and include in the body of the message "help".