Your question happens to be one that is somewhat similar to mine.
My OSim (Distributed simulation) application requires an XtAppContext ..the
one placed in
the XtAppInitialize for XWindows applications. However XForms
creates this within fl_initialize().
How do I get the XtAppContext that XForms "uses internally" so I can pass
it
to the OSim application?
Any Help would be appreciated.....
Vince Golubic
-----Original Message-----
From: Steve Lamont <spl@szechuan.ucsd.edu>
To: xforms@bob.usuf2.usuhs.mil <xforms@bob.usuf2.usuhs.mil>
Date: Thursday, April 02, 1998 11:29 AM
Subject: Re: XForms: Xforms as a plugin
># To subscribers of the xforms list from spl@szechuan.ucsd.edu (Steve
Lamont) :
>
>> > Are you actually handling the events in the 3D app? Is the app
>> > "eating" the events? Are you using XPutBackEvent() to stuff the event
>> > back in the queue?
>> The 3D app API allows me to install a callback/handler which is
>> executed before any of the 3D apps.' Xevent processing. I believe the
>> function is analogous to the xforms fl_set_event_callback(). The 3D
>> app. ends up "eating" the events in the end.
>
>Does the handler actually get handed the event or just some
>notification that an event has occurred? If the former, you probably
>need to stuff the event back on the queue with XPutBackEvent().
>
>> > Does your app make a separate display connection? How is it actually
>> > processing the events? With XNextEvent()?
>> My plugin doesn't create a new display connection (unless
>> fl_initialize() or xforms in general does this).
>
>Yes, fl_initialize() does create a display connection.
>
>> > Does the app separately process its own events? If so, how does it
>> > discriminate between the events that it "owns" and those that XForms
>> > "owns?"
>> The handler callback that I install must return 1 if the event is to
>> be handled by the 3D app. Otherwise, it must return 0 indicating the
>> event was handled.
>
>And what do you tell it?
>
>> My thinking was that when I call fl_initialize() or fl_show_form()
>> later, I'm not able to say that the new window should be a child of the
>> 3D app. Does the new window get parented to root?
>
>When a new top level Window is created it is parented to the root
>Window and then immediately reparented to the window manager, which
>slaps its decoration around it (title bar, borders, and whatever other
>gingerbread it wants).
>
>I suppose you *could* try reparenting the XForms window to your
>application -- I'm not sure what would happen. You might need to find
>the parent of the XForms window (which you could do with the
>XQueryTree() function) and reparent *that* to the 3D app.
>
>However, I'm not sure that any of this would work -- I've never tried
>doing something like this. Even if it did, I'd be nervous about its
>stability.
>
>Are there any other callbacks from the app's API that might be better
>suited to doing something like this?
>
>If there's something akin to an XForms idle callback what you may want
>to do is to spawn a new process which creates your XForms GUI and then
>use that idle callback to process commands passed to it via a pipe or
>some other mechanism from the XForms window. If there's a callback
>analogous to the XForms IO callback for processing asynchronous IO,
>then you could use that and avoid having to poll the pipe
>continuously.
>
>If the only thing you have is the API's fl_set_event_callback()
>analog, then another possible method might be to use the XSendEvent()
>mechanism to communicate between the GUI, the app and vice versa.
>Again, spawn your XForms GUI with a fork() and exec(), then using
>XSendEvent() and maybe some of the interclient communications
>functions should allow you to happily communicate without having to
>worry about whose event belongs to whom.
>
>I don't know how interested the rest of the group is in this -- if you
>want to carry on this dialog directly, I'll be happy to take it to
>private email.
>
> spl
>_________________________________________________
>To unsubscribe, send the message "unsubscribe" to
>xforms-request@bob.usuf2.usuhs.mil or see
>http://bob.usuf2.usuhs.mil/mailserv/xforms.html
>XForms Home Page: http://bragg.phys.uwm.edu/xforms
>List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/