| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 854.1 | | 19584::BRANDENBERG | Si vis pacem para bellum | Tue May 30 1989 14:25 | 14 |
|
The neatest way I know of detecting an error on a particular
request is to:
XSync()
Replace error handler with your own special one
XAsyncRequestThatMightFail()
XSync()
Restore original error handler
If there's a neater way, I'd like to hear about it...
m
|
| 854.2 | | 32148::KLEINSORGE | Toys 'R' Us | Tue May 30 1989 16:26 | 6 |
|
Yup. That's my hack, but I was hoping for something a little neater...
Thanks, _Fred
|
| 854.3 | why are pixmap errors more difficult than other types | HANNAH::OSMAN | see HANNAH::IGLOO$:[OSMAN]ERIC.VT240 | Thu Jun 01 1989 16:07 | 13 |
|
Can someone please explain more about this ? Some things I'm puzzled about:
o I assume you're talking about XCreatePixmap ? Can't we just look at
the result, and 0 means it failed ?
o Why would we need special methods of detecting this error than
other sorts of errors ?
Thanks.
/Eric
|
| 854.4 | | VWSENG::KLEINSORGE | Toys 'R' Us | Thu Jun 01 1989 17:27 | 18 |
| This is probably why DECterm goes bonkers when it can't create backing
store :-(
- No, you can't just "check for zero", 99% of all Xlib calls are NOT
synchronous. Xlib sends the request off (the next time the buffer is
flushed) and returns a identifier for the pixmap -- at some future point
in time the server *might* send back an error asynchronous to program
execution. So you need to use one of the synchronize mechanisms and set
up (at least temporarily) a error handler for non-fatal X errors. The
first synch makes sure there are no errors still not seen, you try to
create the pixmap - if you get past the next SYNCH without the error
routine being invoked -- you've succeeded in the create -- otherwise
you've failed and you can take the appropriate actions... I was just
hoping that there was some way to identify the operation in the error
routine without the need for a SYNCH... like if there was a way to get
the current serial number before making the pixmap create request...
|
| 854.5 | Pity... | HANNAH::MESSENGER | Bob Messenger | Sat Jun 03 1989 17:17 | 11 |
| Re: .4
> This is probably why DECterm goes bonkers when it can't create backing
> store :-(
I naively assumed that since I was getting back a pixmap ID the server "must"
have synchronized the request. Unfortunately I probably won't have a chance
to fix this any time soon.
-- Bob
|
| 854.6 | Ideas | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Sun Jun 04 1989 17:08 | 18 |
| Fred,
I have not gone back to read all this over again to re-get the context
and see if what I am about to say is relavent, but:
1. There is a macro (at least in V2 if not V1) to get the current
serial number, and
2. If you did something like a GetImage (of a 1x1 area) on the pixmap
after you create it, you should be able to figure out pretty quickly.
If the GetImage fails, for example, the pixmap is not there. And the
GetImage is synchronous. Don't have my Xlib book at home, so I don't
know if you would still have to set up an error handler, of if GetImage
has a status return.
Burns
|
| 854.7 | | VWSENG::KLEINSORGE | Toys 'R' Us | Mon Jun 05 1989 09:52 | 10 |
|
Great! If you find out the name of the Macro, I'll check out alternate
means of accomplishing what I want without need to synchronize... if
I remember right, the error block has the serial number of the request
just prior to the failing one... so I can set up a error handler that
can check for specific known requests where I might expect a failure
(like backing store pixmap allocation). If I pick up the current
serial number just before the call...
|
| 854.8 | XNextRequest | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Mon Jun 05 1989 16:47 | 4 |
| The handy-dandy book reader says it is "XNextRequest". It is in version 1.
Burns
|
| 854.9 | | VWSENG::KLEINSORGE | Toys 'R' Us | Mon Jun 05 1989 17:04 | 5 |
|
Silly me. I never thought to look there. Thanks!
_Fred
|