Wonderful  :-((( So, it's probably not possible to test and execute in the
same JVM.... That's just great. That's like trying to test code on a
Macintosh and then implement it on a Windows machine directly. Back in the
days before you could run Intel code on Macs and vice versa.

You'd think there'd be some way to test on the same JVM on which you're
going to implement..... In my case, it might be worth asking the best way to
handle this dilemna on the java newsgroup for Palm developers but the
traffic on it was so sparse when I was developing a couple of years ago - a
couple of posts a week - that it was not very useful. But it might be worth
going this way for this issue since it's such a big and important issue.
Perhaps you can do something equivalent for your IPAQ? After all, if the
manufacturers want code developed for their platforms it would seem highly
advisable for them to create emulators that those developers can use and for
those emulators to be the same as the JVMs they're putting on their PDAs.

--
Rhino

"Simon Brooke" <simon@jasmine.org.uk> wrote in message
news:uvc634-6mr.ln1@gododdin.internal.jasmine.org.uk...

For reference, the problem was as follows:

Images were stored in the MIDlet suite JAR file in the directory /images/;
I have verified they were indeed there. They were loaded using

       try
       {
               zoneDisplay =
                       new ImageItem( "Zone",
                               Image.createImage( "/images/closed.png" ),
                               Item.LAYOUT_BOTTOM, "Closed" );
               statusDisplay =
                       new ImageItem( "Status",
                               Image.createImage( "/images/confirm.png" ),
                               Item.LAYOUT_BOTTOM, "OK" );

               form.append( zoneDisplay );
               form.append( statusDisplay );
       }
       catch ( IOException e )
       {
               // ignore
       }

in the MIDlet constructor.

On the Sun Wireless Toolkit emulators, both versions 2.2 and version 2.5,
this worked fine. On the device, the MIDlet failed, with no error message
or other diagnostics.

However, when I removed the images from the directory, leaving the code
unchanged, the MIDlet ran successfully on the device (although without
images, of course).

Images /do/ work on the j9 MIDP installation, because the following method
works:

/**
* Shamelessly cribbed from
* http://java.sun.com/developer/J2METechTips/2001/tt0820.html
*
* @param d the diaplay on which to display thie
* @param next the screen to show next after this
*/
protected void showSplashScreen( Display d, Displayable next )
{
       Image logo = null;

       try
       {
               logo = Image.createImage( "/images/splash.png" );
       }
       catch ( IOException e )
       {
       }

       Alert a =
               new Alert( "Field Inspection Pack",
                       "Fisherman field inspection pack $Revision: 1.4 $ of $Date: 2006/11/21
14:58:35 $ " +
                       "(c) 2006 Simon Brooke\n\n" +
                       "http://www.weft.co.uk/products/fisherman", logo,
                       AlertType.INFO );
       a.setTimeout( 6000 );
       d.setCurrent( a, next );
}

I'm left with the possibilities that

(i) Images cannot be loaded during startup, while the constructor is being
executed, possibly because required structures have not yet been
initialised; or

(ii) There's a bug in the ImageItem constructor.