In my app, I call UIPickColor to let the user change a color, and it's fine in all
cases I've tried except on a 5.0 handheld set to 16-bit color (I'm using a Zire71). In
that case, the screen goes white and the machine goes dead - pin reset required. It
dies inside UIPickColor.
OK, so then I made a starter app that ONLY calls UIPickColor, and it works fine, so
I'm positive this is my fault :-) But I can't figure out why!
How can I possibly be wedging the machine by calling UIPickcolor? I know the
parameters are all good. Does anybody have any clues?
Here's the code, for what it's worth:
// UIPickColor changes the draw state without asking (!?!),
// so save it and restore it
WinPushDrawState();
// Let user pick a color
// gEqnColors is an IndexedColorType array
RGBColorType rgbColor;
WinIndexToRGB( gEqnColors[swatchHit], &rgbColor );
Boolean newColor = UIPickColor( &gEqnColors[swatchHit], &rgbColor,
UIPickColorStartPalette, NULL, NULL );
WinPopDrawState();
// Always update the entire form, since the color picker does nasty
// stuff behind our backs, especially in 16 bit.
FrmUpdateForm( FrmGetActiveFormID(), kEqnChanged );
Thanks,
Dave Johnson
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
