Listening to events published by other apps?

  • Thread starter Thread starter wobbles
  • Start date Start date
W

wobbles

Hi Everybody,

How do I go about listening to events published by other apps?
I know that my events are working internally (ie within my client),
but when I subscribe to an event published by a different client, it
doesn't work.

I feel like I'm missing something. Please point me in the right
direction.

Thanks in advance!
 
Hello Miha,

I was hoping you wouldn't say something like that.
That sounds pretty complicated.

Do you know of any online resources that explain what I should do?
If you could recommend a good book, that would be great too!

Thanks again
 
You might take a look at .net help (very usefull) plus there are really nice
examples in .net sdk folder (
C:\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\Samples\Technologies\Remoting).

For message queues there is .net help topic
Message Queues and Messaging Technology Backgrounder
and others
 
Thanks Miha,

It's back to the books I go.
I don't always find the Microsoft help very easy to understand but
I'll give it a go.

Remoting/message queuing sounds quite complicated. Is it?

Thanks again.
 
Miha, Wobbles,

* Remoted events have a very unpleasant feature - the order in which event
handlers will be called is unpredictable as remoting requests are served on
the thread pool. If the event order is not important, you can probably
ignore that warning. But if it IS important, remoting seems to be useless.

* Message Queues require MSMQ to be installed, don't they?

* I have used Named Pipes for delivering events across process boundaries
and they work just fine. The only caveat is that you should resort to
P/Invoke to create and initalize both ends of the pipe. Then, the FileStream
class constructed from the pipe handle works with the pipe almost as it was
a regular file.
 
* Remoted events have a very unpleasant feature - the order in which event
handlers will be called is unpredictable as remoting requests are served on
the thread pool. If the event order is not important, you can probably
ignore that warning. But if it IS important, remoting seems to be useless.
Yup.

* Message Queues require MSMQ to be installed, don't they - they are free
Click to expand...
though?

Don't forget disconnected feature.
* I have used Named Pipes for delivering events across process boundaries
and they work just fine. The only caveat is that you should resort to
P/Invoke to create and initalize both ends of the pipe. Then, the FileStream
class constructed from the pipe handle works with the pipe almost as it was
a regular file.
Click to expand...

Right. Though you can't use them outside intranet as is the case with MSMQ.
 
Miha, Dimitriy,

Thanks for your input.
I'll have a look at remoting as well as MSMQ and "named pipes".

wobbles
 
Back
Top