Unusual Threading Requirement

Hi,

I have done some reading on threading in WPF and have an interesting
probelm.

My WPF app calls a remote webservice syncronously - eg the the UI is locked.
This is a requirement. If the remote service determines the operation it is
performing will be a long one, it responds quickly and the client app should
just open a cancel/progress dialog and call the remote service again to do
whatever its doing. The remote service will periodically respond with a
progress indication. The client must remain locked, EXCEPT for the cancel
button, which should be clickable, and will cancel the operation (when the
service next responds with a progress).

So the solution where the webservice call is invoked on a different thread
is not workable as the main UI will not be locked. I really need the
progress/cancel dialog on a different thread.

Is this feasible under the WPF threading model, and if so, any clues?

Thanks

Radek

I think I found the answer at
http://msdn2.microsoft.com/en-us/library/ms741870.aspx.

"Radek Cerny" <radekcerny@nospam.optusnet.com.au> wrote in message
news:ONNY6hFuHHA.2028@TK2MSFTNGP04.phx.gbl...
> Hi,
>
> I have done some reading on threading in WPF and have an interesting
> probelm.
>
> My WPF app calls a remote webservice syncronously - eg the the UI is
> locked. This is a requirement. If the remote service determines the
> operation it is performing will be a long one, it responds quickly and the
> client app should just open a cancel/progress dialog and call the remote
> service again to do whatever its doing. The remote service will
> periodically respond with a progress indication. The client must remain
> locked, EXCEPT for the cancel button, which should be clickable, and will
> cancel the operation (when the service next responds with a progress).
>
> So the solution where the webservice call is invoked on a different thread
> is not workable as the main UI will not be locked. I really need the
> progress/cancel dialog on a different thread.
>
> Is this feasible under the WPF threading model, and if so, any clues?
>
> Thanks
>
> Radek
>

Hi,

Radek Cerny wrote:
> I think I found the answer at
> http://msdn2.microsoft.com/en-us/library/ms741870.aspx.

Just to be clear anyway: Your Window runs in one UI thread. If you block
that thread, the whole window stops responding. I wonder why this is a
requirement, though. A much better and friendlier approach would be to
simply disable your whole UI except the Cancel button, and then call the
web service asynchronously.

If for some mysterious reason you still want to block your UI thread,
then you can open another window in another thread. Each window may run
in its own UI thread. To do so, simply call the "Window.Show" method in
another thread's ThreadStart delegate. When you call the Thread.Run
method, the window is open and it gets its own dispatcher.

Now, if you make this window chromeless, and with one single Cancel
button, you will reach the desired effect.

Again, I am not sure why you want to block your UI thread. This is
against all good programming practice. Disable your controls is what the
user expects.

HTH,
Laurent

>
> "Radek Cerny" <radekcerny@nospam.optusnet.com.au> wrote in message
> news:ONNY6hFuHHA.2028@TK2MSFTNGP04.phx.gbl...
>> Hi,
>>
>> I have done some reading on threading in WPF and have an interesting
>> probelm.
>>
>> My WPF app calls a remote webservice syncronously - eg the the UI is
>> locked. This is a requirement. If the remote service determines the
>> operation it is performing will be a long one, it responds quickly and the
>> client app should just open a cancel/progress dialog and call the remote
>> service again to do whatever its doing. The remote service will
>> periodically respond with a progress indication. The client must remain
>> locked, EXCEPT for the cancel button, which should be clickable, and will
>> cancel the operation (when the service next responds with a progress).
>>
>> So the solution where the webservice call is invoked on a different thread
>> is not workable as the main UI will not be locked. I really need the
>> progress/cancel dialog on a different thread.
>>
>> Is this feasible under the WPF threading model, and if so, any clues?
>>
>> Thanks
>>
>> Radek
>>
>
>

--
Laurent Bugnion [MVP ASP.NET]
Software engineering, Blog: http://www.galasoft.ch
PhotoAlbum: http://www.galasoft.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

Thanks Laurent,

I have solved this technically, as you described.

The reason is quite valid - the client is a rich/thin client talking to a
remote server full of business objects; the server session is effectively
single-threaded and maintains both persistent and non-persistent
transactional integrity. So when a user changes a field value, or invokes a
method or whatever on the client, that is sent to the server for processing
(all business rules, persistence, formatting etc live on the server). That
event may of course change other values, which are sent in the response and
disbursed at the client. Thats why the UI must be locked - to avoid any
other changes by the user and maintain transactional integrity. As the
server session is statefull and all traffic is just deltas (eg very small),
response times are basically ping time + < 1 ms, so the user experience is
fine. Only when a truly long running operation is invoked is this required.

Radek

"Laurent Bugnion, MVP" <galasoft-lb@bluewin.ch> wrote in message
news:eK5LTtPuHHA.4572@TK2MSFTNGP02.phx.gbl...
> Hi,
>
> Radek Cerny wrote:
>> I think I found the answer at
>> http://msdn2.microsoft.com/en-us/library/ms741870.aspx.
>
> Just to be clear anyway: Your Window runs in one UI thread. If you block
> that thread, the whole window stops responding. I wonder why this is a
> requirement, though. A much better and friendlier approach would be to
> simply disable your whole UI except the Cancel button, and then call the
> web service asynchronously.
>
> If for some mysterious reason you still want to block your UI thread, then
> you can open another window in another thread. Each window may run in its
> own UI thread. To do so, simply call the "Window.Show" method in another
> thread's ThreadStart delegate. When you call the Thread.Run method, the
> window is open and it gets its own dispatcher.
>
> Now, if you make this window chromeless, and with one single Cancel
> button, you will reach the desired effect.
>
> Again, I am not sure why you want to block your UI thread. This is against
> all good programming practice. Disable your controls is what the user
> expects.
>
> HTH,
> Laurent
>
>>
>> "Radek Cerny" <radekcerny@nospam.optusnet.com.au> wrote in message
>> news:ONNY6hFuHHA.2028@TK2MSFTNGP04.phx.gbl...
>>> Hi,
>>>
>>> I have done some reading on threading in WPF and have an interesting
>>> probelm.
>>>
>>> My WPF app calls a remote webservice syncronously - eg the the UI is
>>> locked. This is a requirement. If the remote service determines the
>>> operation it is performing will be a long one, it responds quickly and
>>> the client app should just open a cancel/progress dialog and call the
>>> remote service again to do whatever its doing. The remote service will
>>> periodically respond with a progress indication. The client must remain
>>> locked, EXCEPT for the cancel button, which should be clickable, and
>>> will cancel the operation (when the service next responds with a
>>> progress).
>>>
>>> So the solution where the webservice call is invoked on a different
>>> thread is not workable as the main UI will not be locked. I really need
>>> the progress/cancel dialog on a different thread.
>>>
>>> Is this feasible under the WPF threading model, and if so, any clues?
>>>
>>> Thanks
>>>
>>> Radek
>>>
>>
>>
>
> --
> Laurent Bugnion [MVP ASP.NET]
> Software engineering, Blog: http://www.galasoft.ch
> PhotoAlbum: http://www.galasoft.ch/pictures
> Support children in Calcutta: http://www.calcutta-espoir.ch