Although under normal circumstances, Rolf's suggestion of using
synchronization to control multi-thread behavior is a good one, it may
be a bit inappropriate here.
As I mentioned previously, it actually is a violation of the MIDP spec
for your keyPressed() method to be called more than once "at a time".
I'd like to know what emulator you're using and get to the bottom of
this potential violation before moving onto workarounds.
There should be no need for any type of synchronization in this
scenario, as you are protected by the MIDP specification itself. It
would be a shame to start adding synchronization blocks which will serve
no use other than to work around a particular emulator bug.
I know the MIDP RI behaves correctly, and I would assume in turn the
WTK. Can you share what emulator you are using to observe such behavior?
Regards,
- Mark
Rolf Sponsel wrote:
To be more precise you need to use a synchronized block
in the method, i.e. NOT a synchronized modifier for your
method, which allows the next event "into" the method but
blocks it to be processed until your first event has been
processed by the code within the synchronized block.
Regards
/ Rolf
Rolf Sponsel wrote:
Hi Adrian,
Now it's been a long time since I've hacked MIDP, so please
correct me if I'm totally out of my mind here, but didn't
J2ME support the synchronized feature? I does - right?
This about "delivering key presses serially", isn't all that a
"promise" that ALL the user generated key presses ARE delivered
in sequence, i.e. in the right order in case of pressing different
keys. But that doesn't mean that you're not responsible to hinder
the VM to deliver events to your method before you have processed
any earliear event and are ready to process the next one, e.g. by
using the synchronized modifier, etc.
I made a quick check in my source and - Yes - I did use synchronized
for such things you're trying to do, and therefor I suggest you to
try that.
Hope this helps!
Best Regards
/ Rolf
Adrian Hill wrote:
Hi again,
Could you explain a bit what you're trying to do?
I am experiencing difficulties where a user will hit a key repeatedly and my
MIDlet will start processing the second keyPress before it has finished
processing the first one.
If you're processing
key events I'll assume you have a Canvas that wants to do something in
response to a key press.
OK, but it's quite complicated (well, for me anyway :)). I just wanted some
info on keypressed stuff. Here goes anyway...
... in my Canvas object...
... in the keyPressed method...
case STATE_GAME_REPORT:
// New little check to stop key hammering bug...
if (!playAgainHit) {
playAgainHit = true;
midlet.playAgain();
} return;
...
If I hit the keys fast enough (occurs on either emulator or phone), then bad
things happen. It's difficult to describe, but here goes anyway...
Two keys are pressed in quick succession. The check above is supposed to
ensure that playAgain gets called once and only once. This fails sometimes
because the first keypress event arrives, sees that playAgainHit is false,
sets it to true, is about to call midlet.playAgain()... but this never gets
called, as the second keypress has arrived, and interrupts the first one.
This second keypressed event finds that playAgainHit is false, so the
midlet.playAgain() call never happens.
All verified using System.out.println's in the emulator (which may not be
the most reliable bit of evidence).
To fix this problem, I added the following to the start of the paint method
(yes, I know it's nasty, but)...
// If someone's hammering the keys, then give the
// phone a bit of time, then reset it. That'll learn 'em :)
if (playAgainHit) {
Timer timer = new Timer();
TimerTask task = new TimerTask() {
public void run() {
playAgainHit = false;
}
};
timer.schedule(task, 1500);
}
Just elaborate what it is you're trying to do
and we can tell you how to do it.
I'm trying to make my MIDlet run normally when users hammer the keys, or at
least find out a bit more on how MIDlets process key events.
Tim writes:
These methods are all called serially. That is, the
implementation will never call an event delivery method before a
prior call to any of the event delivery methods has returned."
This is pulled word for word from the Canvas class description
under the Event Delivery heading. I would say that this is a bug
in the VM. (Unless I am missing something.)
I assumed they are all called serially, which is why I'm finding this bug so
hard to figure out. This occurs on Nokia series 40 and 60 phones and the
related emulators, also on the Motorola T720 and Samsung C100. I have a
horrible feeling it's something I've done, but have looked everywhere else.
I just wanted to know if this was how things were handled by the
specification (and it appears so).
Many thanks for your replies,
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".
--
----
------
--------
Rolf Sponsel
___________________________________________e_n_d___o_f___m_e_s_s_a_g_e_
===========================================================================
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".
--
----
------
--------
Rolf Sponsel
___________________________________________e_n_d___o_f___m_e_s_s_a_g_e_
===========================================================================
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".
