McCollister, Mike <[EMAIL PROTECTED]> wrote:
> for(i = 0; i < 144; i++) {
> RGBColor.r += 5;
> RGBColor.g -= 3;
> for(j = 0; j < 160; j++) {
> RGBColor.b++;
>
> WinSetForeColorRGB(&RGBColor, NULL);
> WinDrawPixel(topLeft.x, topLeft.y);
>
> topLeft.x++;
> }
> topLeft.x = 0;
> topLeft.y++;
> }
[...]
> Now, when I run it on a real Handspring prism it simply locks up and
> sometimes requires a reset. If I run it on the Handspring POSE 3.0a7 and a
> non-debug ROM, it simply displays nothing and _sometimes_ I have to reset
> but other times I can press some buttons and start some other applications.
> I get no POSE errors when I try to do this on the Handspring ROM.
Summary: it's a bug in the PalmSource prerelease 4.0 SDK and 4.0 DR2 ROMs.
If you look at CoreTraps.h in Handspring's Prism-aware tools and in the
PalmSource prerelease SDK, you'll soon see what's going on. The functions
WinSet{Fore,Back,Text}ColorRGB() and WinGetPixelRGB() are assigned to
0xA3e8--0xA3EB in both sets of headers, but in *different orders*. Oops.
When you compiled your code against the PalmSource SDK, WinSetForeColorRGB
compiled to trap 0xA3E9, which works fine on the DR2 ROM, but on the Prism is
actually a call to the Prism's 0xA3E9 function, namely WinSetBackColorRGB.
So on a Prism your loop above is actually varying the background colour,
which isn't being used, and labouriously drawing each pixel in the
previous foreground colour, probably white. It takes a while to plot
invisible pixels and set unused colours 23,040 times, so it looks like the
device has gone into an infinite loop. But it hasn't. Everything's fine.
This is fixed in the 4.0 SDK now, but unfortunately it wasn't fixed in
time to go on the PalmSource CD. So the final 4.0 SDK will certainly
be able to build programs for the Prism and all will be well; if there's
going to be a DR3 prerelease on the Pavilion it'll be fixed in that too
(but I don't know if that's planned or if so what the schedule might be).
So what does this mean right now?
You can write programs using these four calls with the PalmSource SDK and
test them on the DR2 ROMs. But they won't work correctly on anything but
the DR2 ROMs: to run them on a Prism or on a DR3 ROM or whatever you'll
need to recompile your code against corrected headers.
Welcome to the wonderful world of prerelease software! :-)
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/