Thanks for the 16-bit color warning! It turns out that I have been using Sony's Clie Simulator (since all my high res work had been for Clies), and apparently this problem is only with Sony. When I tried the genuine PalmOS emulator, I WAS able to access the screen. So now I'm waiting and hoping to hear back from Sony tech support - I hope this problem is just their emulator and not their devices!
- Jeff --- In [EMAIL PROTECTED], Carsten <[EMAIL PROTECTED]> wrote: > Jeffrey Diamond wrote: > > > Under PACE, when I get the screen address, using > > either address = WinScreenLock, or by using address = > > BmpGetBits(WinGetBitmap(WinGetDisplayWindow())), I get > > pointed to a RAM buffer at $a40000. > > > > I can write to this buffer with no issues, but have > > not found anyway to make this buffer actually appear > > on the real screen. > > > > For me both methods work fine. > You should take care when using WinScreenLock. > It returns a pointer to the -not visible- screen (double-buffering) and > this screen will > become 'visible' calling WinScreenUnlock. (after performing your drawing > operations) > > Using the WinGetDisplayWindow ... etc. method works for me always too. > > Note: There seems to be a bug in the WinScreenLock function - in 16bpp > mode the returned pointer to > the screen is WRONG. WinGetDisplayWindow... etc. returns a correct > pointer. > > > Carsten. > > > > > -- > For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
