carl@quad1.quad.com (Carl Priddy) (09/16/90)
I have experienced some odd behavior with the text widget. I have a popup dialog that contains a text widget. The purpose of this is to allow the user to input a file name.If the user depresses the middle (2) button in the text widget when it is empty, then I popup a FileSelection widget. The user then selects the file and I copy it to the text widget. Unfortunately, the file selection box pops up twice. This is apparently once for the button down, and once for the button up. The documentation CLAIMS that the event that caused the callback is put into the callback struct, but it is consistentlyzero. I would like to distinguish between button up and down, at this point in the processing. Is the callback struct event pointer being zero just another example of incorrect documentation, or is there some other setup necessary? Any ideas out there? Thanks in advance, carl.
mikey@eukanuba.wpd.sgi.com (Mike Yang) (09/16/90)
In article <14983@gouda.quad.com>, carl@quad1.quad.com (Carl Priddy) writes: |> I have experienced some odd behavior with the text widget. I have a popup |> dialog that contains a text widget. The purpose of this is to allow the user |> to input a file name.If the user depresses the middle (2) button in the |> text widget when it is empty, then I popup a FileSelection widget. The user |> then selects the file and I copy it to the text widget. Unfortunately, the |> file selection box pops up twice. This is apparently once for the button |> down, and once for the button up. The documentation CLAIMS that the event |> that caused the callback is put into the callback struct, but it is |> consistently zero. First of all, overloading the meaning of button 2 could be dangerous. For instance, supposed I select some text somewhere else for the file name, go to your text widget (which is empty), and press button 2 to paste it? Perhaps you should use another mouse button, like 3. Next, what kind of callback for the XmText widget are you using to determine that the user depressed button 2? It's very possible that the event field of XmAnyCallbackStruct isn't being set to the button event. I noticed that this is also true when the user pastes the current selection into a text field -- the valueChanged callback is called but the event shows no indication of the button event. This would be useful for determining whether the user pressed a key or whether the user pasted the current selection. Lastly, you can solve your problem by using XtAddEventHandler to watch for button press events on the text widget. ----------------------------------------------------------------------- Mike Yang Silicon Graphics, Inc. mikey@sgi.com 415/335-1786
marbru@auto-trol.UUCP (Martin Brunecky) (09/17/90)
In article <1990Sep16.004605.9095@relay.wpd.sgi.com> mikey@sgi.com writes: >In article <14983@gouda.quad.com>, carl@quad1.quad.com (Carl Priddy) writes: >|> I have experienced some odd behavior with the text widget. I have a popup >|> ....... The documentation CLAIMS that the event >|> that caused the callback is put into the callback struct, but it is >|> consistently zero. > >Next, what kind of callback for the XmText widget are you using to >determine that the user depressed button 2? It's very possible that >the event field of XmAnyCallbackStruct isn't being set to the button >event. I noticed that this is also true when the user pastes the >current selection into a text field ..... > >Lastly, you can solve your problem by using XtAddEventHandler to watch >for button press events on the text widget. > Since XmText callbacks may be triggered by other "things", it is not quite appropriate to trust to the event field. In my WsText widget I solved the problem by additional structure member(s), which try to describe what triggered the callback. May be a usefull enhancement to XmText. [ Plus, I am a firm believer that Xt was invented to RELIEF an application programmer from looking at X events. Thus, even though Motif blindly follows DECwindows in passing events to the callback, I don't ever use those. One of reasons of having a widget is to hide underlying X input system from an application. This, however, puts a little more responsibility on a widget writer, so that applications don't have to compensate for poor widget by knitting a whole net of workarounds based on X calls around it]. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
mikey@eukanuba.wpd.sgi.com (Mike Yang) (09/18/90)
In article <829@auto-trol.UUCP>, marbru@auto-trol.UUCP (Martin Brunecky) writes: |> [ Plus, I am a firm believer that Xt was invented to RELIEF an |> application programmer from looking at X events. Thus, even though |> Motif blindly follows DECwindows in passing events to the callback, |> I don't ever use those. One of reasons of having a widget is |> to hide underlying X input system from an application. This, |> however, puts a little more responsibility on a widget writer, so |> that applications don't have to compensate for poor widget by |> knitting a whole net of workarounds based on X calls around it]. I agree with you. For the common case, the point of Xt and Motif is to hide the need for Xlib knowledge from the developer. However, it would be a big mistake to make the knowledge completely inaccessible and thus limit the ability of Xt/Motif programs. For instance, when dealing with ICCCM selections a timestamp is needed Since many of the Motif callbacks provide the event structure, this can be used for a timestamp for, say, owning the selection when a list box item is chosen. If the Motif callbacks didn't provide this extra information, I'd have to use something like CurrentTime, and in the ICCCM viewpoint, I would be a\ bad boy. So I'm thankful that although I don't often need the event field, it's usually there when I do need it. (I say "usually" because it's not there when a text selection is made -- Grrr.) ----------------------------------------------------------------------- Mike Yang Silicon Graphics, Inc. mikey@sgi.com 415/335-1786
whitty@hpcvlx.cv.hp.com (Joe Whitty) (10/17/90)
> / hpcvlx:comp.windows.x.motif / carl@quad1.quad.com (Carl Priddy) / 2:51 pm Sep 15, 1990 / > ... The documentation CLAIMS that the event that caused the > callback is put into the callback struct, but it is consistently zero. I > would like to distinguish between button up and down, at this point in the > processing. Is the callback struct event pointer being zero just another > example of incorrect documentation, or is there some other setup necessary? > Any ideas out there? I provided OSF with a fix that will indeed pass the event in the callback struct for Motif 1.1. Hopefully it will come out in OSF's next patch. > Thanks in advance, > carl. ---------- Joe Whitty