John Burkhardt [mailto:[EMAIL PROTECTED]] wrote:
> I found a workaround. It does seem to be because of a call
> on the UI thread. So what I'm doing now is:
>
> public void CallMethodResultCallbackProxy(IAsyncResult ar)
> {
> this.Invoke(new
> AsyncCallback(this.CallMethodResultCallback) new object[] { ar }); }
>
> And this works. But its gross.
>
> So somehow "Invoke" knows how to call the object on the UI
> thread. There has to be a way I can tell the original call
> to the service to do this.
John,
This isn't actually a workaround, it's the right way. ;) Controls can
contain/require thread affine resources. Therefore you must always make sure
that you interact with the control on the thread on which it was created.
They created the ISynchronizeInvoke interface to handle this for you.
Basically by calling Control.Invoke, you're telling it to execute some
function, passed as a delegate, on it's thread. This will happen
synchronusly, blocking your current thread, if you use Invoke. However,
there are also aync Begin/EndInvoke methods at your disposal. The only
Control methods safe for cross thread calls are the ISynchronizeInvoke
interface methods and CreateGraphics.
HTH,
Drew
[ .NET MVP | weblog: http://radio.weblogs.com/0104813/ ]
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
