Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!brunix!irwin!jhc
From: jhc@irwin.uucp (James H. Coombs)
Newsgroups: comp.windows.x
Subject: Re: XtAddInput returns; error checking in general
Message-ID: <64855@brunix.UUCP>
Date: 13 Feb 91 16:56:18 GMT
References: <64840@brunix.UUCP>
Sender: news@brunix.UUCP
Reply-To: jhc@irwin.UUCP (James H. Coombs)
Organization: IRIS - Brown University
Lines: 29

In article <64840@brunix.UUCP> jhc@ivan.uucp (James H. Coombs) writes:
>In the man page for XtAddInput()/XtAppAddInput(), I don't see any error
>condition to check for.  The call returns an XtInputId, and I suppose
>that I am to treat that as opaque information.  Is that right?  I
>checked the source code, but I would like some verification on this.

Actually, the problem is a little deeper than I first thought.  I need
to keep a table of descriptor-XtInputId mappings.  In order to
determine whether or not I have called XtAddInput() for a descriptor, I
need to know the null/zero/notset value for XtInputId.  If I don't have
that, then I have to maintain a boolean in addition.  This seems like a
lot of extra mechanics just to check on an id.

Perhaps what we need is for the documentation to say OPAQUE if it
really is opaque.  In general, however, it seems unlikely that
committing Xt to zero/non-zero would create any hardships in
development.

While I am at it, I may as well complain about the fact that
XtAddInput() takes a XtPointer for the condition.  In fact, this is an
XtInputMask that is cast to an XtPointer and then back to an
XtInputMask in the implementatation of XtAddInput().  Note that you do
not actually provide the *address* of the mask; instead, you set an
XtInputMask and cast it to an XtPointer for a routine that really wants
an input mask.  This is confusing at the least.  Or, perhaps someone
can clarify the role of XtPointer.  Is there some general principle
that I am missing?

Thanks.  --Jim