Conference bulova::decw_jan-89_to_nov-90

The following get deallocated (viz XFree...) when XtDestroyWidget is called.

  - pixmaps for icons

  - fonts

  - gc (graphic context)

Kris..

    Interesting, so one had better create a separate pixmap for every
    icon used, even if the icon is always the same.  I am referring
    to the XtNiconPixmap and the XtNiconifyPixmap that I set for the
    window manager.
    
    						Thanks,
    						-Dave

    Maybe I don't understand what you mean -- The window manager treats
    each icon as a different icon - even if you want the pixmap to 
    look the same.   
    
    The only time window manager uses the same pixmap (in the same
    application) for something is with XtNiconifyPixmap.
    The "shrink to icon" button next to the window's title bar
    is the same pixmap as when you are using "small icons" in
    the icon box (by setting the toggle in the customize window
    menu in session manager).  They both use XtNiconifyPixmap.
    
    
    

    When you destroy a widget does all the memory it points to get
    freed up? For instance, if you have a list box that has several
    entries in it, and then destroy the list box, does the memory for
    the strings get freed by DECwindows (or X), as well? 

    Thanks in advance,
    William

    Re: .3
    
    If I say pixmap = XCreateBitmapFromData and then use that single
    pixmap to set the iconify button for multiple widgets, I am wondering
    what happens to that pixmap when I destroy one of the widgets. 
    Setting the icon and then destroying the widget seems to cause the
    window manager to get blown away sometime later.  All XtSetArgs are
    being passed the same pixmap for XtNiconifyPixmap.  Note that this
    has gotten worse since going to VMS V5.1-1.
    
    That was my reason for asking for detail on what actually happens.
    I have to be able to reliably destroy widgets without corrupting
    memory.  That pixmap is being used by the window manager, so I need
    to know what happens in the window manager.
    
    						-Dave

    If you pass the same pixmap N number of times (via XtSetArg)
    for N  number of widgets,  then the window manager will
    retain N number of pixmaps in its memory.

    Interesting, I wonder if something is broken in the window manager
    in VMS V5.1-1.  I still suspect I am screwing up a pointer somewhere,
    it is just a tough thing to find.
    
    What happens to the string in the title bar?  I use DwtLatin1String to
    allocate a unique one for each widget, does the window manager allocate
    its own copy of that as well, or will it attempt to XtFree the pointer
    I passed to it? 
    
    						Thanks for the help,
    						-Dave

    Each title is cached as well.
    
    Did you say that the window manager crashes?

    Yes, the window manager crashes.  I am trying to track down a couple
    bugs right now, if I get an easily reproducible case I will post
    some code to cause it.
    
    Where does the window manager dump crash information?
    
    						-Dave

Title bars use normal strings not compound strings, are you setting the title
with a compound string?

Neal

Regarding pixmaps, the X server keeps a reference count of things that refer
to the same pixmap.  If you create two windows with the same background
pixmap, for example, the server only keeps one copy of the pixmap in its
memory, but that pixmap has a reference count of 2.  If you destroy one of
the windows, the pixmap will still be around.  It doesn't go away for good
until both windows are destroyed.

Regarding the toolkit, if you pass pointers to strings (compound or regular)
via XSetValues, the toolkit copies the strings into its own memory.  You are
responsible for doing a free() or XtFree() to release the string memory for
your copies of the strings.  The toolkit works entirely from its own copies.
It tries to free up all of the resources that it allocates, including all
heap memory.  I say "tries" because there are bugs in the toolkit where it
drops memory on the floor.  These don't result in ACCVIOs or anything nasty
like that, though--they just cause you to run out of virtual address space
eventually.

--PSW

    Re: .10
    
    DwtNtitle is a DwtCompString.  XtNiconName is a char *.  That is
    how I set them.  If DwtNtitle is not supposed to be a DwtCompString
    then a lot of documentation is wrong, or the implementation is
    inconsistent.
    
    Re: .11
    
    Thanks for the explanation.
    
    						-Dave

Re: .12

>    DwtNtitle is a DwtCompString.  XtNiconName is a char *.  That is
>    how I set them.  If DwtNtitle is not supposed to be a DwtCompString
>    then a lot of documentation is wrong, or the implementation is
>    inconsistent.

Where did you read that?  In VMS DECwindows Programming Volume 1B, Toolkit
Reference Manual, page 2-12 it gives the usage for the title attribute
as "char string", and on page 2-14 it says "char *title".

				-- Bob

    I was going by some of the widget argument definitions from the
    ULTRIX doc set.  In the UWS Guide to the XUI Toolkit: C Language
    Binding on page 3-41 it shows Dwtntitle as being a DwtCompString
    for the Scale Widget, or any other widget that one wants to look
    up.
    
    Maybe the difference is VAX bindings vs. C bindings.  I never
    received the VMS DECwindows Doc set from ADS, so I don't normally
    reference those manuals.
    
    It seems that one of the early mistakes I made was to try to use
    a char * rather than a DwtCompString.
    
    Are you talking about VMS bindings or MIT bindings?
    
    						-Dave

Re: .14

>    I was going by some of the widget argument definitions from the
>    ULTRIX doc set.  In the UWS Guide to the XUI Toolkit: C Language
>    Binding on page 3-41 it shows Dwtntitle as being a DwtCompString
>    for the Scale Widget, or any other widget that one wants to look
>    up.
    
Hmmm... This must be a mistake in the Ultrix documentation, since otherwise
DECterm wouldn't be able to set the title on Ultrix.  Look at the
definition of WMShellPart on page 4-5 of the XUI Toolkit Intrinsics Manual
(UWS Programming Volume 3); "String" is the same as "char *".

>    Maybe the difference is VAX bindings vs. C bindings.

No, one of the VMS references I gave was for the VAX binding and the
other was for the C binding.

>    It seems that one of the early mistakes I made was to try to use
>    a char * rather than a DwtCompString.
    
Are you saying that DwtCompString works?  If it doesn't, I'd try using
String.  It's possible that the title changed from DwtCompString to
String at some point during V1 development (although I don't remember that
happening); that would account for the contradictions in the UWS doc set.

				-- Bob

    It has been working just fine, so I don't know what the story is.
    I would expect to get a lot of garbage in my titles if it really
    wanted a "char *".
    
    						-Dave

    no - its not a doc mistake, its a toolkit 'ism.  DwtNtitle is indeed
    a c null-terminated string resource for popup dialog boxes.  Its
    passed to the window manager, which only supports asciz strings.
    
    Scale widget also has a resource named DwtNtitle, but it has nothing to 
    do with the window manager. It is simply the scale 'title'.
    
    These are two very different resources that unfortunately have the same 
    name.
    
    Jay

    I just tried using "char *" and the window title didn't change.
    This was on VMS.
    
    						-Dave

    The title is actually a property of the window -
    Right now the property type that is supported
    is string - there has not been defined a compound
    string property type atom.  (We are working on this issue)
    
    So when the window manager gets the property which
    contains title (icon label has the same issue) it receives
    it in ascii string format (not compound string/text/ddif/or
    whatever).
    
    The titles are actually label widgets so it is feasible to
    put different formats into a label,  but it (window manager)
    has to get it that way to begin with.       

    There is DwtNtitle and XtNtitle...
    
    DwtNtitle is a resource of DECtoolkit widgets and is a compound
    string.  The Dialog Box widget turns this into a char * before
    handing off to the window manager.
    
    XtNtitle is a resource of Intrinsic's shell widgets and is a char *.
    Remember that the Intrinsics know nothing about compound strings...
    
    So, I don't think the documentation is wrong, but it is easy to
    see how people will get confused.
    
    Leo