Path: utzoo!attcan!sobmips!uunet!aplcen!samsung!shadooby!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: XQueryTree and BadWindow errors
Message-ID: <8911150456.AA26384@Larry.McRCIM.McGill.EDU>
Date: 15 Nov 89 04:56:10 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 92

> I have a window id. obtained via various means, in most cases from a
> property on the root window and I wish to check whether that window
> still exists in the server.  Looking at the Xlib manual in Chapter 4
> I find:

> 4.1 Obtaining Window Information

> [ ... ] Because they are most frequently used by window managers,
> these functions all return a status to indicate whether the window
> still exists.

> [they generate BadWindow errors as well.]

I never did understand this: since they *are* for use by window
managers, who presumably *would* rather get a return status than a
BadWindow error, why do they generate the error at all?

I asked xpert something very similar at the time I discovered this and
got a note similar to this reply, which I see was sent to you as well
as to xpert:

> From: rws@expo.lcs.mit.edu (Bob Scheifler)
>> From my reading of section 4.1 if a bad Window is passed then it
>> should return a Status of 0 (failure).  Should this be happening?
> Yes, if your error handler returns.
>> Do I have to trap the error using an error handler?
> Yes.
>> If I do have to install an error handler how can I re-install the
>> previous error handler if one had been installed (*I* cannot know
>> about previous handlers that may have been installed)?
> In R4, XSetErrorHandler and XSetIOErrorHandler return the old
> handler.
[Presumably all X development is supposed to be put on hold until R4 is
 released or something, or we're supposed to live with the occasional
 BadWindow crash.]

At the very least, I would like to see it made obvious in the
documentation that a BadWindow error is generated in addition to the
return status indicating whether the window exists or not.  (It clearly
is not sufficiently obvious now!)

I'm curious about the rationale for making query functions like
XQueryTree cause BadWindow errors as well as returning the status.  Can
anyone explain this to us?  What does generating the error give us that
not generating it wouldn't?

In my case, I couldn't simply install my own error handler, because
there is no (documented) way to have Xlib perform the default error
handler action when you've decided the error isn't one you want to just
ignore.  (It's possible, but relies on an undocumented internal
function Xmusomethingorother.)  And I wasn't about to rewrite the code
to pick apart the error object.

So what I did was this.  Somewhat ugly, but until either (a) the Xmu
routines are documented, (b) the Xlib window information functions are
fixed so they don't produce spurious BadWindow errors (yes, that's my
opinion of the current behavior), or (c) R4 comes out so we can install
an error handler for just the duration of one call....

int window_exists(w)
Window w;
{
 Window root;
 Window parent;
 Window *children;
 int nchildren;
 int rv;
 int i;

 XQueryTree(disp,rootwin,&root,&parent,&children,&nchildren);
 rv = 0;
 for (i=0;i<nchildren;i++)
  { if (children[i] == w) rv = 1;
  }
 XFree((char *)children);
 return(rv);
}

Note that this assumes the window in question is a direct child of the
root (in my application, this is true), and that the server is grabbed
when this is called (which must be true for such a function to be
useful in any case - otherwise, the return value could be out-of-date
even before we get it and we have the same race all over again).

Sigh.  Three misfeatures out of a whole windowing system is an
impressively good record, but that doesn't stop me from being annoyed
by the misfeatures.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu