After reading your note, rather than Lloyd's followup, it looks like we're missing the point. The real problem is that OpenDX is simply not working right. Whats really going on here is this. When you use the Import Data... button on that little startup menu, the prompter starts, gathers some info, then starts DX in editor mode with a very simple default network. The DX VPE (dxui.exe) runs as a separate process from the initial startup UI run, run via the DXLink interface. The DX VPE, in turn, starts the DX exec (dxexec.exe), which is the workhorse that does the bulk of the data processing, then tries to link to it via a socket. Thats whats not working - the VPE is waiting for the exec to start and do a little handshake, and its not.
Of course, the interesting question really is why not, and thats not easy to figure out. It depends on OpenDX being installed correctly. That includes the values of various environment variables, maybe the registry, and the directory structure of the OpenDX files. Unfortunately, this is being set up for you by the binary you downloaded, which may in fact not be correct. Typically these binaries are created by helpful participants and made available, but without adequate testing or sufficient generality to cover all the cases that can be found on end-user's machines. Windows is certainly the most difficult platform to get this right on, and people have had lots of problems. Good news is that I have a binary version here that I've put on a bunch of machines around our lab in various states of Windows versions and software installs. It installs with InstallShield just like a "real" Windows app. It has netcdf, cdf, hdf, ImageMagick and JavaDX support. Bad news is that, for sound legal reasons, I can't distribute it outside of IBM. Of course, I can share all the little bits of magic I had to figure out along the way, so I was wondering - anyone out there want to team up to create a new possibly definitive Windows binary? Greg
