|
Which part of this planet do you live in? I just want to know who is using this storage device called *floppy*
Nobody can give you wiser advice than yourself. - Cicero
ப்ரம்மா
|
|
|
|
|
It's a storage device? WOW! I always thought it was a place to stash my weed.
"If you can dodge a wrench, you can dodge a ball."
|
|
|
|
|
Ok forget about Floppy, if you know please tell me how will i set ACL on USB and CD.i guess this is not somthing funny.
Thanks
RYK
|
|
|
|
|
|
Thanks Buddy.
let me test all these thing.
|
|
|
|
|
Hi all.
I want to load the previews of multiple JPG files (One Below the other)in a list box.
How I can do so?
Thanks
Sameer Thakur
|
|
|
|
|
I suggest use of CListCtrl
|
|
|
|
|
Hi.
I appreciate your suggestion.
How can I do the same with ListCtrl.
Any simple way for it?
Thanks
Sameer Thakur
|
|
|
|
|
|
Hi all,
I am creating a dialog app that has a button. When the button is pressed, in OnButton function of the dialog's cpp it creates a thread (I am using CreateThread())that runs some task. I will have to wait for the task's completion by watching the thread's termination via WaitForSingleObject(hThread, INFINITE) there. Now, the thread 's execution may take seconds so the WaitForSingleObject() would actually block windows messages and the dialog window "freezes" during the time. I'd love to NOT have the dialog frozen but simply have the button disabled during the thread task's execution. As now I have two ways in mind:
1. Use Timer and places the thread creation process in the Timer's function instead. Disabling and re-enabling button can be directly done in the function.
2. Create a main thread that does the thread creation process. The main thread will disable and enable the button via PostMessage().
I am just wondering what an appropriate approach would be to solve this problem?
Thanks in advance,
Best Regards,
Johnny
|
|
|
|
|
Why not do something simple like:
1. disable button
2. create and start thread
3. when thread completes it posts a message to your dialog where you enable the button
Sort of like your (2), but guarantees the button disabled when thread starts. The dialog can still receive timer messages if you need a watchdog.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
Thanks a lot for the reply, Peter,
This would work partially. But I think this is will not solve the frozen dialog window problem I am having, as long as I use WaitForSingleObject() or WaitForMultipleObjects() (multiple tasks executed at once) in my dialog's cpp. I have to wait until all the thread are terminated to calculate the total execution time. That's why I thought about putting WaitForSingleObject() or WaitForMultipleObjects() in another thread or Timer which creates the (threaded) tasks, without blocking dialog's window messages.
I hope it makes sense.
Thanks again,
Best Regards,
Johnny
|
|
|
|
|
J.B. wrote: I will have to wait for the task's completion by watching the thread's termination via WaitForSingleObject(hThread, INFINITE) there.
Then there's really no point in having a second thread if you're still doing things in serial. The implementation misses the point of multithreading.
I suggest you spawn the thread as you already do, but continue after the thread is created and don't wait for it.
When the thread has finished its task it should post a message to the main thread/window to inform the main thread that it has finished. In the message handler you can then enable your button again and do whatever you have to do in order to clean up.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Then there's really no point in having a second thread if you're still doing things in serial. The implementation misses the point of multithreading.
Agreed. It's amazing how many folks start doing Windows development synchronously.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: Agreed. It's amazing how many folks start doing Windows development synchronously.
I know what you mean, and it is an issue. I don’t find is surprising however; its natural to think sequentially and if you're used to writing console applications even more so.
Steve
|
|
|
|
|
That's what I was trying to describe - you did a better job!
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
Roger Stoltz wrote: Then there's really no point in having a second thread if you're still doing things in serial. The implementation misses the point of multithreading.
While true to a large degree this is not always the case. For example, you may be doing a long task and want to keep the UI responsive or even if the UI is disabled you still want the application to repaint itself while the task is in progress. You could scatter message pumps throughout the long task but this is not always possible and even when it is it may not be practical.
Steve
|
|
|
|
|
I admit I have used ::MsgWaitForMultipleObjects(...) in the way you're referring to a couple of times. But those cases were very specific.
You can also get in trouble with re-entrancy with Chaos and Mayhem following if you're not careful. There was nothing in J.B.'s post that implied to me that this could be such a rare case, that's why I suggested the most common, straight-forward and less error prone way to do it.
I also think you're missing my point Steve.
I wrote that "the implementation misses the point of multithreading" referring to J.B.'s call to ::WaitForSingleObject(...) blocking the main thread during the wait. In that situation he would actually gain on doing the worker thread task in the main thread.
I intentionally phrased it that way leaving the possibilities open for the rare cases you're thinking about, even though I doubt this would be one of them.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks a lot for the suggestion Roger,
I am wondering where I should close the thread's handle (CloseHandle(hThread)) if I do not check for its actual completion. Receiving the message handler's call does not mean the thread's already returned I think? Another problem is that my task may contain multiple thread creations at the same time, the window would need to know when they all terminated too, which then I will get their exit codes for processing(GetExitCodeThread) as well as retrieve a timestamp at the time.
Some sort of "wait-until-all-done" is still needed for my case I think? And obviously that shouldn't be done in the main window. That's why I thought about creating a thread or a timer which creates and does my thread tasks.
Thanks again,
Best Regards,
Johnny
|
|
|
|
|
In short, here's what you should do when the thread has finished its work:
1. Post a user defined message with ::PostMessage(...) to the main thread to inform it that the worker thread is terminating.
2. In the message handler you wait on the thread handle to know when the thread has terminated.
3. [Optional] Get the exit code of the thread with ::GetExitCodeThread(...).
4. Close the thread handle with ::CloseHandle(...).
Read this[^] excellent article for more info about how to use worker threads.
Regarding your problem with multiple worker threads I suggest that you post the thread ID from the worker threads with the user defined message.
You should have a mapping between thread IDs and their handles. In the message handler you get the thread ID, look up the thread handle in the map and continue from #2 above. Don't forget to remove the thread ID and its handle from the map when you're done with it in the message handler.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks again Roger,
for very informative reply and link. They helped greatly.
Best Regards,
Johnny
|
|
|
|
|
J.B. wrote: Thanks again Roger,
for very informative reply and link. They helped greatly.
You're most welcome Johnny.
I'm pleased to hear that I was able to help you, so thanks for telling me. 
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
It sounds like you’re after the MsgWaitForMultipleObjects[^] function.
On a side note, you probably should be using _beginthreadex[^].
Here’s a quote from MSDN on the CreateThread function:
A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and _endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multi-threaded version of the CRT. If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions.
Steve
|
|
|
|
|
Hi
How we differenciate between
1) send one New Mail
2) Reply a existing mail
in webdav method
i find some forum subject property have him "Re: " keyword in prefix
but the User may change the subject line of the reply mail.
Thanks
Arunkumar S
|
|
|
|
|
Hi
If i have received a Mail Named : X
and I reply that mail namely : Re: X
How can i find relationship between " X " and " Re: X "
in inbox and sent Items folder
which property is used to identify the relationship
Please anybody help me.
Thanks
Arunkumar S
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
