In addition to the subtle problem with FrmReturnToForm(0), we've run into one other strange problem with the 3.5 d4 roms posted for quick-click (whatever...) download. On 3.5 Color Release only, we have a sequence of code which is: bmpPtr = MemHandleLock(bmpHandle); RenderSomeDataToTheBitmap(bmpPtr); WinDrawBitmap(bmpPtr, 0, 15); MemPtrUnlock(bmpPtr); POSE a3 and a4 report: <application> 1.0 has just read directly from memory manager data structures. If you hit debug, you are in MemPtrUnlock. Continue seems fine and the app does not crash under stress testing with the warning disabled. Here is the interesting part. Comment out "RenderSomeDataToTheBitmap" - no change. Comment out "WinDrawBitmap" - the error disappears. And this is only in 3.5 Color _release_. Color debug, EZ debug/release, non-Ez debug/release, 3.3 EZ debug/release, 2.0 debug/release, 3.1 release - all fine. The 3.0 SDK sample Beamer exhibits this sample problem - under Color Release only. That sample allocates heap memory and creates its own Bitmap. Presumably, something did not get initialized correctly in the bitmap header which freaks WinDrawBitmap on the color/release version crazy. If I could get the 3.5 SDK, I could see what changed in Beamer, or even test for 3.5 and use the new create-bitmap function I've seen people refer to... I'm trying to be patient, but between waiting weeks and weeks for paperwork to get processed and waiting weeks and weeks for a working CW (the primary reason we upgraded to R6 was for new resource support)... Thanks in advance for the help, -jjf -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palm.com/devzone/mailinglists.html
