Hi Matt, You can set variables in a running copy of DX using DXLink, but you are correct that you send them as text. There are helper routines in one of the libraries that let you write a loadable module and external program which talk with each other over sockets. These routines are commented out in the Windows build, by the way, with a big #ifndef WIN32. You would want to combine the two in order to have full control over DX. Send data on the socket; change parameters through the script.
If you want to use shared memory, you have to write it yourself as a loadable module in DX. On Windows, you have to roll your own anyway. Writing a module isn't so bad, though. MPI is also available, as I think about it, and implementations of MPI sometimes use shared memory on local machines. I haven't looked into using MPI with DX and suspect it is implemented mostly for parallel execution of modules, not for receiving data from remote processes. If you don't have a running copy of DX, then you can still use library methods to decode arrays and such, but you can't load a DX net. Without a DX net, what good is doing visualization in DX? I think this technique is best for translators to/from DX. For instance, if your program wanted to create a DX Object and then send it to DX, it could use the library to make the relevant Arrays and Objects, then use _dxfExportBin_buffer to turn this object into a byte stream, send the byte stream to DX, and then have a DX module decode it with _dxfImportBin_buffer. More likely, you'll write a DX module that receives data in your preferred format and then creates the Object on the fly. When you control DX from an external program, the simplest way is to allow DX to show its own Image window. If you want the display in your own program, then see the Tk example in the distribution. Every time you try to rotate the image, you have to request that DX rotate the image and return the result. If you want to test whether this will work well enough for you, you could expand the Tk example to allow rotations. You may want to do this to prove to yourself that DX can fulfill your technical requirements. I probably have some of this wrong b/c I know better the things I did than everything doable in DX. People have wrenched this program into all sorts of amazing capabilities over the years. While the data model of DX is great and it is a very expressive visual language, it is not good at being embedded in other programs because it runs as a separate process, doesn't have structured error modes to the controlling process, and the executive sometimes dies. All this is probably okay for an academic tool, but, again, it depends on your requirements. Drew Dolgert Cornell Theory Center
