|
Hello Everybody:
I was wondering if someone can tell me how I can play a wave files in MFC. Or if there is any other way to do it. Thanks and hope to hear from you guys soon.
Have a good day!!
Luis E. Cuadrado
)
|
|
|
|
|
Take a look at the PlaySound function in the MSDN, it can play wave files for you. There's many ways to do it, but PlaySound is one of the simplest.
Chris Richardson
|
|
|
|
|
Here is a link.
Also, this article contains a multithreading flaw as described in my comment
Best regards,
Alexandru Savescu
|
|
|
|
|
Hello. I need to kill a thread when a dll is unloaded (in DllMain). However, the OS would not let ExitThread to return as long as any other thread is in DllMain, and I have a deadlock.
Any hints?
And yes, I've tried DisableThreadLibraryCalls. Doesn't work
|
|
|
|
|
It was me who posted the question - just from the wrong computer
I vote pro drink
|
|
|
|
|
Short answer is never do that.
Step back, rub your eyes, take a deep breath, stretch a bit, and reflect on the relative importance of CP, CG, the age / travel time sustained by supposedly 'fresh' cheese curds, and Life in General. - Shog9
|
|
|
|
|
Easy to say. I have a static (read global) variable in this DLL that launches a thread, and in its destructor I need to kill this thread. The problem is that the destructor is called in DllMain.
I vote pro drink
|
|
|
|
|
Ok the question is - who calls FreeLibrary?
You should provide the client with calls that shutdown the thread.
Step back, rub your eyes, take a deep breath, stretch a bit, and reflect on the relative importance of CP, CG, the age / travel time sustained by supposedly 'fresh' cheese curds, and Life in General. - Shog9
|
|
|
|
|
FreeLibrary is called from an ATL 7.0 DllCashe class, and I cannot change it.
I vote pro drink
|
|
|
|
|
In that case derive a class from CDllCache. In your implementation of IServiceProvider return a reference to this class when asked for DllCache. In your implementation you can explicitly terminate the thread before freeing the library.
Step back, rub your eyes, take a deep breath, stretch a bit, and reflect on the relative importance of CP, CG, the age / travel time sustained by supposedly 'fresh' cheese curds, and Life in General. - Shog9
|
|
|
|
|
Rama Krishna wrote:
In that case derive a class from CDllCache
Thanks for the tip Actually, I thought of doing something like that, but I hoped there was a simpler solution.
Thanks again.
I vote pro drink
|
|
|
|
|
What's about the following idea:
Do you really need DLL_THREAD_ATTACH and DLL_THREAD_DETACH notifications in your DLLMain?
If not, you could disable them at loadtime (during DLL_PROCESS_ATTACH) by calling DisableThreadLibraryCalls(). Then at DLL_PROCESS_DETACH time you could simply signal your thread and wait until it has ended. Because it does not have to go through DLLMain any more, no deadlock should arise.
--
Daniel Lohmann
http://www.losoft.de
|
|
|
|
|
As I said in my original post, I have tried that already, but it just doesn't work: the bloody thread just won't end while any other thread is in DllMain even if DLL_THREAD_DETACH notification is disabled.
I vote pro drink
|
|
|
|
|
Nemanja Trifunovic wrote:
As I said in my original post, I have tried that already, but it just doesn't work: the bloody thread just won't end while any other thread is in DllMain even if DLL_THREAD_DETACH notification is disabled.
Ehm, you said this in your original post???
However, it is really sad that it does not work. Seems that the system uses internally a process wide Mutex/CS that has to be passed during ExitThread - regardeless if the tread afterwards calls DLLMain or not
I frequently get the feeling that this "only one thread in DLLMain at a time" thing brings us more headaches than it solves. Better teach developers to deal gracefully with concurrency and let them do the things on their own!
--
Daniel Lohmann
http://www.losoft.de
|
|
|
|
|
I was trying to populate a richedit ctrl and had a callback function etc, When I tried to run it - "failed to create empty document". and a blank frame shows up. So I undid I believe everything and got the same error. I am going to scrap this copy but am terribly puzzled as to why and how to recover.
Ideas and suggestions are welcome!\Thanks,
ns
|
|
|
|
|
You need to call AfxInitRichEdit() if you are using RichEdit 1.0.
Chris Richardson
|
|
|
|
|
Where do I call this function? In OnInitialUpdate of my view class in which the control resides?
Thank you so much!!!
ns
|
|
|
|
|
That did it. I put it in the apps initinstance....
I reallly appreciate your help!!!
Many thanks,
ns
|
|
|
|
|
No problem ... sorry for the semi-vague reply the first time.
Chris Richardson
|
|
|
|
|
Dear Friends,
I want to develop a notepad type application using
doc/view architecture.If you got the code please mail at
kashif1112000@hotmail.com
|
|
|
|
|
CEditView or CRichEditView will be helpful in such application. It will save you a lot of coding.
|
|
|
|
|
Jeff Prosise's "Programming Windows with MFC" has an excellent example located within chapter 12, you might want to check it out.
-Ken Mazaika
|
|
|
|
|
I read something about mb_autoDelete but cant find it now . At one point I destroy a view, and I think I'm suposed to safeguard the document by setting this variable to something (True or FAlse). Is mb_autodelete a member function of the doc class? I didnt see it in the doc.h file. MSDN has no relevant info. what should I set it to and WHERE should I set it?
Thanks for helping,
ns
|
|
|
|
|
To be honest with you, your question is a little vague, however, I think I've found the answer you're looking for.
An auto delete member variable is a fairly common thing and could be anywhere. However, I do believe what you are looking for is m_bAutoDelete and not mb_autoDelete. It would help to learn the notation used by Microsoft. In this case m_ means member variable and b means boolean. So the correct variable name is m_bAutoDelete. If you do a search in the MSDN library with your Visual Studio install for this variable name, you'll see that the variable you are looking for is in fact in the CDocument as you suspected.
This particular member variable tells MFC not to delete the document when the view is destroyed if you set it to FALSE.
Here's some code from the MSDN library used in a replace view method:
CDocument* pDoc = pView->GetDocument();
BOOL bSaveAutoDelete = pDoc->m_bAutoDelete;
pDoc->m_bAutoDelete = FALSE;
pFrame->SetActiveView(NULL);
Good luck.
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
|
Thanks. But my program started acting very flakily when I added this snippet. SO I am going ahead with the DestroyWindow without regard to m_bAutoDelete. It really makes my app behave weirdly. I'm glad I tried it though---
Thanks,
ns
|
|
|
|