Send commands from one application to another?

[jmoses]

Both applications are running on the same procesor. The command receiver is a LabWindows/CVI GUI. The command protocol must comply with some published standard. How is this done?

[Al_S]

You have multiple options demonstrated in the sample projects that ship with CVI.
Datasocket: if you can think of commands as data.
...\CVI\samples\datasocket\Writer\Writer.prj
...\CVI\samples\datasocket\Reader\Reader.prj
TCP: client/server, easily implimented across a network
...\CVI\samples\tcp\client.prj
...\CVI\samples\tcp\server.prj
ActiveX: interface provided by many applications (including CVI, Microsoft Office, etc).
...\CVI\samples\activex\servers\SimpleEXE\SimpleEXE.prj
...\CVI\samples\activex\servers\SimpleEXE\SimpleEXEClient.prj
EXE/DLL: OK if they're both on the same machine. No defined protocols, just function calls.
...\CVI\samples\dll\simple\cvi\mydll.prj
...\CVI\samples\dll\simple\cvi\simple.prj

Why do you need to create two applications?

[jmoses]

Thank you very much for these great ideas! I would also greatly appreciate a few more details:

Datasocket: Yes, I can think of commands as data, but I am hesitant to go with this option because although the command receiver will be written in LabWindows, I prefer not to require that the command sending application be written in an NI environment. But I'll investigate the sample programs you suggest.

TCP: This is a very attractive option to me because I am familiar with TCP. However, I have never tried to get two programs running on the same machine to communicate with each other using TCP. Is this possible? Would I need two network interface cards with a crossover cable? That would seem clumsy. I would like to choose an architecture that allows the two programs to be running either on the same machine or on different machines.

ActiveX: This is also an attractive option because of the strong ActiveX support offered by NI, although I am unfamiliar with ActiveX programming. Can the server and client be on different machines? Again, I'll investigate the sample programs you suggest.

EXE/DLL: Do you mean that one of the programs could be an EXE and the other could be a DLL? I have used this architecture in the past, but I have never seen a DLL with a GUI. I need to allow both of the two programs to have GUI's.

Why do I need two applications? I want to invite my customer to write software that can send commands to my application, as an alternative to releasing my source code.

My boss suggested using an ODBC database with SQL queries. This is also familiar technology to us. One program can write commands into the database and the other program could read them. But I am concerned about performance here. I would expect the server (command receiver) to respond to commands within at least 200 millisec of when the client sends them. Do you think I have cause for concern here?

Thanks again,

Josh

[Al_S]

Datasocket:
If you want your customer to be able to develope applications around your code, you're right that the disadvantage of Datasocket is that they need some NI software. NI Component Works provides an ActiveX interface to Datasocket, so with Component Works they can develope code in any language that supports ActiveX. But first they have to buy Component Works.

TCP:
On a single machine, you can use the local loopback address of 127.0.0.1. You don't need two NIC's cabled together. Using the local loopback address of 127.0.0.1, the data doesn't even go out to the network. You can 127.0.0.1 without being connected to the network.

ActiveX:
If you create an ActiveX server, you can set the distribution kit to register it as it installs it. Any software that can talk ActiveX (CVI, LabView, Visual C++, Visual BASIC, etc....) can be used to develope an application accessing your ActiveX properties and methods.
ActiveX servers can be remote from the client. (Sometimes called a remote COM object). I don't know the details of creating and registering a remote ActiveX server.

EXE/DLL:
A DLL can have a user interface based on a UIR. You just create and export a function to LoadPanelEx (instead of LoadPanel: see the help for both), DisplayPanel, RunUserInterface, and QuitUserInterface and call that function from your EXE. I name that function InitUIForDLL. If you want both programs (yours and your customers) running independently, you can create a very small EXE that basically just calls InitUIForDLL. Your customer then won't need to call InitUIForDLL but will have access to any other exported function.
The DLL can be remote from the EXE, but it will have to be on a network drive that the customer's application can map to.

[jmoses]

Do you mean I can have 2 applications running at the same time on the same machine, and they can both open a TCP socket to 127.0.0.1, on the same port, and talk to each other this way? That would certainly be the perfect solution for me! Are there any particular port numbers I should or shouldn't use for this, like 23 or 80? I'll work on using Hyperterminal telnet to try this out.

Thanks again,

Josh

[jmoses]

Ah Yes, The CVI tcp examples work great with localhost or 127.0.0.1. We have a winner! I like this solution much better than ActiveX, simply because I am already familiar with TCP but not with ActiveX! Thanks so much for your help.

Yours,

Josh Moses
The Modal Shop

[Al_S]

Good!
But think about your customer too. How complicated will it be to connect to your app via TCP?
ActiveX is pretty popular. One good thing is that any development environment that supports ActiveX can browse the ActiveX objects, properties, and methods. That can be a big help for a developer.

[jmoses]

Sure. I'll consider migrating to ActiveX as my interface increases in complexity and my interested customers increase in number. For now I have only four simple commands and only four interested customers, so I'm content to base my choice on what is easiest for me at the moment.

Thanks again.