CrtErrHdlr.3
上传用户:rrhhcc
上传日期:2015-12-11
资源大小:54129k
文件大小:6k
- '"
- '" Copyright (c) 1990 The Regents of the University of California.
- '" Copyright (c) 1994-1996 Sun Microsystems, Inc.
- '"
- '" See the file "license.terms" for information on usage and redistribution
- '" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
- '"
- '" RCS: @(#) $Id: CrtErrHdlr.3,v 1.2 1998/09/14 18:22:46 stanton Exp $
- '"
- .so man.macros
- .TH Tk_CreateErrorHandler 3 "" Tk "Tk Library Procedures"
- .BS
- .SH NAME
- Tk_CreateErrorHandler, Tk_DeleteErrorHandler - handle X protocol errors
- .SH SYNOPSIS
- .nf
- fB#include <tk.h>fR
- .sp
- Tk_ErrorHandler
- fBTk_CreateErrorHandlerfR(fIdisplay, error, request, minor, proc, clientDatafR)
- .sp
- fBTk_DeleteErrorHandlerfR(fIhandlerfR)
- .SH ARGUMENTS
- .AS "Tk_ErrorHandler" clientData
- .AP Display *display in
- Display whose errors are to be handled.
- .AP int error in
- Match only error events with this value in the fIerror_codefR
- field. If -1, then match any fIerror_codefR value.
- .AP int request in
- Match only error events with this value in the fIrequest_codefR
- field. If -1, then match any fIrequest_codefR value.
- .AP int minor in
- Match only error events with this value in the fIminor_codefR
- field. If -1, then match any fIminor_codefR value.
- .AP Tk_ErrorProc *proc in
- Procedure to invoke whenever an error event is received for
- fIdisplayfR and matches fIerrorfR, fIrequestfR, and fIminorfR.
- NULL means ignore any matching errors.
- .AP ClientData clientData in
- Arbitrary one-word value to pass to fIprocfR.
- .AP Tk_ErrorHandler handler in
- Token for error handler to delete (return value from a previous
- call to fBTk_CreateErrorHandlerfR).
- .BE
- .SH DESCRIPTION
- .PP
- fBTk_CreateErrorHandlerfR arranges for a particular procedure
- (fIprocfR) to be called whenever certain protocol errors occur on a
- particular display (fIdisplayfR). Protocol errors occur when
- the X protocol is used incorrectly, such as attempting to map a window
- that doesn't exist. See the Xlib documentation for fBXSetErrorHandlerfR
- for more information on the kinds of errors that can occur.
- For fIprocfR to be invoked
- to handle a particular error, five things must occur:
- .IP [1]
- The error must pertain to fIdisplayfR.
- .IP [2]
- Either the fIerrorfR argument to fBTk_CreateErrorHandlerfR
- must have been -1, or the fIerrorfR argument must match
- the fIerror_codefR field from the error event.
- .IP [3]
- Either the fIrequestfR argument to fBTk_CreateErrorHandlerfR
- must have been -1, or the fIrequestfR argument must match
- the fIrequest_codefR field from the error event.
- .IP [4]
- Either the fIminorfR argument to fBTk_CreateErrorHandlerfR
- must have been -1, or the fIminorfR argument must match
- the fIminor_codefR field from the error event.
- .IP [5]
- The protocol request to which the error pertains must have been
- made when the handler was active (see below for more information).
- .PP
- fIProcfR should have arguments and result that match the
- following type:
- .CS
- typedef int Tk_ErrorProc(
- ClientData fIclientDatafR,
- XErrorEvent *fIerrEventPtrfR);
- .CE
- The fIclientDatafR parameter to fIprocfR is a copy of the fIclientDatafR
- argument given to fBTcl_CreateErrorHandlerfR when the callback
- was created. Typically, fIclientDatafR points to a data
- structure containing application-specific information that is
- needed to deal with the error. fIErrEventPtrfR is
- a pointer to the X error event.
- The procedure fIprocfR should return an integer value. If it
- returns 0 it means that fIprocfR handled the error completely and there
- is no need to take any other action for the error. If it returns
- non-zero it means fIprocfR was unable to handle the error.
- .PP
- If a value of NULL is specified for fIprocfR, all matching errors
- will be ignored: this will produce the same result as if a procedure
- had been specified that always returns 0.
- .PP
- 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 subsequent (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.
- .PP
- 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 fBTk_CreateErrorHandlerfR;
- disobey it at your own risk.
- .PP
- fBTk_DeleteErrorHandlerfR may be called to delete a
- previously-created error handler. The fIhandlerfR argument
- identifies the error handler, and should be a value returned by
- a previous call to fBTk_CreateEventHandlerfR.
- .PP
- A particular error handler applies to errors resulting
- from protocol requests generated between
- the call to fBTk_CreateErrorHandlerfR and the call to
- fBTk_DeleteErrorHandlerfR. However, the actual callback
- to fIprocfR may not occur until after the fBTk_DeleteErrorHandlerfR
- call, due to buffering in the client and server.
- If an error event pertains to
- a protocol request made just before calling fBTk_DeleteErrorHandlerfR,
- then the error event may not have been processed
- before the fBTk_DeleteErrorHandlerfR
- call. When this situation arises, Tk will save information about
- the handler and
- invoke the handler's fIprocfR 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 fBTk_DeleteErrorHandlerfR and then
- call fBXSyncfR; 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
- fBXSyncfR call Tk is guaranteed not to call any error
- handlers deleted before the fBXSyncfR call.
- .PP
- For the Tk error handling mechanism to work properly, it is essential
- that application code never calls fBXSetErrorHandlerfR directly;
- applications should use only fBTk_CreateErrorHandlerfR.
- .SH KEYWORDS
- callback, error, event, handler