[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

2293.0. "XMultiplexInput error?" by SHARIF::BULLARD (Seize the day !!) Fri Feb 16 1990 15:10

/*  I sent a customer the following code fragment which  demonstrates how to 
communicate with the user from a callback using the Work in progress widget .
It demonstrates how to temporarily manage the event queue from within a 
callback. The code works happily for me but when the customer implemented it
he got the following error :-

	X Toolkit Error :Error in MultiplexInput
	%DWT-F-DWTABORT, xtoolkit fatal error

	This message is not documented anywhere. Can anyone explain why it
might fail when used in a larger application.It works in a small simple
application. Have I just been lucky? I suspect that there is some sort of
interaction that I am don't have to worry about but the customer is not aware
of. Any pointers?

regards Mark					  */

void wndw_flush ();
XEvent event ;    */

Widget toplevel_widget, main_window_widget,my_caution_widget;
Widget global_widget_id;                               

Display *display;
Window  *wipwindow;                                    

/* Here I have fetch the widgets (defined via UIL) and I am displaying a 
 work in progress box in which I want text to appear while I 'doze' for  10
 secs to simulate real work. The customer gets the problem at the XtPeekEvent
 call in the routine 'wndw_flush' */
                               
       XtManageChild (my_work_widget) ;
	wndw_flush (display,my_work_widget);
	XtSetArg (arglist [0],DwtNfirstTopic, topic);
	XtSetValues (my_help_widget,arglist,1);
        
 	if (!XtIsManaged (my_help_widget))  {                                  
        XtManageChild (my_help_widget);
	XFlush (display);
	} 
	printf ("dozing for a while....ZZZZZZ ...");
	sleep (10);

} 
 

void wndw_flush (display_id,widget_id)

Display *display_id;
Widget widget_id;

{

char event_not_wip_expose;
Window *wipwindow;
XEvent event;

	XFlush (display_id);
	wipwindow = XtWindow (widget_id);
	event_not_wip_expose = XtPeekEvent (&event);
	while (event_not_wip_expose) {

	XtNextEvent (&event) ; 
	XtDispatchEvent (&event);
	if (event.xexpose.type == Expose &&
	    event.xexpose.window == wipwindow &&
	    event.xexpose.count == 0) {
	    event_not_wip_expose = FALSE ;                                
	} else {
		event_not_wip_expose = XtPeekEvent (&event);
	}
    }      
}         
                      
T.RTitleUserPersonal
Name
DateLines
2293.1Using ASTs?HELENA::ORGOVANVince OrgovanFri Feb 16 1990 17:162
    I think it's possible to get that error if you accidently call
    into Dwtlib at user AST level. Any chance that's the problem?
2293.2See 2224.1LEOVAX::TREGGIARISat Feb 17 1990 07:583
    Also see 2224.1.
    
    Leo
2293.3AST's were the problem ,but now.... SHARIF::BULLARDCharlie's retiired 9-NOV-1989 !!Thu Mar 01 1990 10:3547
Thanks for the replies the customer was using the routine from an AST
which explains the problem.As I understand it it is only possible
to use XLib at the AST level.So I set about modifying the routine 
to only use XLib.


void wndw_flush (display_id,widget_id)

Display *display_id;
Widget widget_id;

{	    
 


char event_not_wip_expose;
Window *wipwindow;
XEvent event;

	XFlush (display_id);     
	wipwindow = XtWindow (widget_id);
       	event_not_wip_expose = XPeekEvent (display_id,&event);
       	while (event_not_wip_expose) {

	XNextEvent (display_id,&event) ; 
	XSendEvent (display_id,wipwindow,FALSE,FALSE,&event);
       	if (event.xexpose.type == Expose &&
	    event.xexpose.window == wipwindow &&
	    event.xexpose.count == 0) {

	    event_not_wip_expose = FALSE ;
                                 
	} else {
		event_not_wip_expose = XPeekEvent (display_id,&event);
       }        
       
    }   XFlush (display_id);         
}         
 
This use of XSendEvent has been documented before which is where I got
the information from.However now the expose event to put text into
my Work In Progress Box does not appear until I return to XtMainLoop,
despite several XFlushes .

Any ideas 

regards Mark
2293.4This may just be plain impossibleFEGPX::SWEENEYPatrick Sweeney in Hong KongTue Mar 06 1990 06:0634
    "As I understand it it is only possible to use XLib at the AST level."
    
    One possible parse of this sentence is "one can use Xlib at ONLY the AST
    level (and not at non-AST level)"  Clearly, this is incorrect.
    
    Another one is "one can use ONLY Xlib (and not the toolkit) at AST
    level".  Well, I for one don't think Xlib works reliably from the AST
    level either.
    
    Many notes have been written on this topic.  Unfortunately, the
    conference doesn't have a keyword "AST".
    
    Calling Xlib from AST level is not supported in the SPD for DECwindows.
    Which is really the only description for the level of support that you
    should rely on for you customer.
    
    The claim that the current VMS/DECwindows version of Xlib is AST-reentrant
    has been qualified or completely refuted depending on whom you ask.
    
    Pragmatically, you may be able to work around the immediate problem of
    why Xlib doesn't flush when so told, but long-term prospects for
    support and maintenance of such a program frighten me.
    
    It's my guess (and I don't have access to sources) that Xlib sets a
    flag early with the semantics of "Xlib has been called already", and
    when a request arrives that flag is checked and the request is queued
    without any processing. That flag is cleared after the user AST routine
    returns and the non-AST thread of execution continues inside Xlib until
    Xlib returns to the user.  In a toolkit based application, that would
    be observed as XtMainLoop.
    
    Were it true, allowing Xlib to be reentered seems to me quite a feat of
    installing interlocks on lots of data structures.
    to be quite
2293.5DECWIN::JMSYNGEJames M Synge, VMS DevelopmentTue Mar 06 1990 11:5018
    Re: .3
    
    I'm not sure I understand the intent of your wndw_flush routine.  Can
    you please explain your (customer's) goal more clearly.
    
>This use of XSendEvent has been documented before which is where I got
>the information from.

    Can you point me to where this is documented?

>However now the expose event to put text into
>my Work In Progress Box does not appear until I return to XtMainLoop,
>despite several XFlushes .
   
   You don't need to do several XFlushes.  One will be enough.  They
   really do cause a flush to occur.
   
   James
2293.6PSW::WINALSKICareful with that VAX, EugeneWed Mar 07 1990 16:176
RE: .4

Last time I looked, Xlib was *intended* to be AST-reentrant, but was not, due
to a bug or two.

--PSW
2293.7STAR::KLEINSORGEFred Kleinsorge, VMS DevelopmentTue Mar 13 1990 13:4214
    
    Having written a lot of code (for UISX) that depends on Xlib to be
    AST-reentrant, I can tell you that it "mostly" works.  It has varied
    up and down from release to release, but looks reasonably good in
    V5.3-1 and V5.4.  There are some problems that may be impossible to
    get around in V1 servers, and even in the V5.3 server (i.e. late
    event AST's after a connection closure).  The UISX product had to
    drop it's intention of supporting V5.1 and later because of some of
    these problems and support only V5.3 and later.
    
    I know it was meant to be AST reeentrant (I think a very important
    customer kind-of required it).
    
    _Fred