Hi Glynn,<br><br><div><span class="gmail_quote">2007/11/15, Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Sorry, I misread the code. If you aren't interested in a specific<br>window, use XCheckTypedEvent() instead. If you need to allow other<br>parts of the code to see the event, you can use XPutBackEvent() to<br>return the event to the queue.
</blockquote><div><br>Yes I stumbled across this function meanwhile. However, using this function results in an active wait condition, because that function does not block. I'd rather not run into 100% CPU load just to process some X events ;-)
<br><br>However, I found that XMaskEvent does exactly what I need in terms of event processing; instead of having to actively wait, it will put the calling thread to sleep until some event matching the given mask arrives in the queue.
<br><br>BUT, to get back on topic: As to the "unexpected async reply" errors. With the risk of ridiculing myself, I "fixed" the problem by simply opening the same display again using XOpenDisplay(NULL) in the event thread. Using the Display pointer returned by that call (which is then specific to that thread), I no more receive these errors.
<br><br>I guess this however is not the way it is intended to use? I mean, I call the same function with the same argument (XOpenDisplay(NULL)) in both threads now, and use the respective Display structure instances only within the boundaries of their "parent" threads. While this does the job, will this have any other side effects?
<br><br>Best regards,<br>Matthias<br></div></div>