Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ames!think.com!sdd.hp.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!ucdavis!csusac!unify!openlook!openlook-request
From: sane!genmri!doug@crdgw1.ge.com (Doug Becker)
Newsgroups: comp.windows.open-look
Subject: Re: ***!?! Help needed with re-use of Xview colourmaps !?!***
Message-ID: <2r6su2y@openlook.Unify.Com>
Date: 29 May 91 20:37:51 GMT
Lines: 29


    > I have a base application which in turn executes (in turn) a number
    > of Xview applications. Each of these applications uses its own
    > (statically allocated) palette, and it is here that the problem
    > arises...
    
    If you're using olwm/olvwm, here's a section from the man page that might help:
    
I don't think you answered the original poster's question (which I read as,
"Why isn't xv_destroy really destroying my application's colormap?").

I also ran into this problem some months ago, but didn't (and don't) have
the time to investigate it.  (I worked around it by reusing the existing
colormap rather than cyclically creating and destroying Cmses.)  My app
created a 128-entry read-write colormap, destroyed it, then created a new
one.  XView apparently thought that the old (destroyed) segment was still
in use, and forced my second Cms' color cells out of the default colormap
on our 8-bit (PseudoColor) displays.

Because of several other peculiarities I've observed, I have a hunch that
this problem stems from xv_destroy not destroying things properly.  I'd be
interested in hearing about any acknowledgments of or fixes to this
problem.

-- 

Doug Becker
doug@nmri.ge.com
crdgw1!sane!doug