mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (11/15/89)
> 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
jg@max.crl.dec.com (Jim Gettys) (11/17/89)
I claim you are right (and I wrote the original spec). XQueryTree should return status, and not generate BadWindow errors. No error handler should ever be called. I believe the specification is correct as written, and very clear on this point, and is precisely what I intended. I can certainly believe the current implementation is defective... Jim Gettys Digital Equipment Corporation Cambridge Research Laboratory
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (11/17/89)
I believe the specification is correct
as written, and very clear on this point, and is precisely what I
intended.
I might be willing to take your word on intent, but *very* clear? Section 4.1
says "Because they are most frequently used by window managers, these functions
all return a status to indicate whether the window still exists." Yet two of
the functions in this section, XGetWindowAttributes and XQueryPointer,
explicitly state that they generate errors, and the other two, XQueryTree and
XGetGeometry, do not. And one of the functions, XQueryPointer, returns Bool,
not Status, and the bool has nothing to do with status. This looks a lot more
like inconsistency than "very clear".jg@CRL.DEC.COM (11/17/89)
I concede the point; it is not "very" clear.... My intent was encapsulated by the sentence about window managers. I suspect on the errors listed what happened was they were added mistakenly when we went through the library trying to identify what errors each could generate. But doing document archeology to determine when the errors went into the spec seems pointless. In any case, my claim is that those routines should never generate errors, but return an error indication to the caller. - Jim