Conference bulova::decw_jan-89_to_nov-90

>   Is
>   there any way of doing this - something to map request-ids back to the
>   widget that generated them, and give me some information about what it
>   was that the toolkit was trying to do that caused the X-error?
 
About the only thing that helps is to call XSynchronize after initializing
the toolkit.  Then, the server error will be reported while you are
executing the Xt call rather than "sometime later" which is the default.

Leo   

    Would something like this (an X-error decoder, built into the toolkit)
    be feasible, or are there insurmountable difficulties?  It seems very
    bad practice to give a user/programmer error information at a different
    level from the level that actually caused the error.  Layered software
    ought to either translate obscure errors signalled by lower layers, or
    correct them.
    
    Is there a DECwindows phase 0 conference for wishlist items?
    
    For the moment I guess I'll have to do synchronous IO to find out
    what's going wrong.
    
    John

    The toolkit group has been thinking about ways to help application
    developers debug programs.  Your suggestion is one we hadn't thought
    about.  We'll add it to our list.
    
    Leo

    If it is a goal for the toolkit to become "programmer-friendly", the
    most important change would be to put in some error-checking of
    parameters to toolkit procedures (catch errors as soon as possible,
    when it's easy to report what's wrong).  Some examples that spring to
    mind:
    
    1)	Check that sufficient parameters have been passed to each
    	procedure.
    
    2)  Check that all attribute names passed to XT$SET_VALUES/XT$GET_VALUES
    	are supported by the widget.
    
    3)	Whenever a procedure expects a widget as an argument, check that
    	what's supplied _is_ a widget (eg check that the first field is a
    	self-pointer).
    
    4)	The only time the toolkit should ever access-violate is if the
    	user supplies a pointer parameter that points to memory that isn't
    	accessible to him, and these access violations should occur within
    	a few instructions of entering the toolkit.  _Any_ other programming
    	errors (including invalid pointers internal to records) should result
    	in meaningful toolkit errors.
    
    A few simple (and low-cost) checks like this would make programming the
    toolkit so much easier.
    
    John

But it would also slow down an already too slow toolkit.  I'd rather have 
a debug toolkit with the extra checking and a toolkit with no checking which
is what my applications link with.

    But the checks I'm talking about here would be required only once per
    toolkit call, not on every internal call within the toolkit.  In my
    experience the slowness of applications occurs within the toolkit, not
    because the applications have to call enormous numbers of toolkit
    procedures, so adding a few instructions to validate arguments wouldn't
    affect things much.
    
    Also, much on .3 could be implemented with error-path code only (eg
    access-violation decoders), so you only pay for the extra robustness
    when you need it.
    
    John

RE: .6

The access violation decoder approach would only work on VMS.  It won't work on
Unix or any other operating system that doesn't support procedure-based
condition handling.

I'm inclined to agree with .5--we don't need anything that slows the already
slow Toolkit down.  However, there are things that could be done to aid in
debugging.  Linking the toolkit shareable image /DEBUG, for example, so that
at least you have some idea of where things are blowing up.

--PSW