From: janzen@lichen.mpr.ca (Martin Janzen)
Subject: Re: Help with Signals: Novice has 2 questions.
Reply-To: janzen@mprgate.mpr.ca
Organization: MPR Teltech Ltd.
Date: Fri, 24 Jul 92 20:56:18 GMT

In article <cluther.711999464@morticia>, cluther@morticia.cnns.unt.edu (Clay Luther) writes:
>I have two questions regarding a complicated problem. I need to be able to
>perform interprocess communication from one X program to another. The first
>X program I will be writing myself, but the second one, though I can add
>code to it, does not provide access to any of the underlying X widgets...
>[...]
>For the interprocess communication, I believe that signals cannot be used due
>to basic incompatibility with either X or the manner in which the second
>program's architecture was built.
>In a previous posting to comp.x.windows.motif, many people mentioned using
>XtAppAddInput as a solution for the interprocess communication.

Signals can be used if you're *really* careful, but it gets tricky.  Using
XtAppAddInput is much better.

>Here are the questions:
>
>    1) XtAddAppInput expects me to pass an application context as the
>       first argument. Since I have no X information passed to me
>       explicitly, I am unable to use this function, unless I can
>       somehow determine what the 'current' application context is...
>       actually, even just one of the widgets would do, I believe.
>       Is there a way for me to get the app_context with a call to
>       X or Xt (or Xm)?

I ran into a similar situation with Ingres Windows/4GL.  I couldn't find any
function in any library which returns the app context (or a widget or a
Display *) without *some* kind of starting point.  I ended up using the
following gross hack:

    XtAppContext get_app_context(void)
    {
        extern Display *_XHeadOfDisplayList;
        return XtDisplayToApplicationContext(_XHeadOfDisplayList);
    }

Yes, it begins with an underscore; it may not work in future versions; it
probably won't work if you have multiple displays; it may not work at all
on your system; you may not use my name in connection with it; if you do, I
will deny everything; etc. etc.  But it did work for me...

If you must do this, I strongly suggest that you isolate it in a function like
the one above, so that you can replace it in the future if a more civilized
alternative becomes available!

>    2) An obsolete call exists: XtAddInput, which requires no application
>       context. I tried using XtAddInput to implement the communication,
>       but the target routine was never called. Why is XtAddInput obsolete?

Because X11R4 allows applications to create multiple application contexts.
The value of these has been discussed here in the past, but they can be useful
on some architectures (don't ask me to name one!), and for programs which
open multiple display connections.  See Section 14.10 in O'Reilly Volume 4
(the Motif edition) for more details, if you care.

>       Why didn't it work?

Because XtAddInput(), XtAddTimeOut(), and the other non-XtApp* functions use a
*default* application context, which is different than the one created (behind
your back) by your second program.  So the file descriptor that you pass to
XtAddInput() is added to the read mask in the default app context, but the
actual select() is done using the read mask from the application's app context
(which it passed to XtAppMainLoop() initially).

>                             (I *am* issuing this XtAddInput call from
>       within the Main Loop, I believe. I *can* register a new input from
>       within the main loop, can't I?)

Yes, you can.


I probably shouldn't sign this, but...

-- 
Martin Janzen                     janzen@mprgate.mpr.ca (134.87.131.13)
MPR Teltech Ltd.                  Phone: (604) 293-5309
8999 Nelson Way                   Fax: (604) 293-6100
Burnaby, BC, CANADA  V5A 4B5
Newsgroups: comp.windows.x.intrinsics