Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sdd.hp.com!hplabs!hplabsz!mayer
From: mayer@hplabsz.HPL.HP.COM (Niels Mayer)
Newsgroups: comp.windows.x
Subject: Re: R5 wish list
Message-ID: <5679@hplabsz.HPL.HP.COM>
Date: 28 Jul 90 23:35:41 GMT
References: <1963@lri.lri.fr> <5677@hplabsz.HPL.HP.COM> <5196@harrier.ukc.ac.uk>
Reply-To: mayer@hplabs.hp.com (Niels Mayer)
Organization: Hewlett-Packard Labs, Software & Systems Lab, Palo Alto, CA.
Lines: 92
Summary:
Expires:
Sender:
Followup-To:

In article <5196@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes:
>While we are on the subject of warning generation in Xt;  I would very
>much like to see atleast one error message to be changed to a warning message
>instead (and thus not causing the application to die).
>The error I am thinking of is ...
>
>		"Widget blah has zero width and/or height"
>
>This hurts my user interface builder; when a widget is to be created and
>does not calculate a default window size,  I would like to be graciously
>informed of this via a Warning which I can ignore (I don't mind if the window
>is given a 1x1 size).  I just don't want my builder falling over from a
>silly Error that can be dealt with simply.

Here's how I handle "overriding" Xt warnings in WINTERP. In WINTERP
Xtoolkit warnings & fatal errors don't cause the program to exit; rather it
returns control to the interpreter's debugging loop (by calling xlfail())
so you can figure out and fix what when wrong and then continue on with
programming.

From winterp/src-server/winterp.c:

------------------------------------------------------------------------------
main(...)
{
...
  /*
   * Setup Xtoolkit warning and error handlers so that errors inside
   * the Xtoolkit will call xlerror().
   */
  XtSetErrorHandler(Winterp_Xtoolkit_Error_Handler);
  XtSetWarningHandler(Winterp_Xtoolkit_Warning_Handler);
...
}

/*******************************************************************************
 * This handles fatal errors from the Xtoolkit. According to the Xtoolkit
 * docs, such a handler should terminate the application. In this case,
 * however, we suggest to the user that the application be terminated, but
 * don't actually do it. This may allow the user to figure out what went 
 * wrong by poking around inside the lisp environment.
 *
 * This is set up in main() via XtSetErrorHandler(). Note that the default
 * error handler is _XtDefaultError().
 ******************************************************************************/
static XtErrorMsgHandler Winterp_Xtoolkit_Error_Handler(message)
     String message;
{
  sprintf(temptext, "X Toolkit Fatal Error -- PLEASE QUIT AND RESTART THIS APPLICATION -- %s\n", message);
  xlfail(temptext);
}


/*******************************************************************************
 * This handles nonfatal errors from the Xtoolkit.
 *
 * This is set up in main() via XtSetWarningHandler(). Note that the default
 * error handler is _XtDefaultWarning().
 ******************************************************************************/
static XtErrorMsgHandler Winterp_Xtoolkit_Warning_Handler(message)
     String message;
{
  sprintf(temptext, "X Toolkit Warning: %s\n", message);
  xlfail(temptext);
}
------------------------------------------------------------------------------


PS: One WINTERP improvement I want to add is to override X protocol errors
Is this possible? Is this safe to do?? I need to RTFM on this before I
decide to add such a feature to WINTERP, and do it in my copious spare
time.

Why do I want this... well, for example, doing (send widget :unmap) on an
unrealized widget exits WINTERP and generates the annoying message

> X Protocol error detected by server:  not a valid window ID
>   Failed request major op code 10 (X_UnmapWindow)
>   Failed request minor op code 0 (if applicable)
>   ResourceID 0x0 in failed request (if applicable)
>   Serial number of failed request 2103
>   Current serial number in output stream 2104

And I'd much rather just fix the code and re-interpret it rather than have
to restart WINTERP.

-------------------------------------------------------------------------------
	    Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
		  Human-Computer Interaction Department
		       Hewlett-Packard Laboratories
			      Palo Alto, CA.
				   *