Doug,
Thanks for your response. I have tried the listening client class with or
without inheriting MarshalByRefObject, but the event still does not seem to
reach the listening client. As I continued to dig, I ran across a clue
which suggests to me the underlying problem. Part of the trick is that the
remoting server component is hosted by a WinForm application, and I really
want a button click on the form to raise the remoted server component
event. I have a "Broadcast" sub which simply raises the remoted event.
The clue : To debug, in the server component class code, I print the
hashcode of the class instance, in the "Broadcast" sub ( me.GetHashCode ).
When a different "event initiator" remote client calls the server
"Broadcast" method, I see one hashcode. When I call the "Broadcast" method
locally from the form that hosts the server component, I see a different
hashcode value. It seems to me that the "Broadcast" method that gets called
via remoting by the "initiator" client is in the "proxy" instance of the
server component, i.e, the same instance that the other "listener" client
references. The "Broadcast" method that gets called by the server's host
app, is not the "proxy" instance of the server component. Within the server
component code, how can I call the proxied instance, and not the local
instance methods?
To see what I'm talking about, print Me.GetHashCode from one of the methods
implemented by your remoted server component. Now try to have the server
code call it's own method, to raise an event.
Thanks for pointing out any gaping oversights I may have commited.
Functionally the event works, and the listening client handles it, if the
sub which raises the event is called thru a remoting proxy. How can I get
the server to initiate this sub to raise the event? Thanks.
[quoted text, click to view] "Doug Forster" <doug_ZAPTHIS_AT_TONIQ_ZAPTHIS_co.nz> wrote in message
news:O6BVNBw$DHA.624@TK2MSFTNGP11.phx.gbl...
> Hi,
>
> > Is there any "one-way" restriction on remoting communication?
>
> No there isn't per se, though each channel is one way. We have a similar
> scheme working well though we have a separate listener at the 'client'
end.
> Did you remember to make your listening 'client' a MBR object? Otherwise
it
> might be easier to help if you could post a cutdown version that
reproduces
> the problem?
>
> Cheers
>
> Doug Forster
>
> "RJ" <RJ@postonly.net> wrote in message
> news:38adnY8LOvEuOt3dRVn-sA@august.net...
> > I have been struggling with a remoting implementation, where I want
> > bi-directional communication between one server object and one remoting
> > client. I have a SAO, whose methods are working properly when called
from
> > the remoting client application, which runs on the same computer. I
> > add an event to the interface for the remoted class, to allow the server
> to
> > notify the server object, and provide the 2-way communication.
> > The server code raises the event, but the "listening" client never
> receives
> > it. No exceptions thrown. No clues.
> >
> > I found an example which implements this type of event, but requires a
> > second "Event Initiator" client, to simply call a "broadcast" sub on the
> > server object. The server object in turn
> > raises the event, and the first "listener" client receives the event.
> This
> > works with no changes to the "listener" client.
> >
> > I can't get this to work without the second "Event Initiator" client.
Why
> > won't a single "listening" client,
> > which has the proper event handler implemented, receive the event, when
> the
> > server object directly raises the event. No exceptions thrown. No
clues.
> >
> > Example1 - Client2 calls Svr.RaiseIt, which raises Event1, Client1
> receives
> > Event1 successfully
> > Example2 - Svr directly raises Event1, Client1 does not receive Event1
> >
> > Is there any "one-way" restriction on remoting communication? Any ideas
> are
> > much appreciated.
> >
> > RJ
> >
> >
>
>
