Conference bulova::decw_jan-89_to_nov-90

Re: .0

What DECterm does is to set an event flag and process AST events synchronously.
It calls XtAppAddInput to tell the toolkit about the event flag; then in its
main loop XtAppProcessEvent waits for either an X event or one of the event
flags DECterm cares about.

				-- Bob

    Here's the code TPU uses to send and event to ourselves from withing an
    AST routine.  We aren't sending data in the event but I don't see why
    that would matter.  Perhaps you need the event mask we are using. 
    Perhaps the x$flush is necessary.  
    
                                August G. Reinig
    
        BEGIN
    
        BIND
        scrinfo = .ctx_[com_ctx_scrinfo] : $sinfo,
        env = .scrinfo [sinfo_a_environment] : $env;
    
        LOCAL
        event : x$clie_message_event;
    
        !
        ! Send ourselves a dummy event in case we are blocking for input.
        !
        event [x$l_clnt_type] = x$c_client_message;
        event [x$a_clnt_display] = .env [decw_a_display];
        event [x$l_clnt_window] = .env [decw_a_main_window];
        event [x$l_clnt_message_type] = x$c_none;
        event [x$l_clnt_format] = 32;
    
        !
        ! Send the event - Note that the event mask is bogus.  This is the
        ! value that the session manager uses, and 0 causes a fatal XLIB error
        !
        x$send_event (env [decw_a_display],     ! Display
              env [decw_a_main_window], ! Window
              %REF (false),         ! Don't Propagate
              %REF (x$c_client_message),    ! Event Mask
              event [$address]);        ! Event
    
        !
        ! Force the send to occur
        !
        x$flush (env [decw_a_display]);
        END;
    

RE: .0

The XSendEvent call should be sending you the ClientMessage event OK.  I think
the problem is in how you are dispatching events.  Your dispatching loop is
probably ignoring client messages.  Could you post it here?

--PSW

Thank you very much for the help: .1 will be generally useful in some
other projects, and .2 was the clue(s) for my present dilemma.  For the
record, what now works is:

	XSelectInput (dpy, menuwin, (KeyPressMask | ClientMessage ));   /* per 1351.2 advice */
  
  and

	DialEvent.xclient.display = dpy;
	DialEvent.xclient.window = menuwin;
	DialEvent.xclient.data.l[0] = dial;
	DialEvent.xclient.data.l[1] = data;
	DialEvent.xclient.message_type = XA_INTEGER;
	DialEvent.xclient.format = 32;

	XSendEvent ( dpy, menuwin, FALSE, ClientMessage , &DialEvent ); /* per 1351.2 advice */
	XFlush(dpy);

One of the confusions is the definition of ClientMessage:

#define ClientMessage		33

which isn't exactly my idea of a mask value.

#define KeyPressMask			(1L<<0)  
#define LeaveWindowMask			(1L<<5)  

A real long look-ahead question I got was - is this going to be supported?  Thanks again,
and I hope all of this in one place helps others do this fairly mundane task.

Randy K.

RE: .4

The lack of XFlush() was the key to your problem.  Xlib was buffering your
request and not sending it immediately to the server for action.  The XFlush()
forces the request to be sent immediately.

ClientMessage is not a mask value.  It is an event type value.  There isn't any
mask for ClientMessage.  You can't mask ClientMessages out--they are always
delivered.

--PSW

I have been dealing with a customer who needed to play 'XtMainLoop"
for a while from within a callback.I sent him some code which did the
job fine. This piece of code follows:


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);
	}
    }      
}      

However this proved to be a problem because the customer was using this
function from an AST and started to get XMultiplexInput errors.I tried 
to rewrite the above just using XLib.But this time the events do not
seem to get delivered . Can anyone see the problem? The new code follows


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) {
        XFlush (display_id);
	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);         
}         


regards Mark 

    I suspect that you might be running into an Xlib AST reentrancy problem
    which is being discussed in another note.  The basic summary is:
    
    	If you do anything which causes a read on the connection within
    	an AST thread, it may temporarily cause the user mode thread to
    	fail to realize that there is data on the event queue.
    
    We are attempting to fix this bug.  It appears to be a day one bug in the
    interaction between Xlib and X transport.
    
    James