| ||||||
|
|
Tk_CreateErrorHandlerPrepared by Ready-to-Run Software, Inc. Tk_CreateErrorHandler(Tk Library Procedures_________________________________________________________________ Tk_CreateErrorHandler(Tk Library Procedures
ClientData clientData (in) Arbitrary one-word
value to pass to
proc.
Tk_ErrorHandler handler (in) Token for error
handler to delete
(return value from
a previous call to
Tk_CreateErrorHandler).
_________________________________________________________________
Tk_CreateErrorHandler(Tk Library Procedures
the error completely and there is no need to take any other
action for the error. If it returns non-zero it means proc
was unable to handle the error.
If a value of NULL is specified for proc, all matching
errors will be ignored: this will produce the same result
as if a procedure had been specified that always returns 0.
If more than more than one handler matches a particular
error, then they are invoked in turn. The handlers will be
invoked in reverse order of creation: most recently
declared handler first. If any handler returns 0, then sub-
sequent (older) handlers will not be invoked. If no handler
returns 0, then Tk invokes X'es default error handler, which
prints an error message and aborts the program. If you wish
to have a default handler that deals with errors that no
other handler can deal with, then declare it first.
The X documentation states that ``the error handler should
not call any functions (directly or indirectly) on the
display that will generate protocol requests or that will
look for input events.'' This restriction applies to
handlers declared by Tk_CreateErrorHandler; disobey it at
your own risk.
Tk_DeleteErrorHandler may be called to delete a previously-
created error handler. The handler argument identifies the
error handler, and should be a value returned by a previous
call to Tk_CreateEventHandler.
A particular error handler applies to errors resulting from
protocol requests generated between the call to
Tk_CreateErrorHandler and the call to Tk_DeleteErrorHandler.
However, the actual callback to proc may not occur until
after the Tk_DeleteErrorHandler call, due to buffering in
the client and server. If an error event pertains to a pro-
tocol request made just before calling
Tk_DeleteErrorHandler, then the error event may not have
been processed before the Tk_DeleteErrorHandler call. When
this situation arises, Tk will save information about the
handler and invoke the handler's proc later when the error
event finally arrives. If an application wishes to delete
an error handler and know for certain that all relevant
errors have been processed, it should first call
Tk_DeleteErrorHandler and then call XSync; this will flush
out any buffered requests and errors, but will result in a
performance penalty because it requires communication to and
from the X server. After the XSync call Tk is guaranteed
not to call any error handlers deleted before the XSync
call.
Tk 3
Prepared by Ready-to-Run Software, Inc.
Tk_CreateErrorHandler(Tk Library Procedures
For the Tk error handling mechanism to work properly, it is
essential that application code never calls XSetErrorHandler
directly; applications should use only
Tk_CreateErrorHandler.
|
|
|
Email addresses listed on this site may NOT be used for unsolicited commercial email. Ready-to-Run Software, Inc Privacy Statement Portions (c)Copyright, 1996-2005 by
Ready-to-Run
Software, Inc |
To return to the Ready-to-Run Software WinPak Table of contents please presshere