Java Development

[thorntech]

I am trying to call Invoke.invokeApplication to open the Email editor. The device I am testing on does not have an email account setup, so I get dialog box saying "No accounts available. You will only be able to save a draft" (or something like that). This is fine and expected. However, when I select Ok to dismiss the dialog box, the application hangs. 

The device I am testing on is a Pearl 8130 from Sprint.

I am calling the following code from the Canvas keyPressed handler:

MessageArguments args = new MessageArguments(MessageArguments.ARG_NEW, to, subj, "");

Invoke.invokeApplication(Invoke.APP_TYPE_MESSAGES, args);

       MessageArguments args = new MessageArguments(MessageArguments.ARG_NEW, to, subj, ""); 

      Invoke.invokeApplication(Invoke.APP_TYPE_MESSAGES, args);

(where "to" and "subj" are just local variables parsed from the page)

Has anyone experienced this before? Any idea why it might be happening? 

I believe the Pearl has an OS Version of 4.3. Could this happen if the app was compiled with version 4.5 or 4.6 of the SDK? 

Thanks in advance for your help.

Jeff

[MSohm]

If you are targeting BlackBerry device software version 4.3, the application should be built in version 4.3 or lower of the BlackBerry JDE/ BlackBerry Java SDK.

What line of code is your application hanging on?  Are you able to task switch out of the application (hold Alt and press escape)?

[thorntech]

I don't know what line of code it hangs on. It seems like the Invoke.invokeApplication works fine and leaves control from my app. Then, I get that dialog saying that "no email account is setup" - which is the case I am testing. The whole phone locks up at that point and I cannot dismiss that dialog box. 

I do think the issue may be related to the version of the SDK the app is built with. I believe it was built with version 4.6. The phone I am testing on has platform version 4.3.

There might also be background threads running in the app (I didn't write the code - I am just trying to fix it!). What happens to those background threads after a call to Invoke.invokeAppliacation? 

Thanks for your help. 

Jeff

[MSohm]

The first thing I recommend is building the application in a supported version of the BlackBerry JDE.

The application would continue doing whatever it was doing (running its background threads, etc...) after the dialog is dismissed.

Is the application you are creating a UiApplication?  If so, does it display a screen?  If not it is possible that you are actually seeing your application (that doesn't have a screen on the display stack), which means the screen would have nothing "refresh" after the dialog was dismissed (the dialog would remain visible).  This would make it appear that the device has locked up.  A way to test this theory is to try and task switch out of the application by pressing Alt + Escape.

[thorntech]

Well the application does have screens, but it is a MIDlet. I am not sure if that makes a difference.

I will try the Alt-Escape feature to see if that works. I wonder if my app is simply not redrawing. 

[thorntech]

Hi Mark,

I think I have found the cause of my problem. The application that I am trying to maintain has a keyListener attached to the main application. When my code calls Invoke.invokeApplication, the Compose Email screen comes up, but my app is still capturing all key events.

What is the recommended approach for handling this? Should I remove the keyListener before calling Invoke.invokeApplication? If so, how will I know when to reattach it?

Thanks!

[MSohm]

A KeyListener should not be used within a MIDlet.  It is designed for use in BlackBerry CLDC applications only.

[thorntech]

Let me rephrase that....the MIDlet startApp() method creates a display using a class that is derived from Canvas. This Canvas class also implements KeyListener and calls UiApplication.getUiApplication().addKeyListener(this);

When I start the Email Composer using Invoke.invokeApplication, the Canvas class still gets the key events. 

Is it not correct to do this? 

I didn't write this code. I am just trying to correct it! (it obviously needs a lot of work!)

[thorntech · Accepted solution]

I think I have solved my problem.

In the KeyListener keyDown() method, I added the following code:

if(!isShown())
    return false;

That seemed to do the trick.

If there is still something not right about this approach I would appreciate your thoughts.

Thanks

[Matty]

---

thorntech wrote:

If there is still something not right about this approach I would appreciate your thoughts.

Thanks

---

No such thing as "not right", only "works" and "doesn't work".  

M