jerryl@is.Morgan.COM (Jerry Liebelson) (05/14/91)
Hi -- We have an application the needs to show the same XmList with the same data in more than one place. The list is not very big and we don't want put it in a popup. But it's also cumbersome and inefficient and to manage multiple instances if the widget. QUESTION: Is there an efficient, trouble-free way to unmanage and re-manage once instance of this XmList under different parent container widgets, which themselves might be contained within different shell widgets? -- |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | Jerry Liebelson | EMAIL: jerryl@is.morgan.com | | Information Systems | uunet!is.morgan.com!jerryl | | Morgan Stanley, Inc. | VOICE: (212) 703-2409 | | 1633 Broadway 36th Floor | FAX: (212) 703-2371 | | New York, NY 10019 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tjhorton@vis.toronto.edu ("Timothy J. Horton") (05/16/91)
jerryl@is.Morgan.COM (Jerry Liebelson) writes: > We have an application the needs to show the same XmList with the same >data in more than one place. The list is not very big and we don't want >put it in a popup. But it's also cumbersome and inefficient and to manage >multiple instances if the widget. > QUESTION: Is there an efficient, trouble-free way to unmanage and re-manage >once instance of this XmList under different parent container widgets, which >themselves might be contained within different shell widgets? XtReparent (I think that's what it's called -- no books nearby).
david@lta.lta.com (05/16/91)
> XtReparent (I think that's what it's called -- no books nearby).
Would that it were; there is no such function.
However, Martin last year posted a limited-use ReparentWidget function which
functions by directly inserting children into the composite's child array;
similar code was posted by other people. Other discussion (on comp.windows.x)
pointed out general difficulties with reloading the resource database,
particularly if the widget being reparented has children.
--
David B. Lewis Lewis, Trachtenberg & Associates (LTA)
Note new address!: david@lta.com +1 617 225 0366
Your Ad Here! This space for rent.kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) (05/16/91)
In article tjhorton@vis.toronto.edu ("Timothy J. Horton") writes: >jerryl@is.Morgan.COM (Jerry Liebelson) writes: >> QUESTION: Is there an efficient, trouble-free way to unmanage and re-manage >>once instance of this XmList under different parent container widgets, which >>themselves might be contained within different shell widgets? > >XtReparent (I think that's what it's called -- no books nearby). This fits into the category of dis-information. There is no XtReparent(). And there is no easy, nor clean way to reparent widgets. This is not my opinion, but an echo of something Schliefer/Gettys/Converse/et. al. have said in months gone by. One possible solution would be to GetValues() the XmNitems resource from one and SetValues() it onto the other. Since this is fast and simple, it's the way I would go. -- Kaleb Keithley kaleb@thyme.jpl.nasa.gov Meep Meep Roadrunner Veep veep Quayle
tjhorton@vis.toronto.edu ("Timothy J. Horton") (05/17/91)
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes: >tjhorton@vis.toronto.edu ("Timothy J. Horton") writes: >>jerryl@is.Morgan.COM (Jerry Liebelson) writes: >>> QUESTION: Is there an efficient, trouble-free way to unmanage and >>>re-manage one instance of this XmList under different parent container >>>widgets, which themselves might be contained within different shell widgets? >> >>XtReparent (I think that's what it's called -- no books nearby). > >This fits into the category of dis-information. There is no XtReparent(). >And there is no easy, nor clean way to reparent widgets. This is not my >opinion, but an echo of something Schliefer/Gettys/Converse/et. al. have >said in months gone by. I believe you. Sorry, I guess I was confusing it with the Xlib call for reparenting windows (not widgets). XReparent or XReparentWindow or whatever. >One possible solution would be to GetValues() the XmNitems resource from >one and SetValues() it onto the other. Since this is fast and simple, >it's the way I would go. This won't answer Jerry's question; his list is very large and he wants only one instance of the XmList. He'll have several copies because XtSetValues on the XmNitems resource causes a list widget to allocate and make a copy of the entire list. If you no longer need access to the list that you provided to a list widget, you can destroy it, because the list widget has its own private copy. Most motif widgets are like this; they reallocate copies of whatever you give them via pointers. Furthermore, if you fetch back resource values via pointers, most widgets allocate yet another copy of the resource and pass back the new copy, which you normally have to free explicitly. I had an application in which I needed to very quickly swap large lists in and out of a list widget, but couldn't, because the dang list widget always freed its old list and allocated and copied the new one. I had to write my own code from scratch to display selection lists without copying them. [Sorry for the earlier disinformation, and thanks for catching it] Tim
tjhorton@cs.toronto.edu ("Timothy J. Horton") (05/17/91)
Let me get this right the second time tjhorton@vis.toronto.edu ("Timothy J. Horton") writes: >Most motif widgets are like this; they reallocate copies of whatever you give >them via pointers. (using *either* XtSetValues or convenience routines) >Furthermore, if you fetch back resource values via pointers, USING CONVENIENCE ROUTINES SUCH AS "XmTextGetString", ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >most widgets allocate yet another copy of the resource and pass back the new >copy, which you normally have to free explicitly. XtGetValues normally bypasses this copy/free cycle. For instance, XmTextGetString gives you a *copy* of the text widget's internal buffer, wheras XtGetValues on its XmNvalue returns a pointer to the text widget's internal buffer. Thus, getting and setting are different. >I had an application in which I needed to very quickly swap large lists in >and out of a list widget, but couldn't, because the dang list widget always >freed its old list and allocated and copied the new one. I had to write my >own code from scratch to display selection lists without copying them. Someone asked about this -- I just used a drawing area and a scrollbar, and the input callback from the drawing area for item selection. I don't have the code (now belongs to a previous client), but it only took a day to write, except that it required some messy Xlib hacking. Tim
sydorow@bisco.kodak.com (Steve Sydorowicz) (05/17/91)
tjhorton@cs.toronto.edu ("Timothy J. Horton") writes: >tjhorton@vis.toronto.edu ("Timothy J. Horton") writes: >>Most motif widgets are like this; they reallocate copies of whatever you give >>them via pointers. > > (using *either* XtSetValues or convenience routines) > >>Furthermore, if you fetch back resource values via pointers, > > USING CONVENIENCE ROUTINES SUCH AS "XmTextGetString", > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>most widgets allocate yet another copy of the resource and pass back the new >>copy, which you normally have to free explicitly. > >XtGetValues normally bypasses this copy/free cycle. For instance, >XmTextGetString gives you a *copy* of the text widget's internal buffer, >wheras XtGetValues on its XmNvalue returns a pointer to the text widget's >internal buffer. > >Thus, getting and setting are different. > > [extras deleted] > >Tim Yes, XtGetValues *normally* bypasses this copy/free cycle. Unfortunately, you picked a bad example with XmNvalue because it has a GetValues hook (from 1.1.1): for (i = 0; i < num_args; i++) { if (!strcmp(args[i].name, XmNvalue)) { *((XtPointer *)args[i].value) = (XtPointer)_XmStringSourceGetValue(GetSrc(widget)); } } and _XmStringSourceGetValue does an XtMalloc eventually. Typically, Motif will have a GetValues hook for all XmString and String typed resources. (*NOT* XmStringTable though. It's probable that you wouldn't want all that copying going on anyway. Though some argue that same point in the XmString and String case, too :-)) The same situation exists in a SetValues hook for these resources. In any event, it was done that way to be *consistent*. In 1.0, and derivatives, it was a hodge-podge of "well, this is copied and this isn't. Hope you have the source so you can go figure out what to do with the memory." All in all, it isn't *so* bad now. It may not be what everyone wants, but it's consistent, which *does* help. Steve -- -------------------------------------------------------------------------------- Stephen J. Sydorowicz Azatar Computer Systems REPLY TO: sydorow@bisco.kodak.com (716)726-5636 Opinions expressed do not reflect those of my employer