Ken Kolda
8/20/2004 9:01:00 PM
You should use BeginInvoke any time you update the UI from a thread other
than the main UI thread for the form. You can guarantee that any time the
server calls back to the client that the client-side code will be invoked on
a thread which is not the UI thread. The fact that you can, under some
circumstances, successfully update the UI from this thread is luck -- you
shouldn't count on it. So, the moral is, if the form is used in a
multithreaded environment, use InvokeRequired and BeginInvoke.
Also, another thing you may want to consider if your client-side component
is going to be used by apps not under your control: raise your MessageAck()
event in a thread other than the one on which you received the server
callback. That will allow you to return control to the server immediately
even if the application takes a long time to process the event.
Ken
"CheeseToast" <CheeseToast@discussions.microsoft.com> wrote in message
news:5E5191A6-6758-4D1C-8874-56331AB6230E@microsoft.com...
> Hi Ken -
>
> Thanks, I think you are right. On the client side I am doing things a bit
> differently:
>
> Public Sub Ack()
>
> RaiseEvent MessageAck()
>
> End Sub
>
> The client's form handles the event and updates the UI. So, this is
> possibly where the issue is since a call back without updating any UI
> elements works fine. However, here is where I am confused. The following
> client method when called directly from the server also raises an event
and
> updates the UI. And, it works just fine:
>
> Public Sub DisplayMessage(ByVal AMessage As String)
>
> RaiseEvent MessageReceived(AMessage)
>
> End Sub
>
> So what could the difference be? I would think this would fail also. If
I
> am raising an event, do I need to use BeginInvoke inside the form's event
> handler?
>
> Thanks,
>
> Cheese
>
> "Ken Kolda" wrote:
>
> > Usually this kind of behavior is caused by not using BeginInvoke in your
> > client callback (Ack) if/when it attempts to update the client's UI. It
> > sounds like you're using BeginInvoke to update the server's UI within
the
> > DisplayMessage() call, but you don't show what the Ack() method on the
> > client-side object does.
> >
> > Ken
> >
> >
> > "CheeseToast" <CheeseToast@discussions.microsoft.com> wrote in message
> > news:369A877C-D15F-442F-B837-47AA1A945EAB@microsoft.com...
> > > I have a client that passes a reference to itself to a server. If a
call
> > > from the client to the server results in a server call back to the
client,
> > > the client hangs. Pseudocode:
> > >
> > > (Client)
> > > ServerObect.Connect(Me) <- Client passes a reference to itself, which
the
> > > server maintains.
> > >
> > > (Client)
> > > ServerObject.DisplayMessage("You are an idiot")
> > >
> > > (Server)
> > > Public Sub DisplayMessage(ByVal AMessage As String)
> > > 'UI is updated with the message, this works fine using a delegate
and
> > > BeginInvoke
> > > ClientObject.Ack
> > > End Sub
> > >
> > > Is functionality like this even possible (without using events)? How?
> > >
> > > I know I could use a timer or other kind of message to release context
and
> > > delay the Ack, but this is just a simple example. I'm basically
trying to
> > > figure out how to deal with more complex situations where a call back
> > might
> > > occur. The people using this are non-programmers and I don't want
them to
> > > have to deal with delegates and events.
> > >
> > > Thanks,
> > >
> > > Cheese
> >
> >
> >