background threads and keeping the UI painting

[Marina Levit]

I am trying to do some processing on a background thread while keeping the
UI painting. However, this is a generic server side call routine - and it
needs to block until the server side call completes. So the idea is, a
server side call begins, it gets spun off on another thread to keep the UI
painting - but, the code flow cannot return to the caller until the server
side call completes, because the caller expects the data.

The only way I could find to do this, was to open a modal dialog after
spinning off the new thread to do the server call. Then the callback would
close the dialog, causing the UI thread to once again begin processing. The
callback had also set the return data, so everything worked fine.

The only problem was that every time the dialog popped open (which had an
animated image to let the user know work was happening), it would activate,
then it would close and the main form would reactivate. One logical
operation sometimes involved several server side calls - and each would pop
open the dialog and then close, resulting in a lot of flashing as the main
form deactivated then reactivated.

The dialog was the only way I could find to block the main thread, and yet
keep the UI painting, and at the same time prevent the user from clicking
anywhere back on the original form and trying to do something while in the
midst of an operation (because the dialog was modal).

Any suggestions for how to implement this kind of thing? Telling the thread
to sleep or anything of that nature does not keep the UI painting - and I'm
thinking Applicaiton.DoE vents is going to allow the user to click anywhere
and mess with things, which isn't going to work either.

[Patrice]

Re: background threads and keeping the UI painting

Generally you launch a background thread that does the work so that the UI
thread is kept responsive. You disable the approprirate controls so that the
user can't do something that would cause problem '(o r you can test if a
background taks is running)...

--
Patrice

"Marina Levit" <someone@somepl ace.coma écrit dans le message de news:
uvX%23NydiIHA.5 780@TK2MSFTNGP0 6.phx.gbl...

>I am trying to do some processing on a background thread while keeping the
>UI painting. However, this is a generic server side call routine - and it
>needs to block until the server side call completes. So the idea is, a
>server side call begins, it gets spun off on another thread to keep the UI
>painting - but, the code flow cannot return to the caller until the server
>side call completes, because the caller expects the data.
>
The only way I could find to do this, was to open a modal dialog after
spinning off the new thread to do the server call. Then the callback would
close the dialog, causing the UI thread to once again begin processing.
The callback had also set the return data, so everything worked fine.
>
The only problem was that every time the dialog popped open (which had an
animated image to let the user know work was happening), it would
activate, then it would close and the main form would reactivate. One
logical operation sometimes involved several server side calls - and each
would pop open the dialog and then close, resulting in a lot of flashing
as the main form deactivated then reactivated.
>
The dialog was the only way I could find to block the main thread, and yet
keep the UI painting, and at the same time prevent the user from clicking
anywhere back on the original form and trying to do something while in the
midst of an operation (because the dialog was modal).
>
Any suggestions for how to implement this kind of thing? Telling the
thread to sleep or anything of that nature does not keep the UI painting -
and I'm thinking Applicaiton.DoE vents is going to allow the user to click
anywhere and mess with things, which isn't going to work either.
>

[Marina Levit]

Re: background threads and keeping the UI painting

The entire application would have to be disabled as really any user
interaction could invalidate things. If the task happened to be short, it
would also look like a different type of flashing to disable/enable it. I am
fairly certain that those in charge of the look of the app are not going to
go for that, though that is an option.


"Patrice" <http://www.chez.com/scribe/wrote in message
news:%23IBzB5di IHA.4396@TK2MSF TNGP04.phx.gbl. ..

Generally you launch a background thread that does the work so that the UI
thread is kept responsive. You disable the approprirate controls so that
the user can't do something that would cause problem '(o r you can test if
a background taks is running)...
>
--
Patrice
>
"Marina Levit" <someone@somepl ace.coma écrit dans le message de news:
uvX%23NydiIHA.5 780@TK2MSFTNGP0 6.phx.gbl...

>>I am trying to do some processing on a background thread while keeping the
>>UI painting. However, this is a generic server side call routine - and it
>>needs to block until the server side call completes. So the idea is, a
>>server side call begins, it gets spun off on another thread to keep the UI
>>painting - but, the code flow cannot return to the caller until the server
>>side call completes, because the caller expects the data.
>>
>The only way I could find to do this, was to open a modal dialog after
>spinning off the new thread to do the server call. Then the callback
>would close the dialog, causing the UI thread to once again begin
>processing. The callback had also set the return data, so everything
>worked fine.
>>
>The only problem was that every time the dialog popped open (which had an
>animated image to let the user know work was happening), it would
>activate, then it would close and the main form would reactivate. One
>logical operation sometimes involved several server side calls - and each
>would pop open the dialog and then close, resulting in a lot of flashing
>as the main form deactivated then reactivated.
>>
>The dialog was the only way I could find to block the main thread, and
>yet keep the UI painting, and at the same time prevent the user from
>clicking anywhere back on the original form and trying to do something
>while in the midst of an operation (because the dialog was modal).
>>
>Any suggestions for how to implement this kind of thing? Telling the
>thread to sleep or anything of that nature does not keep the UI
>painting - and I'm thinking Applicaiton.DoE vents is going to allow the
>user to click anywhere and mess with things, which isn't going to work
>either.
>>

>
>

[Rich]

Re: background threads and keeping the UI painting

Can't you keep the dialogue open until all the transactions have completed?

Instead of creating a dialogue each time you kick off a thread, open a
dialogue which then handles all the transactions in one go?

--

Rich

http://www.badangling.com

....talking pollocks since 1996

"Marina Levit" <someone@somepl ace.comwrote in message
news:%236cKp8di IHA.5160@TK2MSF TNGP05.phx.gbl. ..

The entire application would have to be disabled as really any user
interaction could invalidate things. If the task happened to be short, it
would also look like a different type of flashing to disable/enable it. I
am fairly certain that those in charge of the look of the app are not
going to go for that, though that is an option.
>
>
"Patrice" <http://www.chez.com/scribe/wrote in message
news:%23IBzB5di IHA.4396@TK2MSF TNGP04.phx.gbl. ..

>Generally you launch a background thread that does the work so that the
>UI thread is kept responsive. You disable the approprirate controls so
>that the user can't do something that would cause problem '(o r you can
>test if a background taks is running)...
>>
>--
>Patrice
>>
>"Marina Levit" <someone@somepl ace.coma écrit dans le message de news:
>uvX%23NydiIHA. 5780@TK2MSFTNGP 06.phx.gbl...

>>>I am trying to do some processing on a background thread while keeping
>>>the UI painting. However, this is a generic server side call routine -
>>>and it needs to block until the server side call completes. So the idea
>>>is, a server side call begins, it gets spun off on another thread to keep
>>>the UI painting - but, the code flow cannot return to the caller until
>>>the server side call completes, because the caller expects the data.
>>>
>>The only way I could find to do this, was to open a modal dialog after
>>spinning off the new thread to do the server call. Then the callback
>>would close the dialog, causing the UI thread to once again begin
>>processing. The callback had also set the return data, so everything
>>worked fine.
>>>
>>The only problem was that every time the dialog popped open (which had
>>an animated image to let the user know work was happening), it would
>>activate, then it would close and the main form would reactivate. One
>>logical operation sometimes involved several server side calls - and
>>each would pop open the dialog and then close, resulting in a lot of
>>flashing as the main form deactivated then reactivated.
>>>
>>The dialog was the only way I could find to block the main thread, and
>>yet keep the UI painting, and at the same time prevent the user from
>>clicking anywhere back on the original form and trying to do something
>>while in the midst of an operation (because the dialog was modal).
>>>
>>Any suggestions for how to implement this kind of thing? Telling the
>>thread to sleep or anything of that nature does not keep the UI
>>painting - and I'm thinking Applicaiton.DoE vents is going to allow the
>>user to click anywhere and mess with things, which isn't going to work
>>either.
>>>

>>
>>

>
>

[Marina Levit]

Re: background threads and keeping the UI painting

This is a generic server side calling piece. Thousands of call streams go
through it - in all diff combinations.

So a click handler might have:

run some code dealing with UI object
server call
run some code dealing with UI objects
server call
run some code dealing with UI objects

So, if the dialog is opened up front, and then the click handler as a whole
is run on a separate thread, then anything touching UI objects is going to
die because UI things have to run on the UI thread.

Otherwise, it is just the server calls that are run on a separate thread -
which then brings up the point of how to block while waiting for the async
server call and yet paint the UI.

Yes, I realize multiple server side calls may not be optimal - but sometimes
they are necessary, and it is just not predictable how code was written and
it can't all be redone.


"Rich" <nospam@nowhere .comwrote in message
news:uob3QMeiIH A.5504@TK2MSFTN GP05.phx.gbl...

Can't you keep the dialogue open until all the transactions have
completed?
>
Instead of creating a dialogue each time you kick off a thread, open a
dialogue which then handles all the transactions in one go?
>
--
>
Rich
>

http://www.badangling.com

...talking pollocks since 1996
>
"Marina Levit" <someone@somepl ace.comwrote in message
news:%236cKp8di IHA.5160@TK2MSF TNGP05.phx.gbl. ..

>The entire application would have to be disabled as really any user
>interaction could invalidate things. If the task happened to be short, it
>would also look like a different type of flashing to disable/enable it. I
>am fairly certain that those in charge of the look of the app are not
>going to go for that, though that is an option.
>>
>>
>"Patrice" <http://www.chez.com/scribe/wrote in message
>news:%23IBzB5d iIHA.4396@TK2MS FTNGP04.phx.gbl ...

>>Generally you launch a background thread that does the work so that the
>>UI thread is kept responsive. You disable the approprirate controls so
>>that the user can't do something that would cause problem '(o r you can
>>test if a background taks is running)...
>>>
>>--
>>Patrice
>>>
>>"Marina Levit" <someone@somepl ace.coma écrit dans le message de news:
>>uvX%23NydiIHA .5780@TK2MSFTNG P06.phx.gbl...
>>>>I am trying to do some processing on a background thread while keeping
>>>>the UI painting. However, this is a generic server side call routine -
>>>>and it needs to block until the server side call completes. So the idea
>>>>is, a server side call begins, it gets spun off on another thread to
>>>>keep the UI painting - but, the code flow cannot return to the caller
>>>>until the server side call completes, because the caller expects the
>>>>data.
>>>>
>>>The only way I could find to do this, was to open a modal dialog after
>>>spinning off the new thread to do the server call. Then the callback
>>>would close the dialog, causing the UI thread to once again begin
>>>processing . The callback had also set the return data, so everything
>>>worked fine.
>>>>
>>>The only problem was that every time the dialog popped open (which had
>>>an animated image to let the user know work was happening), it would
>>>activate, then it would close and the main form would reactivate. One
>>>logical operation sometimes involved several server side calls - and
>>>each would pop open the dialog and then close, resulting in a lot of
>>>flashing as the main form deactivated then reactivated.
>>>>
>>>The dialog was the only way I could find to block the main thread, and
>>>yet keep the UI painting, and at the same time prevent the user from
>>>clicking anywhere back on the original form and trying to do something
>>>while in the midst of an operation (because the dialog was modal).
>>>>
>>>Any suggestions for how to implement this kind of thing? Telling the
>>>thread to sleep or anything of that nature does not keep the UI
>>>painting - and I'm thinking Applicaiton.DoE vents is going to allow the
>>>user to click anywhere and mess with things, which isn't going to work
>>>either.
>>>>
>>>
>>>

>>
>>

>