InterApp Comm

[BeeJ]

What are some significant pros and cons of different types of interapp
communications? i.e. is there one that is better than the others?
Your opinion needed.

Being considered:
1)Semaphores.
2)Common Memory.
3)Lone Form SendMessage, no hooks.
4)SendMessage with message hook on receiving form.

what others?

From what I have read and tried of those listed above, (3) is best.
(3) Provides:
Can send a coded string. e.g. Command, arguments ...
Causes a change event to fire giving notification.
Able to be synchronous or asynchronous.
Simple interface with no hooks.

[ObiWan]

> What are some significant pros and cons of different types of
> interapp communications? i.e. is there one that is better than the
> others? Your opinion needed.
>
> Being considered:
> 1)Semaphores.
> 2)Common Memory.
> 3)Lone Form SendMessage, no hooks.
> 4)SendMessage with message hook on receiving form.
>
> what others?

well, for example, named pipes and mailslots come to mind then you may
even use barebone sockets and setup your own TCP or UDP channel and
(application) protocol to pass data back and forth; as for the "better
one" there's NO better one; it all depends from what you need to do
and/or to achieve; all in all, not knowing this one may suggest you to
use http://www.macktrucks.com/default.aspx?pageid=9119 while, for your
purpose, you need a http://www.ferrari.com/english/Pages/home.aspx :-D
again, it all depends from your needs and other factors; expand your
question by adding details (the more the better) and you may have some
answers, otherwise... well, do that yourself, we don't have crystal
balls here :D

[BeeJ]

ObiWan used his keyboard to write :

Well, your crystal ball is working just fine. Those are some good
research projects for me. Thanks!

What I need to do is understand these better so I can make a choice
based on the needs for each app that they might apply to.

[BeeJ]

After serious thinking ObiWan wrote :

Where can I test drive one of those trucks?

[Eduardo]

"ObiWan" <obi...@mvps.org> escribió en el mensaje
news:20130406174...@albasani.net...

I would go for the Ferrari

[ObiWan]

> I would go for the Ferrari

hm... even if you need to carry a boeing aircraft :) ?

Again, it all depends from the needs :)

[Eduardo]

"ObiWan" <obi...@mvps.org> escribi� en el mensaje
news:20130407155...@albasani.net...

>
>> I would go for the Ferrari
>
> hm... even if you need to carry a boeing aircraft :) ?

I only would carry girls.

[Clive Lumb]

"Eduardo" <m...@mm.com> a �crit dans le message de groupe de discussion :
kjs0fi$7n6$1...@speranza.aioe.org...

You would need to pick them up first :-P

[Deanna Earley]

On 06/04/2013 16:30, BeeJ wrote:
> What are some significant pros and cons of different types of interapp
> communications? i.e. is there one that is better than the others? Your
> opinion needed.

There is no one better than all the others, they're all designed for
different, distinct situations and uses.

> Being considered:
> 1)Semaphores.
Mutexes

Cross process, notification of state/events only, no extra data
Primarily used for lock outs (mutual exclusions) to stop simultaneous
access to shared data/resources.

> 2)Common Memory.

Again, cross process, needs some agreement as to the format, will need
one of the above to synchronise access.
Primarily used for larger chunks or arbitrary data, and allows direct
access.

> 3)Lone Form SendMessage, no hooks.

No hooks? To receive most messages you will at least need to subclass (a
form of hook)
Again, cross process, can be sync or async. but VERY limited amount of
data. Without subclassing, you'll need to hijack the normal messages and
events.

> 4)SendMessage with message hook on receiving form.

A limited amount of data can be passed cross process. The message system
is designed for high throughput of small messages, not for marshalling
large chunks of data.

DDE
Old but still used by the Windows shell.
I've not used it in the last 15 years so couldn't say what its
limitations are.

COM/ActiveX
Can be cross process, normally synchronous without doing special work.
Primarily used for a more structured (object and method calls, strongly
types) means of communicating between systems.
Can also be used across machines.
Also used by the shell and provides a built in discovery and plugin system.

Clipboard
Evil beyond all evil (even more so than me and the other gays)!!! Forget
I even mentioned this!

There are many more which can be found with a bit of research in MSDN.
http://msdn.microsoft.com/en-gb/library/windows/desktop/aa365574(v=vs.85).aspx
http://en.wikipedia.org/wiki/Inter-process_communication

--
Deanna Earley (dee.e...@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the
group.)

[ralph]

On Mon, 08 Apr 2013 09:47:00 +0100, Deanna Earley
<dee.e...@icode.co.uk> wrote:


>> 3)Lone Form SendMessage, no hooks.
>
>No hooks? To receive most messages you will at least need to subclass (a
>form of hook)
>Again, cross process, can be sync or async. but VERY limited amount of
>data. Without subclassing, you'll need to hijack the normal messages and
>events.
>
>> 4)SendMessage with message hook on receiving form.
>
>A limited amount of data can be passed cross process. The message system
>is designed for high throughput of small messages, not for marshalling
>large chunks of data.
>
> DDE
>Old but still used by the Windows shell.
>I've not used it in the last 15 years so couldn't say what its
>limitations are.
>

I'll add a short word for my favorite "hammer" -> DDE.

I kept Deanna's comments on SendMessage, because DDE basically uses
Windows Messaging - merely adding the ability to manage larger amounts
of data and simplify the management of message sending and collection.

First the limitations:
DDE follows the Publisher / Subscriber model. If your needs don't fit
- skip it.

It uses the queue just like a thousand other things out there. The
client has to reserve time or insure it does in fact manage the
events.

VB out of the box, using its inherent DDE support, has a limited
number of Topics it can support and depends on data binding - an
active control and GUI, eg, TextBoxes. You can get around this by
writing your data aware classes or controls.

Advanatages:
Analogous to a newspaper. The publisher cares less who his users are,
or whether they are reading or not. The reader just expects his
newspaper to be there. If not - it is not a tragedy, there isn't any
new data. The client can complain, skip it, try something else, etc.

This reduces most "synchronization" beyond the obvious.

Another advantage is it has been around forever. It is the orginal
mechanism behind VBXs, and unless Microsoft wants to kill about a
million SCADA applications, it is likely to remain. <g>

Simple and quick to setup, configure, modify, and debug/test.

-ralph

[Stuart McCall]

"BeeJ" <nos...@spamnot.com> wrote in message
news:kjpetq$jm4$1...@dont-email.me...

One method I've used in the past is an .ini file in a shared location. Works
well enough for most things and is simple to implement.

[Eduardo]

"BeeJ" <nos...@spamnot.com> escribi� en el mensaje
news:kjpetq$jm4$1...@dont-email.me...

> 3)Lone Form SendMessage, no hooks.

[...]

> From what I have read and tried of those listed above, (3) is best.
> (3) Provides:
> Can send a coded string. e.g. Command, arguments ...
> Causes a change event to fire giving notification.
> Able to be synchronous or asynchronous.
> Simple interface with no hooks.

You can create your own custom message with the API RegisterWindowMessage.
It's just something to ensure that the message is not interfering with other
custom messages (like using WM_USER).

There are also some API's to broadcast messages: SendNotifyMessage,
BroadcastSystemMessage, but I've never used them so I have no experience.

Another way to communicate something between applications that I used is
writing a property to the desktop window and reading it, using the API's
GetDesktopWindow, SetProp, GetProp and RemoveProp. The way to know the value
(a long value) is pulling, so it's only useful if you need a common place to
share something but not being notified of changes. It has the advantage over
using a file that it goes away with every system restart.

[BeeJ]

>
> 3)Lone Form SendMessage, no hooks.
>
> No hooks? To receive most messages you will at least need to subclass (a form
> of hook)
> Again, cross process, can be sync or async. but VERY limited amount of data.
> Without subclassing, you'll need to hijack the normal messages and events.
>

Thank you for your detailed response.

I am currently using this no hooks method. Yes, no hooks or subclass.

I also have a test jig that uses this method and also the hook method.
Both work well but the non-hook method works without worrying about
hooks or subclassing.

I can put and get string messages very easily. Unfortunately I have
not figured out how to use a receiving form that I Set (Set fForm = New
frmForm) so I can use WithEvents to easily fire an Event when data
comes in. I tried it and the data never completes. Back to the
standard form and that works just fine. No biggie, I just use the
_Change event and "call" (instead of an Event) the main or any other
form with the incoming string.

Yes, the data is limited to whatever I put in the string but that can
be quite a bit of data. In my case, I am sending a syntax like this:
Command1 arg1 ... arg2; ... CommandN argN
it is fast and for the current breed of app works quite well.
BTW the command can be synchronous or asynchronous with or without a
response.

The other methods discussed are of great interest so do not think I am
just brushing them off. I need to study them a little for possible
future use. If only there was a []Compare like on shopping sites.
lol.

For more general purpose use I need to figure out how to do a find and
find next for open Windows in all apps. I have that in another piece
of code I wrote several years ago. Just need to remember.
Hmmm ... typing this out make my fingers hurt more but helps my memory
recall stuff. Very interesting.

[Eduardo]

"BeeJ" <spa...@nospam.com> escribi� en el mensaje
news:kjvipd$560$1...@speranza.aioe.org...

> For more general purpose use I need to figure out how to do a find and
> find next for open Windows in all apps. I have that in another piece of
> code I wrote several years ago. Just need to remember.

EnumWindows?

[BeeJ]

Eduardo submitted this idea :
> "BeeJ" <spa...@nospam.com> escribiￜ en el mensaje

> news:kjvipd$560$1...@speranza.aioe.org...
>
>> For more general purpose use I need to figure out how to do a find and find
>> next for open Windows in all apps. I have that in another piece of code I
>> wrote several years ago. Just need to remember.
>
> EnumWindows?

Thanks. I'll search my code for that call.