Conference bulova::decw_jan-89_to_nov-90

>	I dug around and found AcceptFocus, but that needs a time argument that
>	I can't quite figure out....

You can use the predefined "CurrentTime"....it's defined in x.h

Dan

    re: .0
    
    What you are suggesting doesn't conform to the XUI style guide, but I
    suppose it's become pass� to suggest that.

  I tried using CurrentTime... but it didn't work.

  As for Style, does the style suggest that the user must puck a one-line
  input region of a 30cm square window in order to specify text input...
  I think that would be sad.  I scanned the XUI style, but did not read it
  in depth.  How are others dealling on this issue?

	Christopher

RE: .3

It is a fundamental part of XUI style that input focus is controlled by the user
(speaking through the window manager) and not by applications.  Your application
should take focus when the user (window manager) gives it to you.  It should not
grab focus simply because the pointer happens to be in one of its windows.

However, once your application has been given focus, it is acceptable for it to
assign input focus to whichever of its widgets it wishes.  If I understand your
application correctly, I would do the following.  Don't key off pointer events
and grab input focus whenever the pointer enters your windows.  Wait for the
event to come in that says the window manager has given your application the
input focus (I don't remember off-hand what this event is called).  When you
get that event, hand off input focus to your command window widget.

--PSW

    There are two events to look for:
    
    1. A focusin event on a widget.  
    
    2. A client message to your top widget.  The message type will be a
       DEC_WM_TAKE_FOCUS.
    
                        August G. Reinig

   My intent was not to take input focus whilest the pointer was in my
   window.  I wanted to direct the focus to the commandWindow when a selection
   is made somewhere in the hierarchy (refer to .0).

   Once I trap once of these events, I do not understand how I attach the
   focus?   I believe this is the information that I am lacking..

   For example, when the user clicks on the title bar, I would like the
   input focus attached to the commandWindow widget.  I am using standard
   DWT widgets.

	Thanks for the help,

		Christopher

    From the code in TPU that catches client messages.  The important
    call is the call to xt$call_accept_focus.
    
                                    August G. Reinig
    
        
    !
    ! If this is a DECW_WM_TAKE_FOCUS message, give input focus to one of
    ! two places, depending upon whether we are doing a read_line or not.
    !
    IF .message_type EQLU .env [decw_l_take_focus_atom]
    THEN
	BEGIN
	!
	! Save the timestamp.
	!
	env [decw_l_time_stamp] = . (event [x$r_clnt_data]);

	!
	! Check to see if we're in the middle of a READ_LINE.
	!
	IF NOT .env [decw_v_doing_readline]
	THEN
	    !
	    ! Put input focus on our main window.
	    !
	    xt$call_accept_focus (env [decw_a_main_widget],
				  event [x$r_clnt_data])
	ELSE
	    !
	    ! Put input focus on the read_line widget.  Also, set the resources
	    ! which keep the insertion point visible.
	    !
	    BEGIN
	    LOCAL
		arglist : dwt$arg_vector (3);

	    arglist [0, dwt$a_arg_name]
		= UPLIT BYTE (%ASCIZ dwt$c_ninsertion_point_visible);
	    arglist [0, dwt$l_arg_value] = 1;
	    arglist [1, dwt$a_arg_name]
		= UPLIT BYTE (%ASCIZ dwt$c_nauto_show_insert_point);
	    arglist [1, dwt$l_arg_value] = 1;
	    arglist [2, dwt$a_arg_name]
		= UPLIT BYTE (%ASCIZ dwt$c_nresize_width);
	    arglist [2, dwt$l_arg_value] = 0;
	    xt$set_values (env [decw_a_readline_widget], arglist, %REF (3));

	    xt$call_accept_focus (env [decw_a_readline_widget],
				  event [x$r_clnt_data]);
	    END;
    	RETURN;
	END;
    

>	I have the following basic hierarchy :
>
>			top-level
>			    |
>		        main window
>			    |
>                    +-------+------------+
>                    |       |            |
>		menubar  attachedDB  commandWindow
>
>	What I would like is the following ...
>
>		(1) When I realize the top-level, focus to be assigned to
>		    the commandWindow
>
>		(2) When I puck anywhere in the top-level hierarchy, focus
>		    to be assigned to the commandWindow.
    
    What the toolkit will give you by default is the following:
    
    Not (1); this is not style guide conforming.
    
    What will happen otherwise, depends upon what the children of the
    attached dialog box are (that is, whether it has any that will
    accept focus or not).
    
    When the user clicks on the title bar, the main window widget
    will give focus to:
    
        1 - Whatever widget had it before.
        2 - If none, the work area widget (attached dialog box).
	    The attached dialog box will search its children to see
    	    if any of them will take it.
        3 - If none of the attached dialog box's children take focus, the
    	    command window widget.
    
    When the user clicks on the attached dialog box, it will attempt to
    give focus to its children as described above.
    
    When the user clicks on the command window, it will take focus.
    
    So, my guess as to the problem you are having is that the attached
    dialog box does not have any child which takes focus, so when the
    user clicks on the attached dialog box, your application does not
    get focus.
    
    If that is the problem, then you somehow need to "trap" the mouse
    click in the attached dialog box and call XtCallAcceptFocus on the
    comand window.  I'm not sure what the best way to "trap" the
    mouse click is, but here are a two ideas:
    
        o  If the attached dialog box has no gadget children, override
           its mouse button 1 down translation entry, and in the action
    	   routine call XtCallAcceptFocus.  If it has gadget children,
    	   this will break gadget processing.
    
        o  Add an Xt event handler for mouse button 1 down in the
    	   attached dialog box, and call XtCallAcceptFocus from it.
    
Leo