Conference bulova::decw_jan-89_to_nov-90

    In the first case, the colormap is not being "installed".  There is
    only one colormap in GPX hardware.  If you are using multiple cmaps,
    the server has to know which one to actually load into the hardware.
    
    According to convention, the window manager is in charge of installing
    colormaps.  When you click on a window, the window manager should
    insure that its colormap is installed.  Have you tried that?
    
    I don't know about the last one.  I especially don't know what is the
    business about "40 colormap entries".  There are normally only a few
    10s of colors used when you first log in (at most).  Indeed,
    AllocNamedColor can allocate from all the rest of them (200+).  And
    even if it can't allocate, it should not accvio.
    
    Burns
    

    Are you creating a window widget and then trying to set the colormap
    for that widget?  If so, I've been similarly unsuccessful at getting
    the colormap installed.  The colormap is being set for both a popup
    shell widget and the actual window widget underneath it (there's a main
    window widget between).
    
    George Chaltas had this problem a while back and said that he got
    around it by specifying the colormap in the override arglist in the
    call to create the shell widget.  That's what I'm trying but without
    success.
    
    Attempting a manual install of the colormap is thrown out by the window
    manager - as expected.  Clicking in the window doesn't do a thing. 
    I've been forced to kill the window manager, run some tests, restart
    DECwindows, change the program, kill the window manager, run some
    tests...
    
    Anybody know how to restart just the window manager?
    
John

    Can I suggest that it is improper to:
    
    (a) Count the number of colors already reserved by DW software,
    (b) Subtract that from 256,
    (c) Code the difference as a constant in your program.
    
    This sounds suspiciously like those programs that design record
    structures after determining the exact bytes-per-bucket used by RMS
    or equivalent.  A sure way to lose big when a FMR takes up just one
    more byte or color or whatever...
    
      John

Ahh..I just remembered some toolkit lore.  The window manager only notices
colormaps in the top level window.  As someone above implied, you must
set the colormap into the shell widget, and not some subwindow that you
happen to own.

Burns

>Ahh..I just remembered some toolkit lore.  The window manager only notices
>colormaps in the top level window.  As someone above implied, you must
>set the colormap into the shell widget, and not some subwindow that you
>happen to own.
    
    Yeah.  That's what I tried that didn't work.  I'm also creating an
    application shell widget so that I can connect to multiple
    workstations.  Is this going to complicate my life?  It certainly
    appears to.
    
    Of course, I'm also setting the colormap for the window widget itself. 
    Maybe I ought to drop that and see what happens...
    
John

    With regard to reply .3:                                   
    Well of course I don't count colors and hardcode anything into my
    program, and frankly I can't imagine who would.
    My tests of allocate named colors began at 50 and I worked my way
    back through access violations, Xlib IO errors, and so on until
    somewhere around 20 named colors all problems went away.  By the
    way, at around 30 named colors I didn't get access violations or
    IO errors, but I did get pixmap garbage (a smattering of the other
    pixmaps used by my program) in the upper left of the graphics window,
    even though I fill the graphics window pixmap with black before I 
    draw to it. This problem also disappeared when I reduced the named
    colors to 15.
    
    With regard to .1, .2, and so on:
    Yes, I create a window widget and then try to set its colormap.  And
    yes, I have clicked on the window, and panned the contents of the
    window, all to no avail, the new colormap is not installed.  I did
    in an earlier attempt try creating a new standard colormap and 
    setting it to the root window, but I haven't tried setting my new
    colormap to my program's top level window, so I will do that and 
    see what happens.

Not that there are any great answers there either (yet); but a cross reference
never-the-less.

    No success setting the new colormap to the program's main window.
    
    Meanwhile, something very disconcerting with named colors:  one choice
    in my program is to draw the graphics image with named colors, and I
    use four rather unusual named colors to do it (orchid, goldenrod,
    and so on).  It happened that I got tired of some of my own session
    colors and went into the session manager to recustomize my highlight
    color.  The next time I ran the program, the set of graphics objects 
    that were drawn in the color orchid disappeared. To see what was going 
    on, I tried using the color firebrick instead of orchid, and just as 
    inexplicably that set of graphics objects was back (drawn of course in 
    firebrick).  
    
    This does not give me a reassuring feeling about named colors, to say
    the least.  It would appear that session color settings can affect
    how named colors are represented - possibly orchid was turned to black?
    (The graphics background is black.)  Or possibly the RGB of orchid was
    changed so that it no longer appeared against black?  Or ???  In fact
    I have trouble visualizing what was going on. 
    
    Any thoughts?  Has anyone else observed this?
      

    I got my program to work with its own colormap.  Sort of.
    
    I specified the colormap as an override argument when I created my
    shell and then proceeded to do a XSetWindowColormap on each of the
    three windows of my widget hierarchy: Shell, Main and Window.  This
    seems to get the point across to all concerned parties.  I can't tell
    if setting the colormap on the mail makes any difference.  Resources
    seem to be reused in such a way that even incorrectly written programs
    can work...
    
    The catch is that everything works perfectly - but only once.  My
    application creates a display connection and then, when the user gets
    into the color part of the application I create a colormap, load it up,
    bind it to the windows and everything is hunky dorey.  Naturally, it
    requires a mouseclick to get the window manager to install the
    colormaps.
    
    When the color part is exited I delete the colormap and the windows. 
    Not the display connection.
    
    But the user can go back into the color part again.  So I recreate the
    colormap and windows and bind them all up the same way.  But the second
    and perhaps third times, it won't work.  Try a couple more times after
    that and everything works as expected.
    
    I'm reasonably sure it's not me - famous last words.  It also doesn't
    seem to have anything to do with the window manager as I've had this
    problem while running without a window manager as well.  If I can nail
    this down, I'm going to submit a couple QARs.
    
John

My program has gotten a little farther using XCOPYCOLORMAPANDFREE()
(or something like that). This lets me load the colormap and see them on
the screen; however, I also suffer from the once in a row problem in .-1.

I cannot unload the colormap and go back to the default after I am done
hogging all the colors.

>    I'm reasonably sure it's not me - famous last words.  It also doesn't
>    seem to have anything to do with the window manager as I've had this
>    problem while running without a window manager as well.  If I can nail
>    this down, I'm going to submit a couple QARs.
    
    It's me.  I now have an application which uses a private colormap
    without any problems except for the color of the window's icons and
    banner.  Anybody know how to set those?  Does the window manager use
    BlackPixel and WhitePixel?
    
    The on-again/off-again behavior I was getting was due to the background
    of the window being undefined.  If it happened to be zero, things
    worked out.  Most of the time it was something else and my application
    went haywire.  Now I set it explicitly.
    
John

The following code fragements show what I have done so far to get colormap
loading to work. Note: I have not been able to get my dialog boxes to load the
new color map yet- both ones already on the screen and new ones brought up
with FetchWidgetOverride() are not showing up with the new colormap working yet.


    wTopLevel      = XtInitialize();
    lDisplay	   = XtDisplay( wTopLevel );
    pMainWindowID  = XtWindow((Widget)wTopLevel);

    iScrn          = DefaultScreen (lDisplay);
    cmColormapID   = XDefaultColormap(lDisplay, iScrn);
    cmColormapID   = XCopyColormapAndFree(lDisplay, cmColormapID);

    SetAttribute(wTopLevel, DwtNcolormap, cmColormapID );
    SetAttribute(pMainWidgetID, DwtNcolormap, cmColormapID );
    XSetWindowColormap(lDisplay, pMainWindowID, cmColormapID);