Paul.Quane@samba.acs.unc.edu (Paul Quane) (12/13/90)
Motif 1.0 X11R3 on HP-UX and Interactive Hi, I'm having a problem which I would appreciate some help with. I create a scrolled list ( using XmCreateScrolledList , visible item count 5 , no items initially, rest default ) in a form in a dialog. Each time I manage the dialog I delete any existing items using XmListDeletePos and then create a new list using XmListAddItemUnselected specifying position 0. This seems the best way to do it as the list of items may vary a lot between each dialog manage. The problem arises when the user uses the scrollbar to peer at items which are not initially seen due to the visible item count being 5. Nothing happens right away, but the next time the dialog is managed the scrolled list widget goes crazy. The only parts that appear are the top shadow and the top arrow and there are no items in the list and the dialog is far longer than the sceen height ( greater than twice ?). It looks like the scrolled window decides to have an infinite height! Anybody ever had anything like this happen ? Now some for further investigation....... Paul Quane
gaf@uucs1.UUCP (gaf) (12/14/90)
Long ago, when I first started doing Motif programming, I had loads of trouble figuring out listboxes. I don't remember if I fell in the pothole you describe, but I was on the same road (clear all previous items in a listbox, in order to re-add current items). What I found that worked was to set XmNitemCount to 0 via XtSetValues(). It's much easier than deleting the items one by one, and it hasn't given me any strange behavior. -- Guy Finney It's that feeling of deja-vu UUCS inc. Phoenix, Az all over again. ncar!noao!asuvax!hrc!uucs1!gaf sun!sunburn!gtx!uucs1!gaf
Paul.Quane@samba.acs.unc.edu (Paul Quane) (12/16/90)
In a previous post I asked why my scrolled list went crazy after a sequence of XmListAddItemUnselected/XmListDeletePos and use of the scroll bar. Well I tracked it down to the visibleItemCount resource being corrupted somehow, going from a respectable 5 to an outrageous 30174, or thereabouts! Anyway in case anybody has the problem occur in their code the solution is to GetValues the visibleItemCount before using the above calls and then re-set it later. Thanks to the person who suggested setting the itemCount to 0 instead of using the above routines.. I haven't tried this yet but I will. I had another problem with a List Widget where I was trying to use It as a queue for displaying comms messages received. Unfortunately these messages are 2K bytes each and even though I only retained a queue of 10 items the program grew by 2k ( or more ? - XmString size of 2k characters ?) every time a message is received. As this interval is about every 2 seconds the program got verylarge indeed in no time any caused all the swap space to be used up causing HP-UX to kill off processes with abandon! Also this huge list made the application so slow as to be unusable. The solution to this problem was to have the list items be the first 20 or so characters of the message and the full text of the message is displayed in a dialog when the user clicks on the list item. I know this will still grow but not as fast, right ? And 1.1 will fix this problem when we get it, right? Paul Quane
nazgul@alphalpha.com (Kee Hinckley) (12/17/90)
> grow but not as fast, right ? And 1.1 will fix this problem when > we get it, right? 1.1 should fix the memory problems. There are still problems with deleting items and restoring them, but not as many (your case should work okay). Hopefully those will be taken care of in 1.1.1 (which is what I assume most vendors will ship). -kee
nick@esacs.UUCP (Nikolaos Tsivranidis) (12/17/90)
In article <1941@beguine.UUCP>, Paul.Quane@samba.acs.unc.edu (Paul Quane) writes: > In a previous post I asked why my scrolled list went crazy > after a sequence of XmListAddItemUnselected/XmListDeletePos and > use of the scroll bar. Well I tracked it down to the visibleItemCount > resource being corrupted somehow, going from a respectable 5 to an > outrageous 30174, or thereabouts! Anyway in case anybody has the > problem occur in their code the solution is to GetValues the > visibleItemCount before using the above calls and then re-set it later. > Thanks to the person who suggested setting the itemCount to 0 instead > of using the above routines.. I haven't tried this yet but I will. > Hey, not so fast. That "outrageous" 30174 is probably an overwritten piece of memory. I remember tracking down a few problems with XmListDeletePos, especially when you delete the last item on the list. The best advice is to set the itemCount to 0 (if you want to remove everything from the list), and use 1.1 (if you want the list to work correctly). By the way, I believe you would have no problems if you copy the array of items (XmNitems), and put it back with SetValues. - nick -
brad@sqwest.sq.com (Brad Might) (12/19/90)
> Hey, not so fast. That "outrageous" 30174 is probably > an overwritten piece of memory. I remember tracking down a few > problems with XmListDeletePos, especially when you delete the > last item on the list. The best advice is to set the itemCount > to 0 (if you want to remove everything from the list), and > use 1.1 (if you want the list to work correctly). By the way, > I believe you would have no problems if you copy the array of > items (XmNitems), and put it back with SetValues. > > - nick - > if you set itemCount to 0, do you also have to delete the list items, does the widget delete them, or have you thrown them to the wolves ? brad -- Brad Might brad@sq.sq.com SoftQuad Inc. {utzoo,uunet}!sq!brad 321-9801 King George Hwy. Surrey, BC. V3T 5H5 (604) 585-1999
meeks@osf.org (W. Scott Meeks) (12/21/90)
>From: julius.cs.uiuc.edu!wuarchive!cs.utexas.edu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!hydroesm!jtsv16!torsqnt!geac!sq!sqwest!brad@apple.com (Brad Might) > > if you set itemCount to 0, do you also have to > delete the list items, does the widget delete them, > or have you thrown them to the wolves ? > >brad If you set XmNitemCount to 0 in an XmList the current behavior is for the widget to delete the old list items. It is also recommended that you set XmNitems to NULL simultaneously as is implied to be necessary by the AES in case of future changes to the implementation. After the release of 1.1.1, XmListDeleteAllItems will be safe to use and will be the recommended method for clearing a list. Let me know if there are any questions. W. Scott Meeks Open Software Foundation meeks@osf.org (617) 621-7229