[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

1001.0. "? on ASTs and X event processing" by PEACHS::BURQUEST (Soaking up the cathode rays...) Thu Jun 22 1989 10:18

I posted this note in the X notes conference but there seems to be low activity
there, so I thought I would try this conference.

I have a couple of questions about using ASTs in event processing. I have setup
an AST to fire when a keypress event happens. I have used XSelectAsyncEvent to
setup my AST and I am specifying KeyPress as the event type.  So far, so good.
When my AST routine is fired, I do an XCheckTypedEvent call specifying KeyPress
as the event type. XCheckTypedEvent returns me a null indicating that there is
no event of the type KeyPress. Therefore,

	1. What event processing should or should not be done in the context
	   of an AST? The documentation leads me to believe that the AST will
	   fire *after* the event is on the queue. Is this really happening
	   after the event is in the queue.(NOTE: if I run this in the
	   debugger XCheckTypedEvent never seems to fail if I set a break point)

	2. The documentation says, "If CHECK TYPED EVENT does not find a match,
	   Xlib searches the available events for the connection that have yet
	   to be queued". I have looked that the source listing for 
	   XCheckTypedEvent and I don't see where the events that have yet to
	   be queue are checked. The routine follows these basic steps:

		- Call XPending (this flushes the output buffer but does not
		    wait for all requests to be processed).

		- LockDisplay (this inhibits user ASTs from firing)

		- StopEventAST (this stops xport ASTs from adding to the queue

		- Now scan the event queue for the event type passed by the user

		- If the event is found copy the event to the user buffer,
		  remove the event from the queue, and indicate success.

		- If the event is not found, call _XFlush, and indicate failure.
                   ( I am not sure what _XFlush does, I believe that it is an
		     Xlib internal routine that flushes the output buffer )

		- Re-enable xport event processing (StartEventAST)

		- UnlockDisplay (allow user ASTs again)

		- return success or failure.

	  I don't see where we are checking events yet to be queued. This is
	  the only thing I can think of that might cause XCheckTypedEvent to
	  fail after the AST is fired (again I am not sure when the AST is
	  fired, after the event is recieved by the xport or after it is
	  put in the event queue). It seems we might have some kind of 
	  synchronization problem here.

	  Can anyone shed some light on what might be happening here? I don't 
	  know Xlib internals that well.

Regards,

Brad Burquest

T.RTitleUserPersonal
Name
DateLines
1001.1DECWIN::FISHERBurns Fisher 381-1466, ZKO3-4/W23Thu Jun 29 1989 16:334
I answered this in the X conference.  (Well, I responded to it, at least!)

Burns