Send Command to another Application

perhaps more details about the target application you try to send commands to?

does it expect commands via TCP/IP? If yes, do you know what port it listen to, and also the list of commands (and perhaps parameters) that it is expecting?

or does it expect commands via SendMessage/PostMessage?

or perhaps via COM/CORBA/RMI?



DragonSlayer.

Ok, I would Write a Server and a Client Application, The Client should be able to Send Commands to the Server Application, and both of them are running Local, I could use  a TCP/IP Server/Client (Indy TidTCPServer / TidTCP ) to Send and receive Commands but I'm looking for a Alternative.

COM provides one alternative. The application server can register itself in the running object table, and clients can access the server that way. Event callbacks provide a means for the server to send info back to the clients (without the clients initiating the action). Provides a well-defined means of communication, but is not the lightest weight mechanism available.

Windows messages are another means of passing information back and forth (see WM_COPYDATA). Requires the client to be able to determine what the server's window handle is at runtime. Very light weigh mechanism.

DDE provides another (albeit antiquated) means of establishing a client / server communications channel as well. Simple to program against, lightweight communications.(not as light as messaging).

There are also a few other means of communications, such as mailslots, pipes, memory mapped files (used with events/mutexes for signalling). Kind of depends on what OS platform you wish to support with some of these, like names pipes begin NT based, etc.

In the end, it will probably boil down to which you are most comfortable with, and what types of requirements you have.

Hope this helps,
Russell

I would recommend you taking a look at Midware http://www.overbyte.be/frame_index.html

You can see how easily it is to create command handlers by looking at the demos given... it is really worth having a look :-)

go with TCP and Indy
that way you're not limited to the same machine or network
your app is immediately portable to another machine over internet
it's abit overhead using on the same machine but it's tolerable .. the tcp loopback isn't that slow :)

for larger apps I write services with RemObjects
it can't get easier than doing it with RemObjects :)
you're also not limited to the transport .. it can be a winmessage channel using WM_COPYDATA, mailslots, tcp, udp, email, direct dll ...
also enables compression, encryption .. ahh .. I should stop :) .. it's well worth the money
but depends on the target project

hello k4hvd77, as has already be mentioned, you can do this alot of different ways, but  it seems from your comments

Send and Receive Some Commands
Client should be able to Send Commands to the Server Application

you seem to only need a very simple way to send and receive "Commands"  I am guessing that could be an Integer or two?

A simple way to go would be to create a Memory Mapped File as the server starts, and this Mem mapped file would just have the servers Form's Handle in it (maybe some other Info, but you don't say), your client could just open this mem Mapped file and read the Server's form handle, and then use the standard   SendMessage( ) to get a couple of integers (wParam, and LParam) commands to the server, and the client will get an integer Responce command fron the server's Message Result, if more data was required to be transfered the already mentioned WM_COPYDATA could be used

if you are interested, I coild show some code

DragonSlayer,
Midware uses TCP/IP!

rllibby,
Could you tell me more about DDE?? Code Examples could be helpfully.

Slick812,
I never worked with maped Files but I think I means that I cannot send the Command Directly to the Application??!!!

Please note, I just want to Send/Receive a String Commands.


k4hvd

Which version of Delphi you using?

Ya, so you do not want to use TCP/IP? Even stuff like DCOM internally uses TCP/IP.

I'm using Delphi 7, and I would not use TCP/IP if we could find another Solution.

k4hvd77

There is no reason you have to use tcp either, should you choose not to.
Win32 offers the following in regards to IPC communication:

Clipboard
COM
Dynamic Data Exchange (DDE)
File Mapping
Mailslots
Pipes
RPC
Windows Sockets
WM_COPYDATA

It should be noted that once you start crossing machine boundaries, then tcpip will be used as the underlying transport mechanism (for those IPC's that support cross-machine).

Re: file mapping ipc, take a look at the {delphi}\demos\ipc sample client and monitor application. Another good alternative should you choose to go that way.


Russell

Like what Russell says... as soon as your client and server are on different machines, you can't escape from TCP/IP.

Russell,
I can not get it work!!


k4hvd77

Er.... perhaps a little more information to go on would be helpful. The code I gave you for dde was compiled, and tested, and rechecked; so I can only assume you are having issues with the client connecting to the server. Is this the case, or are you issues elswhere?

I can help you further if you provide something for me to go on.

Russell

I can compile Client and Server Application too, but if I changing Edit1 and 2 has no effects, so "Client and server are not Connected"!! I have changed the ServiceApplication too!

did you just copy the code ? you also need to set the events of the components :)

I have maked 2 projects saved them, opened the .dfm with Notepad, pasted the Form Code, saved it, opened the unit pasted the source code and compiled it! events are set! could you send the projects using emaill to int@titaniumserver.de


k4hvd77

It works! but could you tell me how to do that Client use the Application path to Find and connect the server?

The dde client side components are a little touchy (I'll explain in a minute) so first, it helps to build the server component first, so it is available.

By touchy I mean that if the Client converation is set to ddeAutomatic, it will attempt to launch the server (even in design mode) and if the server does not launch, it will clear out settings you have for DdeService/DdeTopic, as well as the DdeClientItem's DdeItem property. Its an annoying feature (bug), but one you should be aware of.

Once the server is built and available, the client conversation should have the following properties set:

(from delphi help)

DdeService - Use DdeService to specify the server application to link to. Typically, DdeService is the file name (with path, if necessary) of the DDE server application's main executable file without the .EXE extension. If the DDE server is a Delphi application, DdeService is the project name without the .DPR or .EXE extension. For example, to link to a TDdeServerConv component in PROJ1.DPR, set DdeService to PROJ1.

DdeTopic - Use DdeTopic to indicate the server-defined topic name of the DDE conversation. Typically, DdeTopic is a file name (with path, if necessary) used by the server application. If the DDE server is a Delphi application, by default DdeTopic is the caption of the form containing the linked component. If the DDE client is linked to a TDdeServerConv component, DdeTopic is the name of the server conversation component rather than the form caption.

And finally, there is the ServiceApplication. If the server is not in the "path", then this should be coded with the full path name of the file, minus the .exe extension.

(delphi help) Set ServiceApplication to the name of the server application. Typically, this is the same value as the DdeService property. Sometimes, however, DdeService is a value other than the DDE server application's executable file name. If the server application is not running when the TDdeClientConv tries to establish a DDE conversation, OpenLink uses the ServiceApplication property to launch the server.

----

A normal "real-world" design usage would be similar to the following:
1.) Build server side first
2.) Build client and debug with connect mode set to auto connect, and the path hardcoded into the serviceapplication property
3.) Once testing is complete, switch connect mode to manual, and use the OpenLink method to connect to the server.
4.) Figure out where (like the registry) to store the server location. If the server is already running, then the client can connect to it without this information.
5.) Code the client so it retrieves the server location, sets the serviceapplication property, then calls OpenLink.
6.) Retest to make sure it all works.


Hope this helps,
Russell

Just to follow solution :)