Does Application.UseWaitCursor affect all threads in an application

  • Thread starter Thread starter Academia
  • Start date Start date
A

Academia

I have a main thread with a form and it starts another thread with a form.

I set Application.UseWaitCursor property to True in the main thread.

Most of the time I see the wait cursor in the main thread only.
(There is one exception.)


I would think the documentation which says:

When this property is set to true, the UseWaitCursor property
of all open forms in the application will be set to true.

implies it should appear in all threads. I wonder if the word
"application" should really be "thread".


It would help getting my code to work OK if I knew how
Application.UseWaitCursor Property behaved for you.
Are all threads in an application affected.? Or only one?



Thanks

PS Asked this in another NG that usually answers but got no response, so I'm
guessing the answer isn't well known.
 
Academia,

The UseWaitCursor ^should^ work with whatever forms are exposed for the
thread that Application is processing messages on. Usually, that means the
whole application, since you usually only have one UI thread.

It's really kind of moot in this case, because my guess is that you are
creating with and interacting with new forms on other threads, which is
incorrect. You should either marshal UI calls to the UI thread, or you
should be running message loops on those other threads (this is very
uncommon, but not impossible, and does have some, if few, practical uses).

My advise would be to marshal the calls to the UI thread correctly, and
perform only the ^work^ on the background thread.
 
Hi,


--
Ignacio Machin
http://www.laceupsolutions.com
Mobile & warehouse Solutions.
Academia said:
I have a main thread with a form and it starts another thread with a form.

Honestly I have never seen this. Usually there is only one UI thread.
Why you need to create several UI threads?
I set Application.UseWaitCursor property to True in the main thread.

Most of the time I see the wait cursor in the main thread only.
(There is one exception.)

As it's in Application I would guess it apply , well to the application.
Again. your escenario is not the most common one (by far) so maybe the code
of the method is not prepared for multiple UI threads.
 
Paldino and Machin, thanks for replying.

Normally I'd reply to each of you but I'll save bandwidth and do it only
once since the replies are identical.

Please excuse the VB. The original question was not language specific. And I
don't believe this is either.

The second thread form only shows a progress bar which get updated via a
sub:

Public Sub BarValue(ByVal value As Integer)

If abortForm.ProgressBar1.InvokeRequired Then

Dim d As New SetIntegerCallback(AddressOf BarValue)

abortForm.ProgressBar1.Invoke(d, New Object() {value})

Else

mFormForAbort.ProgressBar1.Value = value

End If

End Sub


Which gets called from the main thread like this:
AbortThread.ProgressBarValue(numb)



Is there something wrong with this.

The main thread is updating it's form and I wanted to show the progress.



Thanks for helping
 
Paldino and Machin, thanks for replying.

Normally I'd reply to each of you but I'll save bandwidth and do it only
once since the replies are identical.

Please excuse the VB. The original question was not language specific.
And I don't believe this is either.

Well, you _are_ posting in the C# newsgroup after all.

As much as the community here is very flexible with respect to whether a
question is truly C# specific (at least half the questions here really
aren't C# questions), it seems to me that it's not unreasonable to insist
that C# be at least _somehow_ connected to the question. If you're coding
in VB, I'd say that's a really good sign you need your question asked and
answered elsewhere.
The second thread form only shows a progress bar which get updated via a
sub:

[VB snipped]

Is there something wrong with this.

No, that's the "marshaling" that Nicholas is talking about (using
Control.Invoke()).

Pete
 
thanks

Ignacio Machin ( .NET/ C# MVP ) said:
Hi,


--
Ignacio Machin
http://www.laceupsolutions.com
Mobile & warehouse Solutions.


Honestly I have never seen this. Usually there is only one UI thread.
Why you need to create several UI threads?


As it's in Application I would guess it apply , well to the application.
Again. your escenario is not the most common one (by far) so maybe the
code of the method is not prepared for multiple UI threads.
 
I don't know of a group relating to threads.
Thanks for being flexible.


Peter Duniho said:
Paldino and Machin, thanks for replying.

Normally I'd reply to each of you but I'll save bandwidth and do it only
once since the replies are identical.

Please excuse the VB. The original question was not language specific.
And I don't believe this is either.

Well, you _are_ posting in the C# newsgroup after all.

As much as the community here is very flexible with respect to whether a
question is truly C# specific (at least half the questions here really
aren't C# questions), it seems to me that it's not unreasonable to insist
that C# be at least _somehow_ connected to the question. If you're coding
in VB, I'd say that's a really good sign you need your question asked and
answered elsewhere.
The second thread form only shows a progress bar which get updated via a
sub:

[VB snipped]

Is there something wrong with this.

No, that's the "marshaling" that Nicholas is talking about (using
Control.Invoke()).

Pete
 
thanks

Nicholas Paldino said:
Academia,

The UseWaitCursor ^should^ work with whatever forms are exposed for the
thread that Application is processing messages on. Usually, that means
the whole application, since you usually only have one UI thread.

It's really kind of moot in this case, because my guess is that you are
creating with and interacting with new forms on other threads, which is
incorrect. You should either marshal UI calls to the UI thread, or you
should be running message loops on those other threads (this is very
uncommon, but not impossible, and does have some, if few, practical uses).

My advise would be to marshal the calls to the UI thread correctly, and
perform only the ^work^ on the background thread.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Academia said:
I have a main thread with a form and it starts another thread with a form.

I set Application.UseWaitCursor property to True in the main thread.

Most of the time I see the wait cursor in the main thread only.
(There is one exception.)


I would think the documentation which says:

When this property is set to true, the UseWaitCursor property
of all open forms in the application will be set to true.

implies it should appear in all threads. I wonder if the word
"application" should really be "thread".


It would help getting my code to work OK if I knew how
Application.UseWaitCursor Property behaved for you.
Are all threads in an application affected.? Or only one?



Thanks

PS Asked this in another NG that usually answers but got no response, so
I'm
guessing the answer isn't well known.
 
I don't know of a group relating to threads.

I'm speaking more of a group relating to VB. Or a language-agnostic group
like something in the "m.p.d.framework" branch. The threads aspect of
your post isn't the most off-topic part here.
Thanks for being flexible.

I'm not the most flexible person around, but I do try. :)
 
thanks
Peter Duniho said:
I'm speaking more of a group relating to VB. Or a language-agnostic group
like something in the "m.p.d.framework" branch. The threads aspect of
your post isn't the most off-topic part here.


I'm not the most flexible person around, but I do try. :)
 
Back
Top