|
Normally in a thread routine you have a while() loop, normally the condition is a 'staytalive' or some such, that is set FALSE when you want the thread to terminate.
==============================
Nothing to say.
|
|
|
|
|
CWinThreads have this built in already... They don't require anything looping be done by the dev.
|
|
|
|
|
Absolutely! I've actually seen people overriding the run method and squeeze in an infinite loop there. When I tell them "that's what it already does, may be what you need is a worker thread?", they'll be like "oh yeah, that makes sense". A lot of people using spawning UI threads don't actually know that they're spawning a, well, UI thread.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
 I use CWinThreads quite a bit... I actually like them, they're easy to use and communicate with...
|
|
|
|
|
By the way, see my note[^] below regarding the UI naming convention.
|
|
|
|
|
Before creating the thread, create an "Event" object, closed, not auto-reset. When the thread is ready to exit, use WaitForSingleObject() to wait for the event to be triggered. When the dialog closes, have use SetEvent() to tell the thread that it is ok for it to exit now.
|
|
|
|
|
CWinThreads don't require this... you can WaitForSingleObject() on the thread handle itself after you've asked the thread to go down with a WM_QUIT message.
|
|
|
|
|
In my opinion, interthread activities should be explicitly stated rather than rely on side effects of other things.
A "permission to exit" signal is one way of formalizing those activities. "Permission to start" is another. The fact that a thread was created doesn't necessarily mean that it can immediately being doing processing. My threads always go through several stages:
1) Initialization at the start address of the thread
2) Signals an "initialization done" event to allow the main thread to create more, knowing that any data structures, other events / objects are created and that the created thread is ready to run
3) Waits for a "permission to start" event. This allows the main thread to delay start of the thread until other threads are created and ensures that subsequent threads have created their objects that may be necessary for interthread communication to work.
4) enters the "run state" where it is now doing its job
5) "permission to exit" is optional and only when you want the "dance of the threads" to end in an orderly fashion.
You want this orderly approach to startup and shutdown to ensure that if you create many threads, some of which need to communicate with each other, those threads do not run into timing problems and access objects that may not be created / initialized yet by other threads.
Also, I have no idea why you downvoted my answer, it was not wrong, just not to your liking.
|
|
|
|
|
Chuck O'Toole wrote: Also, I have no idea why you downvoted my answer, it was not wrong, just not to your liking.
CWinThreads aren't used in this fashion... besides, trace back on your other solutions... I'm sure I've upvoted you numerous times (I know I have). Keep up the responses, I'm sure you'll get plenty more  from me.
|
|
|
|
|
A CWinThread shouldn't do this automatically (in regular operation). Don't forget to override the InitInstance to return a value, not overriding results in the thread thinking it has nothing to do. Another possible cause is the auto-delete feature being triggered somehow, it's controlled via a public variable so you can simply set it to false to make sure that's not causing this behavior.
|
|
|
|
|
From your description it sounds like you have your threads backwards. Your doing the work in a UI thread and trying to spawn another UI thread to keep your UI active.
In fact the UI thread should start a worker thread to do the lengthy operation. Then the UI thread can continue to service the user actions.
If you vote me down, my score will only get lower
|
|
|
|
|
That's how I understood it too. As well, putting a dialog in another CWinThread sounds more like needing a modeless dialog instead of a modal one. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Excellent answer, Roger.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
The UI name is simply a naming convention that MS picked up a long time ago, it doesn't necessarily mean that a CWinThread needs to work with a user interface. Its useful when you need a working thread that's persistent, meaning it doesn't do a job then end.
|
|
|
|
|
If you're implying that "UI thread" is some kind of an inappropriate name, I can't agree with you more. I've used these "UI" threads in several instances where there's no UI. For example, if I needed some kind of a queued event processing mechanism within my program that will process requests in the order they were received, then UI thread would be a quick and reliable way to do it.
BTW, Roger is correct in saying that the OP should rather delegate lengthy tasks to a background worker, and not bother the main thread that processes the dialog UI events.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Exactly! 
Don't know exactly where that name started, but it stuck apparently. Should be more of a "Persistent thread" or something similar.
|
|
|
|
|
If you need to perform a lengthy calculation, spawn a worker thread and let it do that. The UI thread should not be burdened with anything else but responding to the user.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
I briefly talk about this in this article.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Sometimes my application hangs or freezes for few seconds. After sometime it again comes back to normal. Is there any library which can either dump some useful information or detect faulty statements either in debugging or release state?
|
|
|
|
|
|
I read the detail about MiniDumpWriteDump function. I have a query.
Does it make the dump while an exception occurs & application crashes
or
Can it make the dump while an application freezes or hangs but does not raise an exception? Hang might be a deadlock situation or infinite loop etc
|
|
|
|
|
ProcDump[^] is an excellent tool for monitoring an application and generating stack dumps whenever something is wrong.
|
|
|
|
|
Hi Developers,
I am facing some hurdles in modless dialog. Some of this buttons are working properly, but when i clicked a button that button itself gets flicker & the respective will not get called unless and until i'll press "Alt" key. Even all other buttons will not get worked ( close button as well ).
Can anyone tell me what should be the problem?
Thanks.
Amrit Agrawal
Software Developer
|
|
|
|
|
Figure out what are the main difference with 'working' and 'not working' buttons.
Is it a sub-classed button or OWNER DRAW true in styles.
|
|
|
|
|
There is no problem with style of that buttons, because they have simply put from the tool box.
I have commented the lines of code of that function and found the buttons is clicked properly. In that code it jump into other file and call DoModal of another dialog.
Is there any problem with this calling?
Thanks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
