Discussion:
Usage of AttachThreadInput
(too old to reply)
SK
2006-12-28 12:36:06 UTC
Permalink
Hello,

What is the signifance of using AttachThreadInput?

We have to display wait cursor in a Secondary UI thread. This UI thread
contains only Message Window. In this UI thread we need to display a Wait
cursor for some long operations. But if we use CWaitCursor in this UI
thread, cursor is not getting changed. Hence we used AttachThreadInput as
follows in secondary UI thread, this solves our problem.

AttachThreadInput(m_nWndThreadID, m_MainThreadID, TRUE);
/*m_nWndThreadID = Current thread ID, m_MainThreadID = Main thread ID*/
CWaitCursor wait;

// Long operation

AttachThreadInput(m_nWndThreadID, m_MainThreadID, FALSE);


Is this is a proper way of using AttachThreadInput? Or is there any other
way to solve this?

Regards
Khot
Joseph M. Newcomer
2006-12-28 15:52:58 UTC
Permalink
As soon as you say "display a wait cursor in a secondary UI thread" you are already in
fairly deep trouble. There is exactly one cursor for the entire system, and there is no
concept of a cursor that is thread-relative. In fact, it makes no sense to even suggest
that this can be done. There is one, and only one, cursor.

Next, the fact that you have a secondary thread with UI components is scary in the
extreme. There is rarely, if ever, a need to create UI components in a secondary thread,
and if you are doing so you should reconsider your design. You are begging for disaster.

Why do you think you need to use UI components in a secondary thread? (Answer: there is
no reason to put UI components in a secondary thread, in almost any scenario imaginable;
if you think you need to do so, there is a 99.999999% chance you are wrong. Rethink the
design). It is a common error among people encountering threading for the first time to
think that it makes sense to put UI components in secondary threads.

Note that any components you use in a secondary thread must not have any relationship
(such as parent-child relationship) with any component in any other thread.

CWaitCursor is also probably the wrong mechanism to use in any case. It simply sets the
wait cursor once, and its scope is the entire application. And what sense does it make to
have a "wait cursor" in a multithreaded environment because, with threads, YOU AREN'T
WAITING! If a wait cursor were necessary, it would mean that you weren't multithreaded.

My first reaction is to this is that you have jumped into multithreading without
understanding the implications of putting visible GUI components in a secondary thread.
This is almost always, without exception, a serious design error. Those of use who have
been threading for a decade or more will go to extreme effort to avoid ever doing this.
Can you explain why you think this is necessary?
joe
Post by SK
Hello,
What is the signifance of using AttachThreadInput?
We have to display wait cursor in a Secondary UI thread. This UI thread
contains only Message Window. In this UI thread we need to display a Wait
cursor for some long operations. But if we use CWaitCursor in this UI
thread, cursor is not getting changed. Hence we used AttachThreadInput as
follows in secondary UI thread, this solves our problem.
AttachThreadInput(m_nWndThreadID, m_MainThreadID, TRUE);
/*m_nWndThreadID = Current thread ID, m_MainThreadID = Main thread ID*/
CWaitCursor wait;
// Long operation
AttachThreadInput(m_nWndThreadID, m_MainThreadID, FALSE);
Is this is a proper way of using AttachThreadInput? Or is there any other
way to solve this?
Regards
Khot
Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Loading...