By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,046 Members | 2,105 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,046 IT Pros & Developers. It's quick & easy.

background threads and keeping the UI painting

P: n/a
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.DoEvents is going to allow the user to click anywhere
and mess with things, which isn't going to work either.
Mar 19 '08 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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" <so*****@someplace.coma écrit dans le message de news:
uv****************@TK2MSFTNGP06.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.DoEvents is going to allow the user to click
anywhere and mess with things, which isn't going to work either.

Mar 19 '08 #2

P: n/a
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:%2****************@TK2MSFTNGP04.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" <so*****@someplace.coma écrit dans le message de news:
uv****************@TK2MSFTNGP06.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.DoEvents is going to allow the
user to click anywhere and mess with things, which isn't going to work
either.


Mar 19 '08 #3

P: n/a
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" <so*****@someplace.comwrote in message
news:%2****************@TK2MSFTNGP05.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:%2****************@TK2MSFTNGP04.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" <so*****@someplace.coma écrit dans le message de news:
uv****************@TK2MSFTNGP06.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.DoEvents is going to allow the
user to click anywhere and mess with things, which isn't going to work
either.


Mar 19 '08 #4

P: n/a
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" <no****@nowhere.comwrote in message
news:uo**************@TK2MSFTNGP05.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" <so*****@someplace.comwrote in message
news:%2****************@TK2MSFTNGP05.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:%2****************@TK2MSFTNGP04.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" <so*****@someplace.coma écrit dans le message de news:
uv****************@TK2MSFTNGP06.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.DoEvents is going to allow the
user to click anywhere and mess with things, which isn't going to work
either.


Mar 19 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.