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.

On Tue, 4 Dec 2007 09:10:02 -0500, "Academia" <(E-Mail Removed)>
wrote:

>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".

Could be. Standard practice is to keep all the UI in the primary thread, so
they might be using the terms synonymously in this context.

>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?

I think you can believe your own eyes here.

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

The problem with issues like this is that you have to find someone who (a)
writes multithreaded UI code (not common), (b) uses the
Application.UseWaitCursor property, and (c) reads the newsgroup at the
right time, or (d) has the source code.

In my google search, I found lots of people saying that while this property
does change the cursor to the wait cursor, they can still interact with
forms; indeed, they say they have to resume the message loop for the wait
cursor to appear. This seems rather useless, because if you want to show
some kind of wait cursor while the application is processing input
messages, you should show the "working in background" cursor. On the other
hand, if you don't process messages while showing your wait cursor, you can
just use SetCursor, and you don't need to change the "cursor property" for
every window in the thread, because you aren't processing WM_SETCURSOR
messages, and nobody is going to change the cursor.

--
Doug Harrison
Visual C++ MVP

As for "believing my own eyes" it not what I see that is important but what
I surmise are the rules that are causing it. Insight as you apparently have
would certainly be helpful there.

I too read the internet but hoped I could find someone here with experience
with something I now know to by unusual.

Thanks for the explanation it is very helpful.


"Doug Harrison [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Tue, 4 Dec 2007 09:10:02 -0500, "Academia" <(E-Mail Removed)>
> wrote:
>
>>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".
>
> Could be. Standard practice is to keep all the UI in the primary thread,
> so
> they might be using the terms synonymously in this context.
>
>>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?
>
> I think you can believe your own eyes here.
>
>>Thanks
>>
>>PS Asked this in another NG that usually answers but got no response, so
>>I'm
>>guessing the answer isn't well known.
>
> The problem with issues like this is that you have to find someone who (a)
> writes multithreaded UI code (not common), (b) uses the
> Application.UseWaitCursor property, and (c) reads the newsgroup at the
> right time, or (d) has the source code.
>
> In my google search, I found lots of people saying that while this
> property
> does change the cursor to the wait cursor, they can still interact with
> forms; indeed, they say they have to resume the message loop for the wait
> cursor to appear. This seems rather useless, because if you want to show
> some kind of wait cursor while the application is processing input
> messages, you should show the "working in background" cursor. On the other
> hand, if you don't process messages while showing your wait cursor, you
> can
> just use SetCursor, and you don't need to change the "cursor property" for
> every window in the thread, because you aren't processing WM_SETCURSOR
> messages, and nobody is going to change the cursor.
>
> --
> Doug Harrison
> Visual C++ MVP

By message loop you mean something like this?

while (GetMessage(&msg, NULL, 0, 0))

{

TranslateMessage(&msg);

DispatchMessage(&msg);

}



How many loops are there in a application?

One per thread?

One per application?



Thanks



"Doug Harrison [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Tue, 4 Dec 2007 09:10:02 -0500, "Academia" <(E-Mail Removed)>
> wrote:
>
>>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".
>
> Could be. Standard practice is to keep all the UI in the primary thread,
> so
> they might be using the terms synonymously in this context.
>
>>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?
>
> I think you can believe your own eyes here.
>
>>Thanks
>>
>>PS Asked this in another NG that usually answers but got no response, so
>>I'm
>>guessing the answer isn't well known.
>
> The problem with issues like this is that you have to find someone who (a)
> writes multithreaded UI code (not common), (b) uses the
> Application.UseWaitCursor property, and (c) reads the newsgroup at the
> right time, or (d) has the source code.
>
> In my google search, I found lots of people saying that while this
> property
> does change the cursor to the wait cursor, they can still interact with
> forms; indeed, they say they have to resume the message loop for the wait
> cursor to appear. This seems rather useless, because if you want to show
> some kind of wait cursor while the application is processing input
> messages, you should show the "working in background" cursor. On the other
> hand, if you don't process messages while showing your wait cursor, you
> can
> just use SetCursor, and you don't need to change the "cursor property" for
> every window in the thread, because you aren't processing WM_SETCURSOR
> messages, and nobody is going to change the cursor.
>
> --
> Doug Harrison
> Visual C++ MVP

"Academia" <(E-Mail Removed)> wrote in message
news:un$(E-Mail Removed)...
> By message loop you mean something like this?
>
> while (GetMessage(&msg, NULL, 0, 0))
>
> {
>
> TranslateMessage(&msg);
>
> DispatchMessage(&msg);
>
> }

Yes, that's the Win32 wait loop. In .NET,
System::Windows::Forms::Application::Run is used, it calls those same
functions internally.

>
>
>
> How many loops are there in a application?
>
> One per thread?
>
> One per application?
>


One per thread that creates windows, this could be user interface or it
could be COM/OLE/DDE which all rely on windows.

>
>
> Thanks
>
>
>
> "Doug Harrison [MVP]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On Tue, 4 Dec 2007 09:10:02 -0500, "Academia" <(E-Mail Removed)>
>> wrote:
>>
>>>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".
>>
>> Could be. Standard practice is to keep all the UI in the primary thread,
>> so
>> they might be using the terms synonymously in this context.
>>
>>>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?
>>
>> I think you can believe your own eyes here.
>>
>>>Thanks
>>>
>>>PS Asked this in another NG that usually answers but got no response, so
>>>I'm
>>>guessing the answer isn't well known.
>>
>> The problem with issues like this is that you have to find someone who
>> (a)
>> writes multithreaded UI code (not common), (b) uses the
>> Application.UseWaitCursor property, and (c) reads the newsgroup at the
>> right time, or (d) has the source code.
>>
>> In my google search, I found lots of people saying that while this
>> property
>> does change the cursor to the wait cursor, they can still interact with
>> forms; indeed, they say they have to resume the message loop for the wait
>> cursor to appear. This seems rather useless, because if you want to show
>> some kind of wait cursor while the application is processing input
>> messages, you should show the "working in background" cursor. On the
>> other
>> hand, if you don't process messages while showing your wait cursor, you
>> can
>> just use SetCursor, and you don't need to change the "cursor property"
>> for
>> every window in the thread, because you aren't processing WM_SETCURSOR
>> messages, and nobody is going to change the cursor.
>>
>> --
>> Doug Harrison
>> Visual C++ MVP
>
>

On Thu, 6 Dec 2007 09:47:25 -0500, "Academia" <(E-Mail Removed)>
wrote:

>By message loop you mean something like this?
>
>while (GetMessage(&msg, NULL, 0, 0))
>
>{
>
>TranslateMessage(&msg);
>
>DispatchMessage(&msg);
>
>}

Yes, but in a .NET or MFC program, you rarely write the loop yourself.
Instead, it's provided by the framework, which dispatches messages to your
handler functions; when you return from a handler, the message loop
resumes.

>How many loops are there in a application?
>
>One per thread?
>
>One per application?

Message loops are per-thread, but not every thread has a message loop.
Threads which do are called "UI threads", and threads which don't are
called "worker threads". This is not the greatest nomenclature, though,
because an UI thread doesn't have to display windows or do anything with
the user interface. In a Windows program, the primary thread always has a
message loop, while secondary threads typically don't. Since the primary
thread hosts the UI, and secondary threads typically do non-UI work, that's
probably how the "UI" and "worker" threads got their names.

--
Doug Harrison
Visual C++ MVP

On Wed, 5 Dec 2007 09:38:32 -0500, "Academia" <(E-Mail Removed)>
wrote:

>As for "believing my own eyes" it not what I see that is important but what
>I surmise are the rules that are causing it. Insight as you apparently have
>would certainly be helpful there.

I don't have any insight on this, except what I told you. Let me put
"believe your own eyes" in another way. Sometimes you have to fill in the
blanks in the documentation; every Windows programmer comes to realize
this. The challenges are to avoid fooling yourself, avoid making
unwarranted conclusions, and especially to avoid creating a workaround that
potentially has undesirable side-effects. This case seems pretty simple;
you set a property, and it affected only windows in your main thread. If I
couldn't find clarification on the documentation, I would try to test this
in the simplest program I could devise. If this test program behaves the
same on my machine and perhaps a vanilla installation to a VM or something,
I'd conclude the documentation is incomplete or wrong. Then I might go here
and report the discrepancy between the documentation and the reality I
observed:

http://connect.microsoft.com/feedbac...spx?SiteID=210

Actually, that would be a good place to search first, and reporting
problems there is a good idea, because you will get some sort of response
from MS.

>I too read the internet but hoped I could find someone here with experience
>with something I now know to by unusual.

Unfortunately, questions like this sometimes go unanswered for the reasons
I gave in my last message, which I mentioned because you said you didn't
get an answer in another group.

>Thanks for the explanation it is very helpful.

You're welcome, and sorry I can't give you a more definite answer.

--
Doug Harrison
Visual C++ MVP

thanks, that helps

"Ben Voigt [C++ MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Academia" <(E-Mail Removed)> wrote in message
> news:un$(E-Mail Removed)...
>> By message loop you mean something like this?
>>
>> while (GetMessage(&msg, NULL, 0, 0))
>>
>> {
>>
>> TranslateMessage(&msg);
>>
>> DispatchMessage(&msg);
>>
>> }
>
> Yes, that's the Win32 wait loop. In .NET,
> System::Windows::Forms::Application::Run is used, it calls those same
> functions internally.
>
>>
>>
>>
>> How many loops are there in a application?
>>
>> One per thread?
>>
>> One per application?
>>
>
>
> One per thread that creates windows, this could be user interface or it
> could be COM/OLE/DDE which all rely on windows.
>
>>
>>
>> Thanks
>>
>>
>>
>> "Doug Harrison [MVP]" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> On Tue, 4 Dec 2007 09:10:02 -0500, "Academia"
>>> <(E-Mail Removed)>
>>> wrote:
>>>
>>>>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".
>>>
>>> Could be. Standard practice is to keep all the UI in the primary thread,
>>> so
>>> they might be using the terms synonymously in this context.
>>>
>>>>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?
>>>
>>> I think you can believe your own eyes here.
>>>
>>>>Thanks
>>>>
>>>>PS Asked this in another NG that usually answers but got no response, so
>>>>I'm
>>>>guessing the answer isn't well known.
>>>
>>> The problem with issues like this is that you have to find someone who
>>> (a)
>>> writes multithreaded UI code (not common), (b) uses the
>>> Application.UseWaitCursor property, and (c) reads the newsgroup at the
>>> right time, or (d) has the source code.
>>>
>>> In my google search, I found lots of people saying that while this
>>> property
>>> does change the cursor to the wait cursor, they can still interact with
>>> forms; indeed, they say they have to resume the message loop for the
>>> wait
>>> cursor to appear. This seems rather useless, because if you want to show
>>> some kind of wait cursor while the application is processing input
>>> messages, you should show the "working in background" cursor. On the
>>> other
>>> hand, if you don't process messages while showing your wait cursor, you
>>> can
>>> just use SetCursor, and you don't need to change the "cursor property"
>>> for
>>> every window in the thread, because you aren't processing WM_SETCURSOR
>>> messages, and nobody is going to change the cursor.
>>>
>>> --
>>> Doug Harrison
>>> Visual C++ MVP
>>
>>
>
>

Thanks for the complete explanation

"Doug Harrison [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Thu, 6 Dec 2007 09:47:25 -0500, "Academia" <(E-Mail Removed)>
> wrote:
>
>>By message loop you mean something like this?
>>
>>while (GetMessage(&msg, NULL, 0, 0))
>>
>>{
>>
>>TranslateMessage(&msg);
>>
>>DispatchMessage(&msg);
>>
>>}
>
> Yes, but in a .NET or MFC program, you rarely write the loop yourself.
> Instead, it's provided by the framework, which dispatches messages to your
> handler functions; when you return from a handler, the message loop
> resumes.
>
>>How many loops are there in a application?
>>
>>One per thread?
>>
>>One per application?
>
> Message loops are per-thread, but not every thread has a message loop.
> Threads which do are called "UI threads", and threads which don't are
> called "worker threads". This is not the greatest nomenclature, though,
> because an UI thread doesn't have to display windows or do anything with
> the user interface. In a Windows program, the primary thread always has a
> message loop, while secondary threads typically don't. Since the primary
> thread hosts the UI, and secondary threads typically do non-UI work,
> that's
> probably how the "UI" and "worker" threads got their names.
>
> --
> Doug Harrison
> Visual C++ MVP