Path: utzoo!attcan!uunet!mcsun!ukc!harrier.ukc.ac.uk!rlh2
From: rlh2@ukc.ac.uk (Richard Hesketh)
Newsgroups: comp.windows.x
Subject: Re: R5 wish list
Message-ID: <5201@harrier.ukc.ac.uk>
Date: 29 Jul 90 12:23:59 GMT
References: <1963@lri.lri.fr> <5677@hplabsz.HPL.HP.COM> <5196@harrier.ukc.ac.uk> <5679@hplabsz.HPL.HP.COM>
Reply-To: rlh2@ukc.ac.uk (Richard Hesketh)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 53
Summary:
Expires:
Sender:
Followup-To:

In article <5679@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes:
>In article <5196@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh), I write:
>>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).

>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.

>  XtSetErrorHandler(Winterp_Xtoolkit_Error_Handler);
>  XtSetWarningHandler(Winterp_Xtoolkit_Warning_Handler);

I already have an error widget which does this for me, it intercepts
and displays both Xt Warning and Xlib Protocol errors in a suitable
scrolling text widget with clear and hide buttons.  It can also popup
and beep at me 8-).

> * This handles fatal errors from the Xtoolkit. According to the Xtoolkit
> * docs, such a handler should terminate the application.

I would very much rather like to follow the spec. on this one and let the
application die, as I have *no control* over what the Intrinsics are doing,
(i.e. fiddling with memory and pointers).

However on further investigation I see that the one error I don't like
could be handled with the *current* implementation of the Intrinsics
by replacing the XtCreateWindow() routine with one that causes the window
to inherit its parents dimensions.

>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.

This is very easy via the use of XSetErrorHandler() which is
better than the Xt Warning equivalent.  You can capture all the BadWindow,
BadMatch etc. errors and cope with them.   In R4 this function now returns
the previous error handler (my one claim to fame 8-) so that you can quickly
set and unset error handlers and thus enable "wrappers" to be placed around
X requests.

The handler is passed the display and a pointer to an XErrorEvent structure
which describes the error in enough detail to be able to recover from
it (i.e. type of request and type of error;  XCreateWindow & BadMatch).

Richard Hesketh   :   @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk
		  :   rlh2@ukc.ac.uk    ..!mcsun!ukc!rlh2
---                                               
Computing Lab., University of Kent at Canterbury,
Canterbury, Kent, CT2 7NF, United Kingdom.    Tel: +44 227 764000 ext 7620/3682