Eric, Interesting. I've heard reports of this before.
However, I'm unable to duplicate this problem. I suspect that the problem has something to do with the fact that X events don't come in that often, so we may not process our Windows events in a timely manner. I have been searching forever for a non-blocking equivalent to XNextEvent... and I finally found one! Here is Owen Taylor's response to someone looking for the same thing: http://www.xfree86.org/pipermail/xpert/2001-December/013978.html =========================================================================== > For reasons to do with a user interface element I'm working on, > I need something like select. Do the XCheck*Event() functions > block? I'm really reluctant to use pthreads, as this isn't portable > enough for what I'm trying to do. > > Specifically, if the app is in a certain state, I want to update the > window every 1/32 of a second, but I need to keep processing events too. > If XCheckWindowEvent() doesn't block, and is reasonably quick, it will > do perfectly. Does it? The standard way of doing a non-blocking check is if (XPending (display)) { XNextEvent (display, &event); } Using any of the XCheck*Event functions can be relatively slow, since they need to search the entire queue. (If you had to use one, I'd suggest using XCheckIfEvent with an appropriate predicate. But XPending() should be as good or better.) Of course, what real toolkits do is select() on ConnectionNumber(display) to know when they need to call XPending() without having to poll continuously. =========================================================================== I was very intrigued to see this. This not only means that I can make xwinclip better, but it means that I can finally integrate clipboard support into XWin.exe, since we'll actually be able to see some sort of shutdown message, rather than having XNextEvent fail and call exit (). (Obviously you can't integrate a clipboard client in the server if every time you reset you call exit ()... cause you would exit instead of resetting.) I've done a small rewrite of xwinclip to use select () on both the X event handle and /dev/windows (which is a socket that watches the Windows message queue). This should solve the problem that you are seeing with Outlook because we will process our Windows messages in a timely manner. I'll post the new xwinclip in just a few minutes. It won't be long now until we can get rid of xwinclip and have clipboard integration directly in XWin.exe. Harold