Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!bloom-beacon!SHAMASH.MCRCIM.MCGILL.EDU!mouse
From: mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  How do I use a read/write color cell?
Message-ID: <9009271332.AA12772@shamash.McRCIM.McGill.EDU>
Date: 27 Sep 90 13:32:31 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 80

[Code examples edited to compress this posting -dM]

> [...] the background color inside a window will change dynamically.

> I made a call to XAllocColorCells to allocate one read/write color
> cell.  The call looks like:

>    unsigned long *plane_masks = 0 ;
>    int rtn = XAllocColorCells (dsp, cmap, True, plane_masks, 0, &pixel, 1) ;

Well, there's no need to make plane_masks a variable, but that's not a
problem (except perhaps in a stylistic sense).

> This seems to yield a valid value for "pixel" usually something "25".
> I also check the return code and it never comes back "0", so it seems
> like this part works okay.  Later I call XStoreColor to initialize
> the color cell to "black":

>    XColor xc ;
>    xc.pixel = pixel ; xc.red = xc.green = xc.blue = 0 ;
>    xc.flags = DoRed | DoGreen | DoBlue ;
>    XStoreColor (dsp, cmap, &xc) ;

> As far as I can tell, this works.  [...]

This looks entirely reasonable, assuming cmap is something sensible
(you don't say where you get cmap from).

> Once I've allocated this, I assign the background color of an
> OpenLook Static Text widget to use the "pixel" I got from the
> previous call.  This looks like:

>    XFreeColors (dsp, cmap, old_pixel_value, 1, 0) ;   /* Free previous color */
>    XColor xc ;
>    xc.pixel = new_pixel ;    /* Pixel value obtained from XAllocColorCells */
>    int rtn = XAllocColor (dsp, cmap, &xc) ;
>    /* Build an Xt Args list with XtNbackground set to "new_pixel" */
>    /* Use XtSetValues to set the widget background color to "new_pixel" */

This looks most peculiar.  Where are you getting old_pixel_value from
and why are you freeing it?  (Also, shouldn't it be &old_pixel_value?
Without a declaration for old_pixel_value I can't be sure.)

XAllocColor allocates a read-only color cell.  You don't say what
you're setting the red/green/blue fields of xc to, so I can't say what
sort of color you're allocating.  The Xlib documentation I have does
not explicitly say what XAllocColor does with the pixel field of the
XColor structure passed in; UTSLing tells me that it is completely
ignored.

However, this shouldn't matter, because you ignore the allocated
read-only cell and proceed to use the read-write cell you allocated
earlier with XAllocColorCells.

> Later, in the callback function for the slider, I call XStoreColor
> again to set a new RGB value for the "pixel".  It is  identical to
> the one above except only one field is set and "flags" is set
> correspondingly.  I also left-shift the color by 8 (<< 8) before I
> call XStoreColor.

(Presumably the value before the left-shift is [0..255].)  I assume the
cell you are trying to store into in the callback is the one from
XAllocColorCells.  The only thing that comes to mind then is, are you
sure the widget's window is using the same colormap as the one you
allocated your read-write cell in?  You don't say where you get the
"cmap" you pass to all these functions.

It might be informative to start off with something other than black.
Pick a color that's not normally present on your screen and set the
color to that initially, instead of black.  If you then still see black
this should tell you something - just what depends on where you see
black when you expect the other color.

If you still have trouble, I'd be glad to discuss it via email (so as
to avoid annoying everyone on xpert with a debugging session :-).

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu