stuart@siesoft.co.uk (11/21/90)
Environment: Siemens hardware (X20), Motif 1.0, X11r3 server. I have been following the focus policy discussions with interest, hoping that one of the articles would answer a problem that I have with text widgets. Apologies if my question has already been answered but I must have missed it if it has. In the simplest case, I have a window with a single text widget. I want to be able to do just two things: 1) start editing the text widget from my application, i.e. without the user having to click on the text widget. 2) stop editing the text widget, i.e. lose the focus, without the user having to click on another text widget (there isn't another one :-) Dan Heller suggested using XSetInputFocus (surprise, surprise :-) to solve a similar problem with two widgets. So I should be able to go: { XtAddCallback(window, XmNinputCallback, MouseClick, NULL); ... } void MouseClick(Widget w, char *dummy, XmAnyCallbackStruct *datap) { XSetInputFocus(XtDisplay(w), XtWindow(w), RevertToParent, CurrentTime); } and then the editing on the text widget will stop when the user clicks on the window's background. When I try this it either doesn't work or I lose the focus for good. Gabe Begeddov sugetested that one should use the undocumented _XmGrabTheFocus call to move the focus to a particular widget. The first time that this call is made to start editing the text widget it works. However, it never works when used in trying to move the focus to the window (to stop the editing) or on subsequent calls to restart the editing. He also mentions a XmProcessTraversal() service in Motif 1.1 as the being the correct way to do this. Is there a way round this problem with Motif 1.0? Will XmProcessTraversal() do what I want when I get Motif 1.1? All and any help is much appreciated, Stuart. - -- S I E M E N S Stuart Hood 65-73 Crockhamwell Road, Woodley, Berkshire, UK ------------- Phone: + 44-734-691994 Email: stuart@siesoft.co.uk N I X D O R F The trouble with everyone, is that they generalise too much
argv@turnpike.Eng.Sun.COM (Dan Heller) (11/23/90)
In article <1990Nov21.154611.25895@siesoft.co.uk> stuart@siesoft.co.uk writes: > In the simplest case, I have a window with a single text widget. > I want to be able to do just two things: > > 1) start editing the text widget from my application, i.e. without the > user having to click on the text widget. > > 2) stop editing the text widget, i.e. lose the focus, without the user > having to click on another text widget (there isn't another one :-) > > Dan Heller suggested using XSetInputFocus (surprise, surprise :-) to > solve a similar problem with two widgets. I recommended that at the time because I only had 1.0 (as you do) and I was unaware of the damaging side effects of using the function (and the sister function, XtSetInputFocus()) because Motif isn't expecting that kind of stuff. Doing this sort of thing will break a few things internally to motif, but the side effects may not be noticable right away. One problem is that the blinking cursor is done using a timeout routine (XtAddTimeOut()) and motif isn't pro- perly resetting that when you change focus using X[t]SetInputFocus(). The workaround for this is to set the blink rate resource to 0. I think there are other problems as well, but I don't remember exactly what they are. If you are going to use 1.1 anytime in the near future, I recommend defering the problem till then and using Gabe's suggestion: > > { > XtAddCallback(window, XmNinputCallback, MouseClick, NULL); > ... > } > void MouseClick(Widget w, char *dummy, XmAnyCallbackStruct *datap) > { > XmProcessTraversal(text_w, XmPROCESS_CURRENT); > } I might note that a "red flag" goes up in my mind when I see people trying to munge the focus policy of their applications. We revisit the issue of "compatiblity", not just with Motif, but with other applications. If everyone does this sort of thing, the users who get Motif apps from different vendors may not be able to do the same things and get the same results across all apps.. Of course, I don't know your particular situation, but it's something to think about. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.