[comp.windows.x] trapping Newlines in Athena dialog boxes

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.