slc1290@hare.udev.cdc.com (steve chesney x4662) (08/14/90)
I am experiancing a series of random aborts using Motif. These appear to be related to the use of XtDestroyWidget on dialog boxes (dialog shell parent of bulletin board parent of many XmText widgets). At some point in the session, the application will abort (segmentation violation); this problem is avoided if my dialog boxes are merely unmanaged instead of destroyed. I suspect that XtDestroyWidget, or the XmText or XmBulletinBoard destroy methods are doing something nasty to memory. Are there any known problems of this sort? I am new to USENET (and Motif), so my pardon if I am rehashing an old topic. Steve Chesney Control Data Corporation slc1290@hare.udev.cdc.com
argv@turnpike.Eng.Sun.COM (Dan Heller) (08/14/90)
In article <24537@shamash.cdc.com> slc1290@hare.udev.cdc.com (steve chesney x4662) writes: > I am experiancing a series of random aborts using Motif. These appear > to be related to the use of XtDestroyWidget on dialog boxes (dialog I'm having the same problem and the larger the application gets, the more likely the it is that it will happen. But it doesn't stop there -- My List dialog frequently coredumps when I select items a number of times. The paned window doesn't even work at all -- I get a protocol error in XGrabPointer. Basically, the bigger the program gets, the less usable it becomes. However, I have an even greater problem than this that is really concerning me. Please don't anyone take this as a flame because it's not intended as that. But the problem I am speaking of is a general sense of "dialog" that happens in this and other motif- related newsgroups. I see a lot of questions going on that are not getting answered or even replied to in any way. I'm not sug- gesting that everyone drop what they do and answer everything with a completely satisfactory answer, altho if that were possible, that would be best. I am suggesting that people try to integrate some more with the topics being discussed -- espcially those who know better about certain topics. I suspect that people are answering directly to questions without following up to the newsgroup -- please don't do this! I would hope that anyone who replies to individuals please Cc the newsgroup as well. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
argv@Eng.Sun.COM (Dan Heller) (08/16/90)
On Aug 14, 12:36pm, Kee Hinckley wrote: > > -- My List dialog frequently coredumps when I select > > items a number of times. > Given how close 1.1 is I'm tending to ignore problems that are > clearly memory/pointer based. I do, too -- but chances are that all of them won't be caught. Someone once suggested that the entire motif library should be compiled and run with Saber-C. That should eliminate most of the problems. > I haven't had any problems at all with paned window though. Are you running an R3 or R4 server? I'm using an R4 server on a sun 3/60. Even backwards-compatibility mode doesn't help. The code looks ok, but I still get the protocol error. > > I see a lot of questions going on that are > > not getting answered or even replied to in any way. > I don't know. For a non-supported newsgroup with a lot of people > without support contracts I think that OSF has been pretty good > about giving feedback. I've just assumed that most of the stuff > I've seen that wasn't answered probably addresses problems no one has > solved yet. You're probably right -- and please keep in mind that this was never intended as a flame. If problems can't be solved, that's one thing, but I am concerned that people are getting questions answered directly to do them and the rest of us aren't getting the benefits of their answers. For example, I have a question :-) There doesn't seem to be any way for to "replace" an item in an XmList widget. In order to do that, I have to: void reset_item(list, item, set_selected) Widget hdr_list; int item; Boolean set_selected; { XmString str; XmListDeletePos(list, item+1); str = XmStringCreateLtoR(generate_new_text(), charset); XmListAddItemUnselected(list, str, item+1); XmStringFree(str); if (set_selected) XmListSelectPos(list, item+1, False); } This is incredibly ugly both for the programmer to the user. The list appears to clumsily delete the item and add the new item. Also, because of the activity, the list scrolls in one direction or another and does not end up in the same order as it was in beforehand. There is no way to "get" the top or bottom item in the list even though the data is saved in the list data sturcture. I am considering that the best way to do this is to maintain a static copy of the list and whenever an item changes, the entire list be reset using XmNlistItems. This will provide better visual feedback for the user, but has the cost of a great deal of memory alloocation and freeing as well as the text-to-compound string conversion. The larger the list gets, the worse this problem it becomes. Has anyone run into this and conceived of possible solutions that I haven't thought of? -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.