Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
Developer
Posts: 39
Registered: ‎03-17-2009
My Device: Not Specified

How to ensure event lock for MIDlet.platformRequest()?

My MIDlet needs to be able to open some web pages for the user.  On other J2ME devices this works fine.  On BlackBerry (simulator 4.0.2), the code gets:

   RuntimeException: pushModalScreen called by non-event thread

I wrote a little test MIDlet that works fine, but my real MIDlet, which does have a few explicit threads, fails with this exception, even if I try to force the thread with UI code immediately preceding the call, as in:

Display.getDisplay( midlet ).setCurrent( new Form("open browser") );
boolean mustExit = midlet.platformRequest( url );

 

I've seen lots of references to how to do this with a RIMlet, as in

How To - Manage UI interactions
Article Number: DB-00134
http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800505/800608/...

and

How to - Update a screen on the Main Event Thread
Article Number: DB-00136
http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800505/800256/...

but not much for MIDlets.  The forum thread:

IllegalStateEx: UI engine accesed without hoding the event lock in LocalDevice.getLocalDevice()   
http://supportforums.blackberry.com/rim/board/message?board.id=java_dev&message.id=220#M220

has BlackBerry advice that says "Moreover, in the MIDP UI space, you should be more or less immune to this sort of consideration, since the concept of an event thread doesn't necessarily apply to MIDP..." but this seems clearly not to be the case, since I'm getting the above exception and have purely MIDP code.  The stack trace:

UiEngineImpl.pushModalScreen(Screen) 481 // line throwing RuntimeException
Dialog.doModal() 509
Dialog.ask(int,String,int) 432
MIDlet.platformRequest(String) 323
... my code

 

 

How does one reliably call MIDlet.platformRequest()?
Developer
Developer
Posts: 39
Registered: ‎03-17-2009
My Device: Not Specified

Re: How to ensure event lock for MIDlet.platformRequest()?

I have also looked at

How to - Invoke the browser
Article Number: DB-00701
http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800440/How_To_...

(which has replaced
How To - Invoke the default browser
Article Number: DB-00010
http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800440/How_To_... )

but it also seems to only talk about the RIM APIs and not MIDP.
Developer
Developer
Posts: 39
Registered: ‎03-17-2009
My Device: Not Specified

Re: How to ensure event lock for MIDlet.platformRequest()?

I have also tried creating a Runnable that does the MIDlet.platformRequest() call and then invoking it with Display.callSerially() (which brought up the confirmation dialog but then froze) and from its own thread (also froze), but to no avail.
BlackBerry Development Advisor
Posts: 15,723
Registered: ‎07-09-2008
My Device: BlackBerry PRIV
My Carrier: Bell

Re: How to ensure event lock for MIDlet.platformRequest()?

Are you able to reproduce this on more recent versions of BlackBerry handheld software (i.e. 4.5.0+)?  If so, can you post some sample code that triggers the exception?
Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Developer
Developer
Posts: 39
Registered: ‎03-17-2009
My Device: Not Specified

Re: How to ensure event lock for MIDlet.platformRequest()?

Sorry for the response taking a while.  Given the other problems encountered with the JavaME UI ("multiple 4.0.2 bugs in J2ME MIDP2 implementation - example included" http://supportforums.blackberry.com/rim/board/message?board.id=java_dev&thread.id=27988) as well as the business need to support back to 4.0.2 and the desire to eventually run with the native BlackBerry UI anyway, the resources weren't around to do further testing and case analysis -- I can only say that I got that message at that stack trace using that version.