Conference bulova::decw_jan-89_to_nov-90

  Try using XSetInputFocus.

  This should do what you want.

				-=> Jim <=-

	I  figured  it  would  come to that.  If I pulled up my windows
	with the following:

	DwtInitalizeDRM();
	toplevel_widget = XtInitialize (...);
	DwtOpenHierarchy (...);
	DwtFetchWidget (...);

	where do I get Display from to pass to XSetInputFocus?

	thx/cliff

XtDisplay(top_level_widget)

    And if you need window try..
    XtWindow(widget)
    

	I'm  using  everything  y'all've recommended, and I'm still not
	getting input focus.   Here's  the  code  in  response  to  the
	creation of a command window widget:

static void create_proc(w, tag, reason)
Widget w;
int *tag;
unsigned long *reason;
{
    XSetInputFocus (XtDisplay (w), XtWindow (w), RevertToParent, CurrentTime);
    }

	I also tried adding:

    Arg ArgList [1];
    XtSetArg (ArgList [0], DwtNtakeFocus, TRUE);
    XtSetValues (w, ArgList, 1);

    
    Have you tried XtCallAcceptFocus (widget, &CurrentTime);
    
    If a more relevant time than CurrentTime is available
    (from a ButtonPress event perhaps ?) then it should be used.
    
                       Alastair.
    

re: .-2

Seems like you are using XtWindow in a create callback of a widget. This type
of thing is usually a no-no. What you really want is to use code in .-2
in a map callback as opposed to create callback. Also, as .-1 mentioned 
XtCallAcceptFocus is the way to go.

Hope this helps.

	XtCallAcceptFocus  doesn't  work  either.   Has anyone actually
	done this before?  (I'm sure someone has).  I'd really like  to
	see  some  real,  working  code....   I've read the manuals and
	gotten to all the same routines, but the documentation is  very
	sparse  on  discussing  any  related  conditions  that  may  be
	inhibiting the actions I'm asking for.

	/cliff

	Ok  -  I  moved  XtCallAcceptFocus  out of the create callback.
	Now, in the main routine, I get "BadMatch", which has something
	to  do with the window not being "viewable".  All I'm trying to
	do is load a window hierarchy that includes  a  command  window
	and give the command window focus.  easy, right?

    DwtInitializeDRM ();
   
    toplevel_widget = XtInitialize ("Welcome to DECSIM", 
				    "example", 
				    NULL, 
				    0, 
				    &argc, 
				    argv);
    if (DRMSuccess != 
	    DwtOpenHierarchy (db_filename_num,
			      db_filename_vec,
			      NULL,		
			      &s_DRMHierarchy))	
	s_error ("can't open hierarchy");
    DwtRegisterDRMNames (reglist, reglist_num);
    if (DRMSuccess != 
	    DwtFetchWidget (s_DRMHierarchy,
			    "S_MAIN_WINDOW",
			    toplevel_widget,
			    &main_window_widget,
			    &dummy_class))
	s_error("cant fetch main window");
    XtManageChild (main_window_widget);
    XtRealizeWidget (toplevel_widget);
    XtCallAcceptFocus (widget_array [k_command_window], &CurrentTime);
    XtMainLoop ();

re: .-1 

  As I said: do it in the 'map callback' and you should be OK.

Jatin

    Your problem is that you can't call XSetInputFocus (or
    XtCallAcceptFocus) until the window
    is mapped.  There is a delay between the time that you call
    XtRealizeWidget and the time that the window is mapped because the
    window manager gets into the act and "decorates" the window.
    
    Also style guide "conformant" applications are not supposed to
    grab input focus at startup.  If you still think you should be
    doing it, you need to add some mechanism to know when the window
    has been mapped.  I don't think a 'map callback' will help because
    it is called before the window is mapped.  You could add a toolkit
    event handler for MapNotify (I think it's called...) and call
    XtCallAcceptFocus from it.
    
    Leo

RE: -1

  I've been told/shown that you should wait for an Expose event.  I've been
confused before on this issue.

  What should *really* be used; an Expose event or MapNotify event??

  Either way should do the trick however.

				-=> Jim <=-

>  What should *really* be used; an Expose event or MapNotify event??

MapNotify should arrive first, but exposes will follow quickly...

>  Either way should do the trick however.

Right.

Leo

	The  Map  callback  routine  for the command window is not ever
	being called; and the command window does not get MapNotify  or
	Expose  callbacks (these are X events, right?).  I am using UIL
	and DW, not X.  Is there a way to simply  fetch  a  widget  and
	give  it  focus?   I  have  tried  everything that everyone has
	suggested here and nothing is working.  I  appreciate  all  the
	help, but I guess I'm miscommunicating what I'm trying to do...

	thx
	/cliff

The problem is that you are going against the grain.  It is not easy to
manipulate focus.  The Style Guide laid down a set of rules and the toolkit
implements those rules.  Doing so is not trival as you are finding out.
I would suggest that you seriously consider not building your application
so that it goes against the Style Guide.

Most of the complexity comes from the need to have a mapped window prior to
setting focus to it.  In general only the widget knows when it has been
mapped, widget try to hide this from users since it usually is of no interest.

As .13 suggested you will need to get either map notify or expose events.
Because the command window is tiled by other widgets it has no expose proc,
hence does not select for expose events.  Also it has no interest in 
map notify events so does not select for them.  Because neither of these
events is selected for the server does not produce them.  Hence listening
for them won't help, yet...

You could add translation syntax for the map notify to the command widget,
this will cause it to select for map notify events.  Having selected for
them the server will produce them and they will be dispatched to your
action proc.  Use XtAugmentTranslations since there is translation syntax
already on the command widget.  I don't believe this can not be done via UIL.

Mike Collins

	ok, Mike.  thanks for the explanation.

	i'm still not clear on one thing.  the application itself
	shouldn't grab focus, but how about popup selection widgets?
	they do it all the time.  doesn't this cause the same problem?

	/cliff

  Slight side step...

  Cliff,

    Take a look at the CYCLE code that is in the DW_EXAMPLES conference.
(not sure of exact note)  This program emualates what VWS did with the
F5 cycle function.  It changes focus of your decterm windows.  This might
give you some insight of how to change/give focus to windows with the help
of the DECwindow manager.

				-=> Jim <=-

    re: -2.  Toolkit popup dialog boxes have code to take focus if
             you ask them to.  They wait for the MapNotify to come back
             before asking.  In doesn't take long in "user-time", but
             in "computer-time" it can take a while...
    
    Leo

	re .18: But if you ask them to automatically take focus, they
	use CurrentTime, which could grab the focus away from a window
	the user has just given focus to. Plus, the application may want
	to set the focus to a particular text widget within the dialog
	box. Plus, it may be a main window widget rather than a popup
	dialog box that you're trying to give focus to. Real-world
	applications do have a need to set focus themselves.

	What we do is an XGetWindowAttributes on the window we want
	to give focus to and make sure it IsViewable before calling
	XtCallAcceptFocus. It helps, but doesn't totally eliminate
	those annoying BadMatch - X_SetInputFocus errors.

	Mike

    Here is a kludge to make it work: create a MainWindow containing a
    work window (DwtWindow). This work window is able to call a callback
    routine on the Expose event. And in this callback routine you
    can do a XSetInputFocus to a text widget of your application.
    This will grab the focus automatically once the application is started,
    without any click on any move of the mouse.
    
    Here is an example with the high level routines. I tested it on a Ultrix
    system, it works.
    By the way, it shows also how to change the focus from one text widget
    to another by simply hitting the Return key.
    
    Bernard
    
    
/* hellotext.c  1.5  89/06/16 */
/* simplest example of pushbuttom, text widget action table and
   input focus , using the High level routines */
/* author: Bernard Laforgue  Digital @VBO */
#include <stdio.h>
#ifdef VMS
#include <decw$include/DECwDwtApplProg.h>
#else
#include <X11/DECwDwtApplProg.h>
#endif
static void window_exposed();
static void helloworld_button_activate();
static void return_key();
static DwtCallback callback_arg[2];
static char translation[] = "<Key>0xff0d: return_key()\n\
<Key>0xff8d: return_key()";
static XtActionsRec action_table[] = { 
    {"return_key", (XtActionProc)return_key},
    {NULL, NULL}
};
Widget label, button, text1, text2;
int main(argc, argv)
unsigned int argc;
char **argv;
{
    Widget toplevel, helloworldmain, dialogw, workw;
    Arg arglist[2];
    /******** Set up the User Interface **********/
    toplevel = XtInitialize("hellotext","Helloclass", NULL, 0, &argc, argv);
    XtSetArg (arglist[0], XtNallowShellResize, TRUE) ;
    XtSetValues (toplevel, arglist, 1) ;
    helloworldmain = DwtMainWindow( toplevel, "mainwin", 0, 0, 170, 155);
    dialogw = DwtDialogBox( helloworldmain, "dialogw", TRUE,0,0,
		    DwtLatin1String("Hi v1.5"), DwtWorkarea, 0, 0);
    label = DwtLabel( dialogw, "label", 0, 0,
		DwtLatin1String(
    "Type in the lines or\nPress button once\nto change label;\ntwice to exit."
			       ), 0);
    XtManageChild(label);
    XtAddActions(action_table, 1);
    text1 = DwtSText(dialogw, "text", 0, 40, 20, 1, "line 1: ");
    DwtSTextSetEditable (text1, TRUE);
    XtOverrideTranslations(text1, XtParseTranslationTable(translation));
    XtManageChild(text1);
    text2 = DwtSText(dialogw, "text", 0, 55, 20, 1, "line 2: ");
    DwtSTextSetEditable (text2, TRUE);
    XtOverrideTranslations(text2, XtParseTranslationTable(translation));
    XtManageChild(text2);
    callback_arg[0].proc = helloworld_button_activate;
    callback_arg[0].tag = 0;
    callback_arg[1].proc = NULL;
    button = DwtPushButton( dialogw, "button", 15, 70,
    DwtLatin1String("Hello\nWorld!"), callback_arg, 0);
    XtManageChild( button);
    /* dummy work area, just to get an expose event */
    callback_arg[0].proc = window_exposed;
    workw = DwtWindow(helloworldmain, "workw", 0, 0, 10, 2, callback_arg);
    XtManageChild( workw);
    XtManageChild( dialogw); /* must be here to override workw */
    XtManageChild( helloworldmain);
    XtRealizeWidget( toplevel);
     /* XtInstallAccelerators(text, button); */
    XtMainLoop();
    return (0);
}

static void window_exposed( widget, tag, callback_data)
    Widget widget;
    char *tag;
    DwtAnyCallbackStruct *callback_data;
{
    /* set the input focus to the first text widget */
    /* this will grab the focus automatically to this aplication,
       at its creation without anay action on the mouse */
    XSetInputFocus(XtDisplay(text1), XtWindow(text1),
		   RevertToParent, CurrentTime);
}

static void helloworld_button_activate( widget, tag, callback_data)
    Widget widget;
    char *tag;
    DwtAnyCallbackStruct *callback_data;
{
Arg arglist[2];
static int call_count = 0;
call_count += 1 ;
switch ( call_count)
    {
    case 1:
        XtSetArg( arglist[0], DwtNlabel,
            DwtLatin1String("Goodbye\nWorld!"));
        XtSetValues( widget, arglist, 1);
        XtSetArg( arglist[0], DwtNlabel,
            DwtLatin1String("Press button to exit."));
        XtSetValues( label, arglist, 1);
        break ;
    case 2:
        exit(1);
        break ;
    }
}

static void return_key (widget, tag, callback_data)
    Widget widget;
    char *tag;
    DwtAnyCallbackStruct *callback_data;
{
    char *content;
    Arg arglist[1];
    Widget w;

    /* copies the content of the text to the pushbutton */
    content = DwtSTextGetString(widget);
    XtSetArg( arglist[0], DwtNlabel,
            DwtLatin1String(content));
    XtSetValues(button, arglist, 1);
    free(content);

    /* set the input focus to the other text widget */
    w = (widget==text1)? text2 : text1;
    XSetInputFocus(XtDisplay(w), XtWindow(w), RevertToParent, CurrentTime);
}
    
                                                

    Instead of calling XSetInputFocus directly, you should call
    XtCallAcceptFocus (widget, time).  There are two reasons I can think
    of:
    
    1.  The widget will call XSetInputFocus but may do other
        desirable things as well.  For example, telling its parent
        so that the parent remembers which widget currently has the focus,
        and can give it back if the window manager tells the application
        to take focus.
    
    2.  MOTIF uses a different "client-side" mechanism for handling
        focus.  Calling XSetInputFocus directly will mess that up
        (so if you ever plan to port your application...).
    
    Leo

    re: .20
        Sorry, the example I gave in .20 does not work on VMS, you must
    replace the line:
        free(content)
    by:
        XFree(content);
    and it will be OK. (I tested it while Leo wrote the reply .21)
    Actually, XFree should always by used for data allocated by X and
    DECwindows, on both systems. My apologize for this mistake.
    
    re: .21
       Ok Leo, I gonna try it.
    
    Bernard
    

	Do you want it to take the input focus after every expose event
	or just after the first one?

	Dan

    re: .21
      I tried on Ultrix to replace
     XsetInputFocus(XtDisplay(w), XtWindow(w), RevertToParent, CurrentTime);
      by
     XtCallAcceptFocus(w, CurrentTime);
     and I didn't managed to link:
       cc -o hellotext.x hellotext.o -ldwt -lXt -lX11
    Undefined:
    _XtCallAcceptFocus
    I tried first without -lXt, same result. Is there a new library to give
    in the link command or is it a known bug of UWS 2.0?
      Second question: can I use CurrentTime as second argument of 
    XtCallAcceptFocus? Else, what sould I use? time((long *)0) ?
    I tried both on VMS, I managed to link but I got Access violation.
    
    re: .-1 
      Good point. I think what Cliff needed was just after the first one.
    It would be a good idea to set a flag to avoid to take the input focus
    on each event.
      Actually I just wanted to test the feasibility to take the input
    focus at start time. I haven't yey used it in a real application.
      It is true that it violates the style guide and can cause you some
    surprise, say if you start it in background and you continue to type
    in your DECterm window. Suddenly when the window is mapped, what you're
    typing is going into the new window and maybe this was not what you
    expected.
    
    Bernard

>      I tried on Ultrix to replace
>     XsetInputFocus(XtDisplay(w), XtWindow(w), RevertToParent, CurrentTime);
>      by
>     XtCallAcceptFocus(w, CurrentTime);
>     and I didn't managed to link:
>       cc -o hellotext.x hellotext.o -ldwt -lXt -lX11
>    Undefined:
>    _XtCallAcceptFocus

I've seen someone else complain about this in a notes file recently, so
maybe it wasn't in UWS 2.0.  A work-around is to get the address of the
accept_focus procedure from the widget class record, and call it.   

>   Second question: can I use CurrentTime as second argument of 
>   XtCallAcceptFocus? Else, what sould I use? time((long *)0) ?
>   I tried both on VMS, I managed to link but I got Access violation.

Yes, you can use CurrentTime, but the time is not passed by value but
by reference.  So you need to declare a variable of type Time, assign
CurrentTime to it and pass the address of the variable.  For example:

Time time = CurrentTime;

XtCallAcceptFocus (w, &time);

Leo

    Re XtCallAcceptFocus not available:

    That's the problem I'm currently banging my head against...
    XtCallAcceptFocus is unheard of for UWS 2.0 on VAXen, but is available
    on UWS 2.1 for PMAXen. I could always hack something, but that would
    mean touching the files, which I can't do. TGIF.

    Denis.