Alert setCommandListener ???

[artemg]

I have a multithreaded app. At some point I have an alert, which can be dismissed (default command) and go onto next Displayable. The problem with the default command, I cannot stop any running threads. This way when I dismiss an alert, I will get results from the tread later on. Obviously, not a desired option.

According to MIDP specifications, Alert can be a CommandListener (myalert.setCommandListener(this)). This works on the WTK emulator, but nokia 7210 SDK prompts an "Illegal state excemption".

Is there a special way to set Alerts as command listeners?

[grahamhughes]

You're using the WTK2.0, which is intended for developing applications for MIDP-2.0 compliant devices. The 7210 is a MIDP-1.0 device. The ability to attach a CommandListener to an Alert is a new feature in MIDP-2.0, and will not work on a MIDP-1.0 device. The specification states that setCommandListener() on an Alert will throw an IllegalStateException.

When developing for MIDP-1.0 devices, I would suggest you use the WTK1.0.4. You can use WTK2.0, but you must be careful to avoid the extra features. You may also have problems when deploying to a device, as the application's manifest may be marked "MIDP-2.0"; you will need to change this, or MIDP-1.0 devices may reject the application.

Graham.

[artemg]

As a maatter of fact, yes, I am using WTK 2.0, but I was under impression that as per MIDP 1.0 spefication, the setCommandListener method was valid for Alert.

My MIDlet settings specify to use MIDP 1.0 APIs, and in every other case, when trying to use an MIDP 2.0 specification, I WOULD be promopted with an error. This time around, WTK compiles MIDLet without any errors.

Just to get a clear idea. If this method has been somehow left out of the site in WTK, there is no way to add custom commands to the Alert?

If so, is there another way to terminate a running thread? Right now, I have a function, that calls another Displayable after Alert has been dismissed. This brings up the screen that I want, but does not terminate the thread and I get the thread returns later on.

[grahamhughes]

Technically, setCommandListener() is "valid" for Alert in MIDP-1.0, as the method is inherited from Displayable. But the Alert class in MIDP-1.0 overrides this method something like:

public void setCommandListener (CommandListener listener) {
    throw new IllegalStateException ();
}

and the API documentation says "this method will always throw IllegalStateException whenever it is called".

The ability to use this method to add a CommandListener to an Alert is new in MIDP-2.0 - in MIDP-1.0 there is no way to do this.

To the best of my knowledge, there is no way to terminate a thread, other than for it to complete its run() method.

The setCurrent() method of Display can be used to tell the Display to display another screen after the Alert has been dismissed (or times-out). I guess your problem is knowing when this has happened (without a commandAction event). If your next screen is a Canvas, you should get showNotify() and paint() events. Otherwise, the only noticably change would be that the new screen's isShown() method will return true. If your thread is able to check this method, that may be an option. Otherwise, you may have to instruct the thread to end before the Alert is shown.

If none of this helps, then perhaps you could describe the underlying problem? (For example, what the thread is doing, and in what circumstances you need it to terminate.)

Graham.

[artemg]

Thank you very much for your post - it cleared things up.

As far as what I'm trying to do. I have the thread making http connection. Since this operation takes some time, I want the user to see the alert, which informs them that application is trying to connect and presents them with option to cancel operation.

This thread, has a quit() method, that I was hoping to be able to call with a cancel command assigned to the alert.

At this point, with default dismiss command, I get next screen but thread is still alive. Once the thread establishes the connection it forces the screen to change.

I guess isShown() would be one of the ways to work around it. Or I may consider a different screen (e.g. Form) as alternative to alert and add command to that. Thanks again for your help.