| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2550.1 | ... | GSRC::WEST | Variables don't, Constants aren't | Mon Apr 02 1990 13:05 | 10 |
|
Well, you got the first answer right...do to re-entrancy problems, especially
with the toolkit you really don't want to use tasks, but if you must then I
believe the general concensus is that only ONE task does ALL toolkit work.
As for checking the event que so you would not block, take a look at
XPending or the prefered XEventsQueued calls.
-=> Jim <=-
|
| 2550.2 | XtEvent blocks for IO | SAILN::HA | | Mon Apr 02 1990 15:14 | 15 |
| Ok, they tried putting all toolkit calls and event handling into
one task and this seems to work - but there is still one problem.
They are using XtNextEvent() - but this blocks for IO so one of
their other tasks that does a database retrieval is prevented
from running. If they bump the priority of the task doing
XtNextEvent() down to 6 this allows the database retrieval task
to continue but this task runs at priority 7 and so once this
database task runs no more Xt events are recognized.
Also, the customer WHY is XEventsQueued preferred over XPending?
Is it possible to get a description of how the queues are utilized
(what is put on the queue, what, which, when, and HOW are events
removed)? Is it possible to get the source for the event handling
code?
|
| 2550.3 | Try XtPending/XtProcessEvent | LEOVAX::TREGGIARI | | Tue Apr 03 1990 08:42 | 9 |
| You don't have to use XtNextEvent. If you want more control over what
is happening, use XtPending and XtProcessEvent instead. XtPending
returns a mask of the type(s) of toolkit input that are pending
{X event | timer | alternate input}. XtProcessEvent takes the same
type of mask and processes exactly one event of the type(s) you
request. By simply passing the mask you receive from XtPending back into
XtProcessEvent, you are guaranteed to never block.
Leo
|
| 2550.4 | To flush or not to flush | DECWIN::KLEIN | | Tue Apr 03 1990 13:14 | 7 |
| > Also, the customer WHY is XEventsQueued preferred over XPending?
XEventsQueued is preferred because it does not (necessarily) cause the
output queue to be flushed (XFlush) if there are no more events pending.
XPending always does an extra XFlush (for historical reasons).
-steve-
|
| 2550.5 | Ada example of non-blocking event processing... | GSRC::WEST | Variables don't, Constants aren't | Wed Apr 04 1990 12:16 | 27 |
|
Below is a sample piece of Ada code demonstrating event processing without
blocking.
-=> Jim <=-
================================================================================
forever:
loop
x.events_queued (
result => number_of_events,
display => display,
mode => x.c_queued_after_flush);
if number_of_events > 0 then
x.next_event (
display => display,
event_return => event);
dwt.xt_dispatch_event (event => event);
end if;
end loop forever;
|
| 2550.6 | thanks! | SAILN::HA | | Wed Apr 04 1990 18:47 | 7 |
| Thanks for everyone's speedy help! We've think we've managed
to get something working by using XSendEvent to send ourselves
an event to unwedge ourselves and get things started again.
We'll also try out XProcessEvent to see how it works. The
only strange thing with XSendEvent is that we try and send
a ClientMessage and we never seem to get it - has anyone heard
of this? Possible bug?
|
| 2550.7 | Lots of wrong ways to XSendEvent | DECWIN::KLEIN | | Wed Apr 04 1990 19:17 | 9 |
| > We'll also try out XProcessEvent to see how it works. The
> only strange thing with XSendEvent is that we try and send
> a ClientMessage and we never seem to get it - has anyone heard
> of this? Possible bug?
Post your XSendEvent code. The window field (as well as some of the
other fields) in the event structure must be properly initialized.
-steve-
|
| 2550.8 | I need to condense code | SAILN::HA | | Wed Apr 11 1990 22:57 | 7 |
| Haven't had time to condense down the code - the customer's built
up all these layers over the X calls and it's going to take
a bit of work to untangle it. I'll post it/send you mail when
I have it in a workable state...
Michael
|