Florent,
0x80000000 jogged my memory and a search turned up the email of Bob Ebert in January
that seems relevant to your situation. It
follows.
Keith Wolcott
Subject:
Re: Using UI Color Table functions
Date:
Tue, 25 Jan 2000 18:14:46 +0100
From:
Bob Ebert <[EMAIL PROTECTED]>
Reply-To:
"Palm Developer Forum" <[EMAIL PROTECTED]>
To:
"Palm Developer Forum" <[EMAIL PROTECTED]>
CC:
[EMAIL PROTECTED], [EMAIL PROTECTED]
At 3:30 AM +0100 25-01-00, Mike Davis wrote:
>I just downloaded (today) the most recent color debug ROMs. I have
>the same problem.
Rats.
You will always have this problem on Debug ROMs. There is a bug that
slipped through. (Which I just now noticed thanks to your problem report.)
Background: On DEBUG ROMs only, when someone sets the draw window to NULL,
we instead set it to an invalid address. (0x80000000) We did this
deliberately so that we would immediately catch any code that tries to draw
too soon, or otherwise use the the DrawWindow when it is invalid. That is,
instead of reading/writing through NULL (which works), now it tries to read
through an invalid address and immediately generates a bus error.
Before I go on, I should say that this was a very good idea, and it helped
us catch a lot of drawing problems related to the bad draw window.
HOWEVER, in the case of WinRGBToIndex, that function tests to see that the
draw window is non-NULL before using it. If it is NULL (invalid), then it
goes directly to the screen hardware to get the palette. That is,
WinRGBToIndex is intended to work even when the DrawWindow is not valid.
UNFORTUNATELY (you can see this coming, right), the 'bad address' that we
set the draw window to is not NULL, so WinRGBToIndex thinks the draw window
is valid and tries to use it... and then boom, you get the bus error.
Obviously we need to find the few places where the OS tests the draw window
against NULL and make sure it *also* tests against the invalid address.
Sigh... I don't know what to tell you for now. We blew it. The code will
work fine on RELEASE ROMs. Until then... well, I suppose you can work
around this by explicitly setting the draw window to something valid before
calling the UI color set function. I think you should do this:
WinSetDrawWindow(WinGetDisplayWindow());
This will force the draw window to be the 'root' window for the OS, which
is the full screen. The palette for this window will always be the same as
the hardware. It's better to do this than to set the draw window to your
form, because you might have a better chance of catching draw-too-early
bugs this way.
--Bob
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
