get an error. And the error occurs in the very file that it says it can't
find. I shouldn't need a server Interface when sending an event from what
"mtv" <mtv@discussions.microsoft.com> wrote in message
news:54307BB4-5A77-445D-9AFC-4EA2C41AD7DB@microsoft.com...
>I think you got the idea; however, your implementation is not there yet.
>Keep
> in mind we're talking at high-level here, and that's why it's better to
> follow/study the links I sent you.
>
> At the high level, you should have:
> ServerObj inherits from AbtractServerObj.
> ClientObj inherits from AbstractClientObj: AbstractClientObj should have 2
> methods:
> 1/ "Inline" method: MyEventHandler(...) { call ClientHandler(...); }
> 2/ Abstract method: ClientHandler(...) that is overridden by ClientObj.
>
> Have both AbstractServeObj and AbstractClientObj built in 1 dll --> both
> ServerObj and ClientObj can see the interface (that's all you need for a
> proxy).
>
> So, Client application instantiate ClientObj typecasted to
> AbstractClientObj. Client app create remote ServerObj and has its proxy as
> AbstractServerObj. Register event with its clientObject.MyEventHandler().
> So
> now, when server object fires an event, the event is sent to MyEvntHandler
> which in turns calls ClientHandler() that resides on client app's domain.
>
> More details should be looked into the links.
>
> Have fun.
>
>
>
> --
> Your 2 cents are worth $milion$. Thanks.
>
>
> "James Hancock" wrote:
>
>> Ok, so I've pretty much figred out that I needed to do what you said I
>> needed to do :)
>>
>> So I created an archetecture like so:
>>
>> Server > ServerWrapper > ClientWrapper > Client
>>
>> The client instantiates ClientWrapper and passes itself using a interface
>> that is available in the central DLL that holds the Server Wrapper and
>> Client Wrapper.
>>
>> The server instantiates a new Server Wrapper on it's side with the shared
>> DLL.
>> When the server needs to notify the client it raises an event in
>> ServerWrapper which the clientwrapper is subscribed to because it
>> instantiates a ServerWrapper to. It then notifies the Client via the
>> interfaced method call of the event and then the client responds.
>>
>> All would be great, and method calls Client to ClientWrapper to
>> serverWrapper to Server work fine and dandy.
>>
>> However, the event from the server gets killed in the server
>> ServerWrapper
>> because it says it can't find the DLL that hte ServerWrapper and
>> ClientWrapper are in. (i.e. the function is in the dll that it says that
>> it
>> can't find)
>>
>> Do you or anyone else have any ideas on why it is telling me that it
>> can't
>> locate the dll when it's in that dll?
>>
>> ServerWraper and ClientWrapper are marked as serializable and everything.
>>
>> Thanks!
>> James Hancock
>>
>> "mtv" <mtv@discussions.microsoft.com> wrote in message
>> news:2E3CB028-C83F-49F1-8B46-9956F41265E0@microsoft.com...
>> > James,
>> >
>> > Let me first try to re-cap what you're asking. Let me know if it's not
>> > what
>> > you're looking for.
>> >
>> > You want to have your server object fire specific events to a specific
>> > client(s) who subscribe to such events. There are two ways that I know:
>> >
>> > 1/ Client register event callback handler with server. This option
>> > limits
>> > a
>> > fixed number of event types that must be known at design time (i.e.
>> > NewData,
>> > DataRemoved...). With this option:
>> >
>> > Client <--> Common Abstract class (CAC) <--> Server
>> > Client class inherits from CAC
>> > Server class inherits from CAC
>> >
>> > AbstractClient is registered with Server --> Server's event is sent to
>> > AbstractClient handler which will in turns calls Client's method.
>> >
>> > Here are some of the links for more details:
>> >
http://www.codeproject.com/csharp/RemotingAndEvents.asp >> >
http://www.dotnetspider.com/kb/Article565.aspx >> >
>> >
>> > 2/ Server just have to maintain a "table" of clients <--> events and
>> > broadcast messages to only subscribed clients upon an event. This
>> > allows
>> > you
>> > to manage event types and users at any time since event/clients... are
>> > just
>> > data to the application.
>> >
>> > Good luck.
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Your 2 cents are worth $milion$. Thanks.
>> >
>> >
>> > "James Hancock" wrote:
>> >
>> >> This is my first forey into Remoting, so please bare with me...
>> >>
>> >> Every sample I can find uses a Singleton system. As far as I can tell,
>> >> if
>> >> I
>> >> raise an event on the server side at that point, every client that has
>> >> registered will get the message...
>> >>
>> >> What I want to do is have the client register, have the server keep
>> >> track
>> >> of
>> >> the currently registered clients, and based on external events (i.e.
>> >> Database stuff) tell the client to go do something with an event. But
>> >> it
>> >> would be a specific event determined by the registration of the client
>> >> (i.e.
>> >> the status that that client sets) and the information from the
>> >> database.
>> >>
>> >> So I've looked at ClientActivatedObjects because I think this is what
>> >> I
>> >> have
>> >> to do, because that will create a new object on the server for each
>> >> client
>> >> as far as I can tell. I'll have that client periodically renew itself
>> >> with
>> >> the server so that the lifetime can time out nicely.
>> >>
>> >> But the question becomes, how, on the server side in my Windows
>> >> Service
>> >> that
>> >> I've created to monitor the database and dispatch the events, do I get
>> >> at
>> >> my
>> >> collection of client activated objects so that I can go through them
>> >> and
>> >> determine which one I want to send the event to? I assume that once I
>> >> have
>> >> that object, that I'll simply be able to raise the event like normal
>> >> and
>> >> handle an error for timeout if applicable...
>> >>
>> >> So the short question, assuming that I got all of the information
>> >> above