Palm OS Emulator problem

Question

hi all,
the problem i've got has something to do with the refreshing of my Midlet's display.
I've got two "Displayables" one Canvas and one TextBox, first i set the Canvas (with an image) as the current object on my display, it works fine, the problem is that i've got a command in the Canvas that when pressed it change the midletsdisplay.setCurrent(TextBox).
If i run this midlet with the ktoolbar application everything works fine, but if i run it with the Palm Os Emulator 3.3 the Canvas is not removed from the display and i cant see the TextBox.... any ideas?
thank you,
Laura.

Answer 1

[LauraD],
What you are seeing with the Display.setCurrent() method is explained in the MIDP API documentation. There isn't a website that I can point you to the online, so I have taken the liberty to cut n paste the setCurrent() API documentation explanation of its usage:
setCurrent
public void setCurrent(Displayable nextDisplayable)Requests that a different Displayable object be made visible on the display. The change will typically not take effect immediately. It may be delayed so that it occurs between event delivery method calls, although it is not guaranteed to occur before the next event delivery method is called. The setCurrent() method returns immediately, without waiting for the change to take place. Because of this delay, a call to getCurrent() shortly after a call to setCurrent() is unlikely to return the value passed to setCurrent().
Calls to setCurrent() are not queued. A delayed request made by a setCurrent() call may be superseded by a subsequent call to setCurrent(). For example, if screen S1 is current, then
         d.setCurrent(S2);
         d.setCurrent(S3); may eventually result in S3 being made current, bypassing S2 entirely.
When a MIDlet application is first started, there is no current Displayable object. It is the responsibility of the application to ensure that a Displayable is visible and can interact with the user at all times. Therefore, the application should always call setCurrent() as part of its initialization.
The application may pass null as the argument to setCurrent(). This does not have the effect of setting the current Displayable to null; instead, the current Displayable remains unchanged. However, the application management software may interpret this call as a hint from the application that it is requesting to be placed into the background. Similarly, if the application is in the background, passing a non-null reference to setCurrent() may be interpreted by the application management software as a hint that the application is requesting to be brought to the foreground. The request should be considered to be made even if the current Displayable is passed to the setCurrent(). For example, the code
         d.setCurrent(d.getCurrent()); generally will have no effect other than requesting that the application be brought to the foreground. These requests are only hints, and there is no requirement that the application management software comply with these requests in a timely fashion if at all.
If the Displayable passed to setCurrent() is an Alert, the previous Displayable is restored after the Alert has been dismissed. The effect is as if setCurrent(Alert, getCurrent()) had been called. Note that this will result in an exception being thrown if the current Displayable is already an alert.
To specify the Displayable to be shown after an Alert is dismissed, the application should use the setCurrent(Alert, Displayable) method. If the application calls setCurrent() while an Alert is current, the Alert is removed from the display and any timer it may have set is cancelled.
If the application calls setCurrent() while a system screen is active, the effect may be delayed until after the system screen is dismissed. The implementation may choose to interpret setCurrent() in such a situation as a request to cancel the effect of the system screen, regardless of whether setCurrent() has been delayed.
Parameters:
nextDisplayable - the Displayable requested to be made current; null is allowed.
So as you can see, setCurrent() requests are only hints as explained in the documentation. There is no requirement that the Java Application Management software comply with these requests in a timely fashion ,if at all. Therefore what it means for you is that the JAM implemented for the wireless toolkit inteprets the call to setCurrent() differently than the Palm OS application management software which is running on the Palm OS operating system. Suffice to say, this does not mean that the MIDP implementation for the Palm OS is non compliant, it just means that the different runtime environment inteprets setCurrent() differently since calling the method is just a hint to the system to bring the Displayble object to the foreground.
It will be helpful if you can post snippets of the code for us to examine and suggest a way to workaround your issue.
HTH.
Allen Lai
Developer Technical Support
SUN Microsystems
http://www.sun.com/developers/support/