Conference bulova::decw_jan-89_to_nov-90

How many planes does your Firefox have?

Furthermore, the correct way to change a resource on a toolkit widget is to
use XtSetValues to change the pixel value of the background resource on the
widget, not XSetWindowBackground on the widget's window.  But it looks like
your real problem is storing the color map entry.  If you've got a 24-plane,
true color system, then the default visual probably doesn't allow XStoreColor
to be done, nor does it make sense on a true color system.  You don't seem to
be checking the status from XAllocColorCells.  You should make sure that you
successfully allocated the cells before you try to store into them.

--PSW

    Yup, I do have a 24 plane FIREFOX.  If there is an easier way to
    change the color of a dialog box at execution time I am willing
    to change my ways.  However, it took me a week to figure out how
    to get it to happen at all on the 3200.  The issue of changing colors
    on any system is quite confusing and the DECWindows documentation
    unfortunately does not shed enough light on this subject.  I will
    definitely check my status values.  I have tried SET ARG along with
    anything else I could think of.  I will research this further and
    will post any new results.  In the mean time, a good example of
    how to do this on a FIREFOX would be extremely beneficial.
    
    Thanks for the quick response
    
    Mike

I think that the default visual on a 24-plane Firefox is a TrueColor visual,
in which case all of the "colormap entries" are read-only.  Try building the
XColor structure as you do now and then calling XAllocColor passing that
structure.  You will get back the pixel value for the color closest to the one
you requested.  You should then be able to do a XtSetValues on the
DwtNbackground resource for the widget using that pixel value to have the
background color take effect.  You can't use XAllocColorCells and XStoreColor
because a TrueColor colormap is read-only (in fact, the hardware doesn't have
a color map per se, but uses the pixel value to encode the RGB values
directly.

--PSW

Great your suggestion worked.  I did have a problem with STORE_COLORS and
SET_WINDOW_BACKGROUND.  However, I also discovered the basic problem that I
had with using VMS_SET_ARG and XT_SET_VALUES.  There are two Ada bindings for
routine VMS_SET_ARG in the DECW$ package.  In one binding, the first argument
is an address and in the second binding, the first argument is an integer.
Since Ada is strongly typed and since a COLR_PIXEL is an UNSIGNED integer,
neither binding was correct.  In several other instances, using the address
binding was appropriate so that is what I used.  This DOES NOT WORK FOR
CHANGING COLOR ATTRIBUTES.  In stead I converted the the UNSIGNED COLR_PIXEL
type to an integer, used the second Ada binding and it worked.  Now what I read
in the manual seems to make much more sense.

Thanks for your quick suggestions.

Mike

Re: .4

We couldn't provide an additional signature with type UNSIGNED_LONGWORD
because then it would be ambiguous if you just specified a constant.
So using the builtin conversion function to INTEGER is what you need to
do.

				Steve

Re: .5

No question, I just didn't use the right stuff.  Sorry if it sounded like 
a hit on Ada.  It was my misuse of the Ada binding.

Mike

No "hit" was assumed.  I just wanted to explain why it was the way it was,
for the potential benefit of other Ada programmers.

		Steve