Is "unique" a synonym for "crufty"? Actually, its worse than that... in hardware mode, the exec superimposes its own window over the parent window received from the UI.
One difference between WIndows and X is that in X, windows are visible to any process that has access to the window ID, whereas in Windows, only the process creating the window has access to it. This precludes an approach like that used in vanilla OpenDX, where the UI and exec are in separate processes, or even DXLink, where the exec and the user's process are separate. In Windows, if OpenDX is to generate graphics that appears in a UI window, the OpenDX exec has to run inside the UI process. Once that is so, you can hand the HANDLE of the UI window directly to the exec (analogously to the UI passing the X window ID to the exec via a socket in vanilla OpenDX), and the exec can then render into it. I have a version that does this - the OpenDX exec runs as a set of threads in the calling process, communicating via the DXLink API. Since the socket-based implementation of the DXLink interface makes little sense in a single process environment, I replaced the communications layer of DXLink with a shared-memory messaging system. I replaced all the X stuff with equivalent Windows stuff. Its wrapped up as a DLL. On top of that, I built a C++ class wrapper for the DXLink API. Its also a DLL. On top of that I built a set of ActiveX controls that provide access to OpenDX functionality. There are three control types - one managing the interface to OpenDX, one providing an image window, and a third - probably unnecessary - providing a non-visible interface to OpenDX. Each of the latter two types can be instantiated any number of times, and is customized by associating a network implementing a macro with it via a property. The DX manager accumulates calls to the macros for each visible and non-visible control into a single main() macro that is executed by OpenDX. Thus you get any number of customized ActiveX controls for your app with only a single OpenDX exec running. I haven't looked at in in a while. It consists of a very hacked snapshot of the product DX code from a couple years ago. I've always meant to fold it into OpenDX, but haven't gotten the time. I'd like to make it available as an feature of OpenDX, but it'd take a lot of work - it was pretty difficult to do (took me several months originally, and touches a *lot* of code). Anyways, those are my ideas on X independency. Greg David Thompson <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 07/11/2001 12:42:14 PM Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: [email protected] cc: Subject: [opendx-dev] Ideas for X independency Jeff and I have been looking at the DX internals lately due to a project we're considering and was wondering if anyone might have a unique solution. Currently, DX shares a named X-Window between the executive and other processes such as the VPE to perform visual displays. It's quite unique and I can't see a solution for a Windows equivalent. For example, the VPE creates an Image Window (X-Window internally) and then passes this X-Window's name via communication to the executive. The exec can then set procs as well as use this window as its own thus having two applications manipulate the same window. Within Win32, it is possible to share a common window via a handle, but you don't have this same advanced functionality of being able to assign the window's events to two different programs. So if I were to try and design a Windows native version of DX, how might this functionality be handled--remember, this graphic window can also be OpenGL based. We've thought of making the executive an ActiveX control but not totally sold on this idea. Any suggestions welcome. David -- ............................................................................. David L. Thompson Visualization and Imagery Solutions, Inc. mailto:[EMAIL PROTECTED] 5515 Skyway Drive, Missoula, MT 59804 Phone : (406)257-8530
