Re: Signaling for a running application

On Sun, 13 Apr 2008 23:04:01 -0700, Peter Baranyi <PeterBaranyi@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

:) Yeah, you completly missing the point. The point is that I have two
applications. One written in Deplhi, the other in c#. If I click on a menu in
the Deplhi application, I want to do something in the c# applicaiton. And I
have no idea how to do this kind of "link" between the two.

For what it's worth, in your original post, among other things the apparent use of Delphi jargon was a definite impediment to understanding what it is exactly you're trying to do. If you only want people versed in Delphi to answer your question, I guess that's fine. But Peter R.'s lack of comprehension was understandable. For a broader audience, you might try to use more general-purpose terminology, using jargon only where necessary and even then only jargon that's defined for the context in which you're conversing (e.g. in a .NET newsgroup, use only jargon from the .NET world).

Anyway, that's a long way of saying, yeah...you probably could've asked the original question better.

Now, that said...what you're asking about is "inter-process communications", or IPC. Within .NET itself, there are a number of pre-defined technologies. However, I don't know if any of them are supportable via Delphi. .NET Remoting and WCF are probably the two most commonly mentioned higher-level mechanisms.

A common technique for connecting two disparate applications would be simply to use regular network i/o. Set up a TCP connection between the two, define some simple protocol for sending messages back and forth, and use that.

Another IPC technique that's often used is memory-mapped files. You can create a named memory-mapped file that is backed only by the virtual memory manager rather than an actual file. It's essentially a shared-memory mechanism, and it has the potential to be more efficient than network i/o. However, it's more complicated and AFAIK there's no built-in support in .NET for it (and there may not be in Delphi either, for all I know).

If someone else has some specific ideas as to how you might get WCF working from a Delphi application, I think that'd probably be a good way to go. Otherwise, plain network i/o is actually not bad, and is very general-purpose (so can easily be extended to practically any language/framework you might wind up using in the future).

Pete
.

Relevant Pages

  • Re: Is Borland QA *really* lacking?
    ... web services isn't something that has really ever been well ... > ability to create SOAP clients was only added in a Delphi 6 update. ... The new IW Standard, IW Data, IW Client Side, and IW Control pages provide ... IntraWeb components for developing Web-based applications. ...
    (borland.public.delphi.non-technical)
  • Re: Announcing CodeGear RAD Studio 2007
    ... compelling health applications to be quickly and easily created. ... to continue down this path -- the ability to continue using Crystal Reports ... Delphi, not Delphi.Net. ... applications to students rather than records management to administrators, ...
    (borland.public.delphi.non-technical)
  • Re: Delphi2005 BETA
    ... I take it it's a matter of Borland ... Delphi 2005 - Compact Framework Support? ... find that very few have plans to develop CF applications. ... How can I transition my development teams to .NET (ASP.NET ranks at the ...
    (borland.public.delphi.non-technical)
  • Re: 7.1 update breaks behavior of persistent fields!!
    ... Clearly many folks, ... situation in their applications. ... that was done in Delphi 4 and prior releases. ... persistent field to be larger than the size of the underlying field in the ...
    (borland.public.delphi.non-technical)