display thread

My testing seems to show that the initial thread that is created in the vm and executes the commandAction callback must return before the display can be changed. Therefore it is not possible to change the screen within this thread and see that screen change until the thread returns to the vm. This seems to be the case on the wireless toolkit emulators, the motorola emulator and the i85s phone. Is this accurate?
Does anyone have any experience putting up a busy wait screen while a long running network operation is taking place? I would like to have the different parts of the application make a serial call to a communications piece that could put up a busy wait screen while it waited for the query response, bu this is not possible if you just use the main thread. So the alternative seems to be to use another thread and thus be able to return the system thread which then allows the screen to be changed.
Does anyone know if this is a MIDP/J2ME spec thing or just a vendor implementation?
thanks
stephen cole

This is normal and expected behavior. It's a common user interface model: one thread services the user interface and other threads do lengthy things like networking. In Swing on J2SE, for example, you have to do *everything* UI related on one particular thread. MIDP doesn't have that limitation, but yes, callbacks and such occur on a single thread and any changes you make to the display won't occur until you return from that thread and the system gets control. So design your apps accordingly -- do all the networking on a separate thread. If you look at the J2ME Tech Tips I write (see http://www.j2medeveloper.com) I have at least one tip that talks about this with examples.