🚀 go-pugleaf

Sorry I didn't answer your question about what exactly was said. Here is the 
complete text:

My Question was:

Why can't the server just call Trigger() itself?  // NOTE: Trigger is the 
function that the server owns that responds to client requests.

somefunction()
{
    Doing the server thing...
    if( Oh, look! Something important happened!...)
        Trigger();
}

That would accomplish what I am after because the message box would become:

void __fastcall TForm1::OnEvent1(BSTR* Message)
{
    //  ShowMessage("Fired now");
    Do the refresh_info_thing();
}


???? Gary

and the answer came back:

     Servers don't really have that kind of logic.  They pretty much sit 
there and wait for requests from clients.  In other words, servers aren't 
supposed to "push out" services on their own; they're only supposed to wait 
for clients to request services and then fulfill those requests.
     Another way to see it is that servers aren't designed to sit there 
executing code on their own.  They only spring to action when a client tells 
them to.  A COM server isn't any different.


"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:435bc353$1@newsgroups.borland.com...
>
> "Gary D" <gcdesroches@nctc.com> wrote in message 
> news:435bbbf2$1@newsgroups.borland.com...
>
>> If you can make a COM server broadcast without needing a request
>> from a client can you tell me how you did it?
>
> Event sinks.  A client registers a sink with the server, and then the 
> server can trigger events to that sink whenever it wants.  A common way to 
> do that is via Connection Points.  When you create a new COM object in the 
> IDE's ActiveX wizards, you have an option to "Generate Event Support". 
> This option adds an additional IDispatch-derived interface to your Type 
> Library where you can then define your event methods.  The COM object's 
> Impl class will then have a TEvent_... class added to its ancestor list 
> which implements Fire_...() methods for the events.  The server code can 
> call these methods at any time to trigger events in connected clients. 
> The client's code can then derive a class from that interface, or 
> alternatively use the VCL's TEventDispatcher class, to implement the event 
> handling as needed.  In the case of TEventDispatcher, it has a 
> ConnnectServer() method that you can use to hook up the TEventDispatcher 
> to your COM object instance.  If you don't use TEventDispatcher, then you 
> have to manually query the COM object for the IConnectionPointContainer 
> interface, call its FindConnectionPoint() method to get an 
> IConnectionPoint interface, and then finally call its Advise() method 
> passing it an instance of your sink class.
>
> Refer to the following articles for more details:
>
>    Events/Callbacks
>    http://www.techvanguards.com/com/concepts/events.asp
>
>    Implementing an Event Framework
>    http://www.techvanguards.com/com/tutorials/eventsystem.asp
>
> The code examples are in Delphi, but the concepts can be applied to C++ as 
> well.
>
>> Borland support says it can't be done.
>
> What EXACTLY was said?
>
>> ( Remember it's an UNSOLICITED broadcast I'm after, no client
>> involvment other than receiving )
>
> The client has to register its interest in receiving events.  You can do 
> that right after instantiating the COM object.
>
>
> Gambit
>