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".
| 