rich@MAX7.llnl.gov (Rich Mayfield) (03/08/91)
Here's the poop - I've got a few XmText widgets sitting in an XmForm. My basic goal is to re-write the tab grouping mechanism so that I can do my own validation before moving onto another XmText widget. (i.e. when I press Tab, I want to check the contents of the XmText, if it's ok then I'll move on; otherwise I stay where I am and do some sort of error handling). Currently, I'm using XtSetKeyboardFocus(), but I wind up with TWO text fields with cursors. I guess one of my problems is that I can't force one of the widgets to "give up" input focus. Any hints out there? Thanks much! rich mayfield
marbru@attc.UUCP (Martin Brunecky) (03/09/91)
In article <1991Mar7.124545@MAX7.llnl.gov> rich@MAX7.llnl.gov (Rich Mayfield) writes: >Here's the poop - > >I've got a few XmText widgets sitting in an XmForm. My basic goal >is to re-write the tab grouping mechanism so that I can do my >own validation before moving onto another XmText widget. (i.e. when >I press Tab, I want to check the contents of the XmText, if it's >ok then I'll move on; otherwise I stay where I am and do some sort >of error handling). > Learn about XmNmotionVerifyCallback. At least in Motif 1.0 this one (attempted to) do exactly what you want. Check with you if the focus can be moved to another widget. See, it's is not cursor motion it refers to, it's focus motion (or was in 1.0). -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
Link_-_APO@cup.portal.com (03/09/91)
>Here's the poop - >I've got a few XmText widgets sitting in an XmForm. My basic goal >is to re-write the tab grouping mechanism so that I can do my >own validation before moving onto another XmText widget. (i.e. when >I press Tab, I want to check the contents of the XmText, if it's >ok then I'll move on; otherwise I stay where I am and do some sort >of error handling). >Currently, I'm using XtSetKeyboardFocus(), but I wind up with TWO text fields >with cursors. I guess one of my problems is that I can't force one >of the widgets to "give up" input focus. >Any hints out there? Thanks much! >rich mayfield Hi Rich, You didn't say what your arguments were to XtSetKeyboardFocus(). Try using something like: XtSetKeyboardFocus( root_widget, text_widget ) ; or XtSetKeyboardFocus( form_widget, text_widget ) ; Good Luck! ---------------------------------------------------------------- Sandy Johan link_apo@cup.portal.com(Sandy) sun!portal!cup.protal.com!link_apo
ik@snoopy.Berkeley.EDU (Ik Su Yoo) (03/11/91)
In article <39956@cup.portal.com>, Link_-_APO@cup.portal.com writes: > >Here's the poop - > > >I've got a few XmText widgets sitting in an XmForm. My basic goal > >is to re-write the tab grouping mechanism so that I can do my > >own validation before moving onto another XmText widget. (i.e. when > >I press Tab, I want to check the contents of the XmText, if it's > >ok then I'll move on; otherwise I stay where I am and do some sort > >of error handling). > > >Currently, I'm using XtSetKeyboardFocus(), but I wind up with TWO text fields > >with cursors. I guess one of my problems is that I can't force one > >of the widgets to "give up" input focus. > > >Any hints out there? Thanks much! > >rich mayfield > > Hi Rich, > > You didn't say what your arguments were to XtSetKeyboardFocus(). > Try using something like: > XtSetKeyboardFocus( root_widget, text_widget ) ; > or > XtSetKeyboardFocus( form_widget, text_widget ) ; > > Good Luck! > ---------------------------------------------------------------- > > Sandy Johan link_apo@cup.portal.com(Sandy) > sun!portal!cup.protal.com!link_apo You may already know this but here is a quote from FAQ: Subject: 21) How can I direct the keyboard input to a particular widget? Answer: In Motif 1.1 call XmProcessTraversal(target, XmTRAVERSE_CURRENT). In Motif 1.0 call the undocumented _XmGrabTheFocus(target). Do not use the X or Xt calls such as XtSetKeyboardFocus since this bypasses the Motif traversal layer and can cause it to get confused. This can lead to odd keyboard behaviour elsewhere in your application. Ik Su Yoo RRC 1H-229, (908) 699-5764 ik@ctt.bellcore.com
bonnett@seismo.CSS.GOV (H. David Bonnett) (03/12/91)
Ik Su Yoo writes: |> You may already know this but here is a quote from FAQ: |> |> Subject: 21) How can I direct the keyboard input to a particular widget? |> |> Answer: In Motif 1.1 call XmProcessTraversal(target, XmTRAVERSE_CURRENT). |> In Motif 1.0 call the undocumented _XmGrabTheFocus(target). Do not use the |> X or Xt calls such as XtSetKeyboardFocus since this bypasses the Motif |> traversal layer and can cause it to get confused. This can lead to |> odd keyboard behaviour elsewhere in your application. I have found that this does not work for me in the following case: I have a rather complex widget hierarchy; but not extremely so, I use a mainWindow that contains a Form passed as the work area of the main_window. Then I have a ScrolledWindow child that contains a another Form which is scrolled. It contains a group of RowColumns each of which contain either labels or Text widgets. I want to set the keyboard focus to the first text widget created, so when use the XmProcessTraversal call exactly as specified in the FAQ and I get: No focus on any of my widgets. The focus did work correctly w/o this call before I added the layers of the scrolled window and 2nd form. The resultant problem is that I grab the input on losingFocus and if the widget never gets the focus well then it can't lose it.... Any solution would be appreciated greatly. -dave bonnett- Center for Seismic Studies; Arlington, VA bonnett@seismo.css.gov : All standard disclaimers apply. -- -dave bonnett- Center for Seismic Studies; Arlington, VA bonnett@seismo.css.gov : All standard disclaimers apply.
ik@snoopy.bellcore.com (Ik Su Yoo) (03/12/91)
In article <49493@seismo.CSS.GOV>, bonnett@seismo.CSS.GOV (H. David Bonnett) writes: > > Ik Su Yoo writes: > |> You may already know this but here is a quote from FAQ: > |> > |> Subject: 21) How can I direct the keyboard input to a particular widget? > |> > |> Answer: In Motif 1.1 call XmProcessTraversal(target, XmTRAVERSE_CURRENT). > |> In Motif 1.0 call the undocumented _XmGrabTheFocus(target). Do not use the > |> X or Xt calls such as XtSetKeyboardFocus since this bypasses the Motif > |> traversal layer and can cause it to get confused. This can lead to > |> odd keyboard behaviour elsewhere in your application. > > I have found that this does not work for me in the following case: > I have a rather complex widget hierarchy; but not extremely so, > I use a mainWindow that contains a Form passed as the work area of > the main_window. Then I have a ScrolledWindow child that contains a > another Form which is scrolled. It contains a group of RowColumns > each of which contain either labels or Text widgets. > > I want to set the keyboard focus to the first text widget created, > so when use the XmProcessTraversal call exactly as specified in > the FAQ and I get: > No focus on any of my widgets. The focus did work correctly w/o > this call before I added the layers of the scrolled window and 2nd > form. The resultant problem is that I grab the input on losingFocus > and if the widget never gets the focus well then it can't lose it.... > Any solution would be appreciated greatly. > Sorry, I, too, have used the above "feature" with only limited success. I was merely trying to point out the danger of using XtSetKeyboardFocus as mentioned in the FAQ listing. Any Motif expert out there want to enlighten us of making XmProcessTraversal work as expected? I already did RTFM and RTF-FAQ. Thanks. Ik Su Yoo RRC 1H-229, (908) 699-5764 ik@ctt.bellcore.com
bni@modulex.dk (Bent Nielsen) (03/12/91)
rich@MAX7.llnl.gov (Rich Mayfield) writes: -- stuff deleted -- >Currently, I'm using XtSetKeyboardFocus(), but I wind up with TWO text fields >with cursors. I guess one of my problems is that I can't force one >of the widgets to "give up" input focus. What about using XmProcessTraversal() if your are running Motif 1.1 instead of XtSetKeyboardFocus(). -- Bent Nielsen <bni@modulex.dk> A/S MODULEX Phone: +45 44 53 30 11 Lyskaer 15 Telefax: +45 44 53 30 74 DK-2730 Herlev Denmark
gabe@hpcvlx.cv.hp.com (Gabe Begeddov) (03/13/91)
XmProcessTraversal tries to disallow traversal to what it considers a non-traversable destination. Lots of resource settings play a part in this decision such as XmNtraversalOn, XmNnavigationType. In addition, it requires that the destination and all it's ancestors (up to the shell) be at least partially unobscured and managed. This means that you can't call XmProcessTraversal till after the hierarchy is realized. It would have been nice to have had a pre-realize mode to setting the focus so that the initial focus could be set at startup. I think 1.2 is addressing this problem of initial focus specification. Till then you have to wait till realize to set the traversal. Gabe
marbru@attc.UUCP (Martin Brunecky) (03/14/91)
In article <1991Mar11.213058.5300@bellcore.bellcore.com> ik@ctt.bellcore.com (Ik Su Yoo) writes: > >Any Motif expert out there want to enlighten us of making >XmProcessTraversal work as expected? I already did RTFM and RTF-FAQ. No, I don't claim to be a Motif expert. But I have some experience with the Traversal.c code in 1.0 (where I had to borrow/override), and I already did some research in 1.1. The main problem, as someone from OSF correctly pointed out, is that the traversal code is "byzantine". It just delas with (to my taste) too many if-this-and-not-that cases. Anytime you introduce a new case beyond what has been considered so far, (such as manager widgets nesting), one or more of those if's fails, resulting in a rejection of whatever request you have made. Just as an example, I have a Composite subclass, which needs to be traversible as a primitive UI element. In Motif 1.0, I was able to get around: For each XmTrav* call I pretend to be an XmPrimitive instance (by changing the class pointer plus several instance fields). Most likely, this will die in Motif 1.1. The only resolution I can see is a complete traversal redesign. Design with minimum (better none) dependencies/assumptions about widgets/gadgets used - for example using widgets "accept_focus" method rather than testing: if ((XmIsPrimitive(w) && (XmPrimitiveWidget)w->primitive.traversal_on || (XmIsManager(w) && (XmGadget)w->gadget->traversal_on )) (which reduces the set of traverable widgets to subclasses of Primitive and Gadget - nothing else, no extensibility whatsever). Similarly, the traversal should probably never depend on if (XmIsPrimitive(w) && XmIsManager(Xtparent(w)) && XtIsShell(XtParent(XtParent(w)) ). My list of grievances could probably continue .... To summ it up, with the current implementation it often may be very difficult to accomplish the desired behavior. The redesign, on the other hand, is not going to be an easy task - there are lots of reasons why the current code is so "byzantine", and cleaning it up will be a real challenge. But I believe it *must* be done, because adding new and new and new cases to the existing code leads nowhere. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404