garys@earth.cchem.berkeley.edu (Gary Shea) (12/26/89)
Hi folks. I have two kinds of widgets in a project i'm working on. One sends, the other receives. They don't know each other's id's, and expect to communicate after some kind of picking operation with the mouse provides them with each other's id's, be it widget or window. Once the id's are available, they'll use XSendEvent to talk to oneanother. I am using a pointer grab and synchronous event handling to get a ButtonDown event which presumably will have the desired window id in it. From the receive widget i activate a pointer grab, then pick the send widget. I get a ButtonDown event ok, but its subwindow field is a window that CONTAINS the send widget, but isn't part of it. I don't even know where this window comes from... is it the wm? My reading of the relevant material suggests that when a ButtonDown event (any Button event, really) is generated, the subwindow/window that are returned are dependent on the Event masks in the window tree the "hit" window was in. So that if the window that's "hit" is really looking for ButtonDown events, then it will be returned as the window arg (or its parent will and it'll be the subwindow?). Using xwininfo (a blessing) i've been able to determine that the top-level window of my widget knows that i want these kinds of events, as does the appShell, so it seems to me i should be getting SOME window somewhere inside my widget, even if it isn't quite the one i want. Can someone please explain why that doesn't seem to be the case? Or, the usual question, what am i missing here? Or, if i'm going about this all wrong and you know a better way, please make my week... Thanks in advance... Gary Shea garys@earth.cchem.berkeley.edu shea@csvax.cs.ukans.edu TIA, Gary Shea
meo@stiatl.UUCP (Miles O'Neal) (12/27/89)
In article <33380@ucbvax.BERKELEY.EDU> garys@earth.cchem.berkeley.edu (Gary Shea) writes: |Hi folks. I have two kinds of widgets in a project i'm |working on. One sends, the other receives. They don't know |each other's id's, and expect to communicate after some kind |of picking operation with the mouse provides them with each other's |id's, be it widget or window. Once the id's are available, |they'll use XSendEvent to talk to oneanother. If you can find some way to use the action procs within each widget, they get provided with the widget's ID as their first argument. Once you have the widget IDs, you of course have the window IDS, as well, if that's what you really want... Are they to work in the same application, or in different aps? -Miles O'Neal {yr fave backbone here}!emory!stiatl!meo