Button click - form update?

[Justin Rich]

So another simple question from me :)

as im working away ive made a button that does a series of wonderful
things.. and as it goes along it suppose to update a label to let the user
know what stage its at... but.. the rendering isnt done until after the code
is completed... how do i tell it to render so that the label gets updated?

Thanks
Justin

[Peter Duniho]

Re: Button click - form update?

Nicholas Paldino [.NET/C# MVP] wrote:

Justin,
>
The short answer, call the static DoEvents method on the Application
class in the System.Windows. Forms namespace.

IMHO, DoEvents() is the last option anyone should choose for addressing
this sort of thing, and as such it's definitely not what ought to be
proposed as the first answer, even if it happens to be short.

It's simple to implement, but BackgroundWorke r and similar solutions
aren't actually all that hard, and are much more appropriate ways of
dealing with the issue. It's such a basic issue in .NET (and Windows
programming more generally), to know how to move lengthy processing out
of the main UI thread, that once a person runs into it they should just
go ahead and learn how to do it right.

Pete

[Ignacio Machin \( .NET/ C# MVP \)]

Re: Button click - form update?

Hi,

"Justin Rich" <jrich523@yahoo .spam.comwrote in message
news:e2$%23SJJ9 HHA.4584@TK2MSF TNGP03.phx.gbl. ..

So another simple question from me :)
>
as im working away ive made a button that does a series of wonderful
things.. and as it goes along it suppose to update a label to let the user
know what stage its at... but.. the rendering isnt done until after the
code is completed... how do i tell it to render so that the label gets
updated?

What if you do your processing (that seems to be a time consuming opertion)
in a separate thread?

Then you can use Control.Invoke to update the UI

[Peter Duniho]

Re: Button click - form update?

Doug Semler wrote:

Subtle? Call DoEvents in Windows message event handler that updates a
second control right before the DoEvents() call. That second control
has an event handler that updates a the first control right before a
DoEvents() call. Convince original programmer to do work in
background thread. All well. Except original programmer now accesses
the form controls from background thread. Cannot convince original
programmer that this is not good.

Nicholas did specifically say for the access from the background thread
to be done via a call to Invoke(), which is a correct and perfectly
acceptable way to interact with form controls from a background thread.

Why would you want to convince anyone that "this is not good"?

I agree (obviously) that DoEvents() is not the right solution, but I
don't really understand the rest of your reply. One one decides not to
use DoEvents(), that necessarily implies moving the code to another
thread, and if the code exists in another thread it will necessarily
have to somehow interact with the form controls from that thread if
those controls are to be updated with respect to the work in the thread.

Doing that isn't a problem at all, as long as it's done correctly.

Pete

[Justin Rich]

Re: Button click - form update?

sounds good to me.. where do i learn?


"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:13edjabjrd pcfc0@corp.supe rnews.com...

Nicholas Paldino [.NET/C# MVP] wrote:

>Justin,
>>
> The short answer, call the static DoEvents method on the Application
>class in the System.Windows. Forms namespace.

>
IMHO, DoEvents() is the last option anyone should choose for addressing
this sort of thing, and as such it's definitely not what ought to be
proposed as the first answer, even if it happens to be short.
>
It's simple to implement, but BackgroundWorke r and similar solutions
aren't actually all that hard, and are much more appropriate ways of
dealing with the issue. It's such a basic issue in .NET (and Windows
programming more generally), to know how to move lengthy processing out of
the main UI thread, that once a person runs into it they should just go
ahead and learn how to do it right.
>
Pete

[Nicholas Paldino [.NET/C# MVP]]

Re: Button click - form update?

I agree, I would never use DoEvents, but some people just want the quick
and dirty solution.


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard. caspershouse.co m

"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:13edjabjrd pcfc0@corp.supe rnews.com...

Nicholas Paldino [.NET/C# MVP] wrote:

>Justin,
>>
> The short answer, call the static DoEvents method on the Application
>class in the System.Windows. Forms namespace.

>
IMHO, DoEvents() is the last option anyone should choose for addressing
this sort of thing, and as such it's definitely not what ought to be
proposed as the first answer, even if it happens to be short.
>
It's simple to implement, but BackgroundWorke r and similar solutions
aren't actually all that hard, and are much more appropriate ways of
dealing with the issue. It's such a basic issue in .NET (and Windows
programming more generally), to know how to move lengthy processing out of
the main UI thread, that once a person runs into it they should just go
ahead and learn how to do it right.
>
Pete

[Doug Semler]

Re: Button click - form update?

On Sep 11, 1:48 pm, Peter Duniho <NpOeStPe...@Nn OwSlPiAnMk.comw rote:

Doug Semler wrote:

Subtle? Call DoEvents in Windows message event handler that updates a
second control right before the DoEvents() call. That second control
has an event handler that updates a the first control right before a
DoEvents() call. Convince original programmer to do work in
background thread. All well. Except original programmer now accesses
the form controls from background thread. Cannot convince original
programmer that this is not good.

>
Nicholas did specifically say for the access from the background thread
to be done via a call to Invoke(), which is a correct and perfectly
acceptable way to interact with form controls from a background thread.
>
Why would you want to convince anyone that "this is not good"?
>
I agree (obviously) that DoEvents() is not the right solution, but I
don't really understand the rest of your reply. One one decides not to
use DoEvents(), that necessarily implies moving the code to another
thread, and if the code exists in another thread it will necessarily
have to somehow interact with the form controls from that thread if
those controls are to be updated with respect to the work in the thread.
>
Doing that isn't a problem at all, as long as it's done correctly.
>
Pete

Missed a word: Accesses controls directly...With out Invoke().....an d
because it has worked without Invoke() in the past it is difficult to
convince that it is wrong.

[Peter Duniho]

Re: Button click - form update?

Doug Semler wrote:

Missed a word: Accesses controls directly...With out Invoke().....an d
because it has worked without Invoke() in the past it is difficult to
convince that it is wrong.

Ah. Yes, that's a significant difference in meaning. :) And yes, I
agree it can sometimes be hard to convince someone that just because it
worked without using Invoke() before, that doesn't mean failing to use
Invoke() is correct.

Much better to indoctrinate new .NET programmers from the outset. :)

Thanks for clarifying.

Pete

[Peter Duniho]

Re: Button click - form update?

Justin Rich wrote:

Actually where I ran in to the problem is with a webpart that uses a web
service.
[...]
>
probably something i should direct more to the WSS dev newsgroup.. but i
figured there would be some value in knowing this anyways.

A web-specific newsgroup would probably be more useful, yes. I don't
actually know all of the ways that the web components differ from
regular forms. But I know that they do, and for sure the general
updating mechanisms are likely to be quite different, given all of the
overhead involved in dynamically updating a web page (especially from
server-side code) versus doing so in a local-only forms application.

Pete