anneb@ai.etl.army.mil (Anne Brink) (03/07/90)
Hi, Folks, What's the conventional way for me, the application programmer, to have my Athena dialog widget fire off a command button when the user enters a <return>, instead of the dialog box widening to accept more data? I've played around with key accelerators in the dialog box, but the text area doesn't recognize my requests. I understand that the text area is a separate widget, and so may ignore what its parent the dialog widget says, but I also understand why it is a bad thing to go down and tweak with the "hidden" text widget. This is using R4 with fixes 1 and 2 under SunOS 4.0.3. The dialog box has 2 child command buttons as well as its own label and text area. Thanks for any help or advice. -Anne Brink anneb@etl.army.mil -- #################################||############################################ Anne Brink: anneb@etl.army.mil || Open Spring Training!! ...!uunet!etl.army.mil!anneb || Baseball in '91? #################################||############################################
converse@EXPO.LCS.MIT.EDU (Donna Converse) (03/09/90)
> What's the conventional way for me, the application programmer, to have my > Athena dialog widget fire off a command button when the user enters > a <return>, instead of the dialog box widening to accept more data? By translations or by accelerators: You can override the default Return key action in the dialog box's text widget by setting the translation resource of that text widget. The action procedure in this translation could call the command button's callback procedure. To use accelerators, set the accelerator resource of the command button and install the accelerators with destination widget being the dialog box's text widget. > I've > played around with key accelerators in the dialog box, but the text area > doesn't recognize my requests. I understand that the text area is a separate > widget, and so may ignore what its parent the dialog widget says, but I also > understand why it is a bad thing to go down and tweak with the "hidden" text > widget. Some points: - The dialog widget engineers things (sets the keyboard focus) so that the mouse pointer is not restricted to being within the text input field before keyboard events are delivered to that text field. All keyboard events are delivered to the text widget, so the accelerator destination widget must be the text widget. - The command button's notify action procedure will not call the command button's procedures on the callback list unless the button is in the set state. Do set()notify()unset() not just notify(). - In the dynamics of widget relationships, children should not ignore parents, but parents may ignore the requests of children. This more often relates to issues of sizing. - Setting the resources of the text widget within the dialog box is not particularly a bad thing. You can get the widget ID with XtNameToWidget. Donna Converse converse@expo.lcs.mit.edu PS. Please don't send me private mail asking for examples of code. Play with examples/Xaw/popup.c or post your question to the net.