[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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.R | Title | User | Personal Name | Date | Lines |
---|
1001.1 | | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Thu Jun 29 1989 16:33 | 4 |
| I answered this in the X conference. (Well, I responded to it, at least!)
Burns
|