To all module developers,

  A number of 3rd party AD module developers (including myself!) have 
noticed that modules they had created which involved creating and using 
a custom palette were suddenly GPF'ing when AD 3.0 would wake up 
(DoClose()). These modules had previously worked OK under AD 2.0.  
  
  So what's up?  Well, after some very helpful feedback from the 
Berkeley engineers (special thanks to Strike!), I came up with a set of 
steps for properly handling custom palettes, which if followed, seem to 
clear up the problem, and now AD 3.0 is happy with our modules, and no 
more GPF's!

  These are undoubtedly the proper methods of handling custom palettes 
in AD, but AD 2.0 let you get away with less, while AD 3.0 is more 
fussy, and keeps you honest!


Basically, you need to :


1) if the lpSystem->bPalAvail flag is TRUE, set it to FALSE before 
creating your custom palette:

	if (lpSystem->bPalAvail == TRUE)
	    lpSystem->bPalAvail = FALSE;


2) create your palette, save the handle to the previous palette as the 
return value from SelectPalette(), and then realize your new palette 
into the AD device context (hDC).

  static LOGPALETTE huge *lpLogPal ; 
  static HPALETTE hPal;      
  static HPALETTE hOldPal;      

	// assumes lpLogPal is already allocated and locked 
	hPal = CreatePalette((LOGPALETTE FAR*) lpLogPal);
	hOldPal = SelectPalette(hDC, hPal, FALSE);
	RealizePalette(hDC);


3) and when you close (in DoCLose()) you need to :

	UnrealizeObject(hOldPal);
	SelectPalette(hDC, hOldPal, FALSE);
	RealizePalette(hOldPal);

  and THEN you can :

	DeleteObject(hPal);


  It would probably also be good karma to reset the lpSystem->bPalAvail 
flag back to TRUE, as you did earlier force it to be FALSE. 

	if (lpSystem->bPalAvail == FALSE)
	    lpSystem->bPalAvail = TRUE;


  The 3 steps previous to DeleteObject(hPal) are the key to success, 
I believe...

  
  I'd appreciate feedback from anyone out there if you think I am giving 
some incorrect (and / or incomplete) information here.

  I hope this has helped!


-- Jim Signorile


James V. Signorile

jsignorile@earthlink.net
http://pixeldreams.com/

*************************************************** 
Do not follow where the path may lead,
go instead where there is no path and leave a trail.
***************************************************