Conference bulova::decw_jan-89_to_nov-90

    Also, when this condition is signalled (on VMS), user-mode ASTs are
    disabled.  This means that my condition-handler has to be very
    carefully coded to avoid a deadlock.  In particular, I can't do any
    Ada I/O in the condition-handler without locking up the program.
    

	Nothing to do with AST's - you can't set input focus to an
	iconified window. Your file-selection widget must be parented
	to your shell, and been iconified at the time it was mapped
	and the attempt was made to set focus to it. The best way to
	avoid this is to set focus in an event handler for the
	MapNotify event, but even that's no guarantee - you should also
	set up an X error handler which will ignore BadMatch errors
	on X_SetInputFocus.

	Mike

/* vtkerrorhandler.c

*****************************************************************************
*									    *
*  COPYRIGHT (c) 1989  BY               				    *
*  DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS.		    *
*  ALL RIGHTS RESERVED.						    	    *
* 									    *
*  THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED    *
*  ONLY IN  ACCORDANCE WITH  THE  TERMS  OF  SUCH  LICENSE  AND WITH THE    *
*  INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR  ANY  OTHER    *
*  COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY    *
*  OTHER PERSON.  NO TITLE TO AND OWNERSHIP OF  THE  SOFTWARE IS  HEREBY    *
*  TRANSFERRED.							            * 
* 									    *
*  THE INFORMATION IN THIS SOFTWARE IS  SUBJECT TO CHANGE WITHOUT NOTICE    *
*  AND  SHOULD  NOT  BE  CONSTRUED AS  A COMMITMENT BY DIGITAL EQUIPMENT    *
*  CORPORATION.							            *
* 									    *
*  DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE  OR  RELIABILITY OF ITS    *
*  SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.		    *
*									    *
*****************************************************************************

FACILITY:	FileView
ENVIRONMENT:	DECwindows
AUTHORS:	Steve Klein

	This module contains the replacement XLib error handler for FileView.

MODIFICATION HISTORY:

16-May-1989 (sjk) Remove call to lib$signal, since it adds no information.
15-May-1989 (sjk) Initial entry.
*/

#include "stdio.h"
#include "decw$xlibmsg.h"
#include "MrmAppl.h"
#include "XProto.h"

#define BUFSIZ 256

static void ErrorHandler(dpy, event)
    Display *dpy;
    XErrorEvent *event;
{
    char bufA[BUFSIZ];
    char msgA[BUFSIZ];
    char numberA[32];
    char *mtype = "XlibMessage";

    /* Ignore soft errors. */

    if (
	/* Attempted to assign input focus to a window, but that window was 
	 * iconified at the time the server processed the request. */

        ((event->error_code == BadMatch) &&
         (event->request_code == X_SetInputFocus)) ||

	/* Attempted to select for ButtonPress on the root window, but
	 * another application already has selected for it. */

        ((event->error_code == BadAccess) &&
         (event->request_code == X_ChangeWindowAttributes))) return;

    XGetErrorText (dpy, event->error_code, bufA, BUFSIZ);
    XGetErrorDatabaseText (dpy, mtype, "XError", "X Error", msgA, BUFSIZ);
    fprintf (stderr, "%s:  %s\n  ", msgA, bufA);
    XGetErrorDatabaseText (dpy, mtype, "MajorCode", "Request Major code %d", 
	msgA, BUFSIZ);
    fprintf (stderr, msgA, event->request_code);
    sprintf (numberA, "%d", event->request_code);
    XGetErrorDatabaseText (dpy, "XRequest", numberA, "", bufA, BUFSIZ);
    fprintf (stderr, " (%s)", bufA);
    fputs ("\n  ", stderr);
    XGetErrorDatabaseText (dpy, mtype, "MinorCode", "Request Minor code", 
	msgA, BUFSIZ);
    fprintf (stderr, msgA, event->minor_code);
    fputs ("\n  ", stderr);
    XGetErrorDatabaseText (dpy, mtype, "ResourceID", "ResourceID 0x%x",
	msgA, BUFSIZ);
    fprintf (stderr, msgA, event->resourceid);
    fputs ("\n  ", stderr);
    XGetErrorDatabaseText (dpy, mtype, "ErrorSerial", "Error Serial #%d", 
	msgA, BUFSIZ);
    fprintf (stderr, msgA, event->serial);
    fputs ("\n  ", stderr);
    XGetErrorDatabaseText (dpy, mtype, "CurrentSerial", "Current Serial #%d",
	msgA, BUFSIZ);
    fprintf (stderr, msgA, dpy->request);
    fputs ("\n", stderr);
}

void VtkSetErrorHandler()
{
    XSetErrorHandler (ErrorHandler);
}

Re .-1
    >	Nothing to do with AST's
    
    	No, I wasn't suggesting that the problem had anything to do with
    ASTs.  However, when the error is raised, user-mode ASTs are disabled,
    which seems like bad practice, since it makes writing a generic
    condition-handler for an application difficult.
    
>	The best way to
>	avoid this is to set focus in an event handler for the
>	MapNotify event, but even that's no guarantee - you should also
>	set up an X error handler which will ignore BadMatch errors
>	on X_SetInputFocus.
    
    If this is required, shouldn't the file-selection widget do it itself?
    After all, it's the widget (not my code) that is doing the
    SetInputFocus.  Probably all modal widgets ought to be prepared for
    this possibility.
    
    John

	An X error handler is global to your application - you really don't
	want widgets taking it upon themselves to set up error handlers.

	Mike

>	An X error handler is global to your application - you really don't
>	want widgets taking it upon themselves to set up error handlers.
    
    True.  This is probably a deficiency in the toolkit itself, in that
    error-handling requirements typically aren't global to the application,
    so the toolkit ought to provide some local (either stack-based or
    widget-based) error-handling functionality.
    
    In this particular case, though, the preferred solution would be for
    the widget to avoid raising the error in the first place.  Is it really
    that difficult for it to check whether it is iconized before it tries
    to SetFocus?

>>    In this particular case, though, the preferred solution would be for
>>    the widget to avoid raising the error in the first place.  Is it really
>>    that difficult for it to check whether it is iconized before it tries
>>    to SetFocus?

Actually, it is impossible.  Because of the asynchronous window manager
activity, a check may say "Yes, you're mapped", and by the time the
XSetFocus call is received by the server, the window manager has iconified
the window.

I don't see any way around using an error handler.

-steve

> Actually, it is impossible.  Because of the asynchronous window manager
> activity, a check may say "Yes, you're mapped", and by the time the
> XSetFocus call is received by the server, the window manager has iconified
> the window.

The widget could grab the server, check whether it is mapped, and only if
it is, set the input focus, and then ungrab the server.  Voila--no async
window manager activity.

/jeff

Whether it's a good idea for clients to go around grabbing the server
is another question...