Re: Plea for assistance...

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