|
Ouch .. NOOOOOOO ...
MFC apps are WINDOWS apps, not console apps.
The idea of an infinite loop in main cannot be used in a windows app, since a windows app is itself a loop.
You'll stuck your app, whith an infinite loop, pushing the CPU at 100% for ever, with the only chance, to the user, to kill it.
I suspect your real problem is that you're trying to do with MFC what you ususally do with traditional console application. That's not the way to go, with windows programming.
With MFC, consider this as starting points:
- CYourApp: public CWinApp has global linkage and exist for all the application life. Make its instance (usially a CYuourApp theApp varialble) to have global scope (by declaring it as external in a header included by all files - stdafx.h is good) and you can put any member in it and access it from everywhere.
- virtual CWinApp::Initinstance is called by the MFC embedded WinMain (like the main of traditional consoles) BEFORE the windows message looop is started. Any initialization code can be placed in the Initinstance override.
- Once the messageloop is started, the input devices (keyboard and mouse) are read by the system, and actions are sent as message to the active application's main window where are dispatched to the implementing C++ class member functions through a message map. You can respond to a message by doing any sort of calculation, but NEVER with an infinite loop, or the application will stuck.
- If you need to perform a lengthy operation through a loop, implement a loop like
whiile(your exit condition)
{
::MSG msg;
if (::PeekMessage(&msg, 0,0,0, PM_REMOVE) &&
!::TranslateMessage(&msg))
::DispatchMessage(&msg);
}
That is: give the system a chanche to manipulate input! (and remenber that input cannot be accessed with functions like getch() or cin::get etc. Input becomes messages deliveret to the main window)
(Another more sophisticated way is use a woker thread ... but if you're new to windows programming, multithreaduing is certinly not the starting point!)
- Output cannot be sent to any "stream": you must store it somewhere in your program, and them display it in the window by handling WM_PAINT (ususally with OnPaint)
- if you need a sort of "draw forever" program, you can instantiate a timer (::SetTimer)and respond to it in your main wiandow (OnTimer) with your loop's body (note BODY, not LOOP: the loop is in Windows, issuing the timer message)
Hope all this may help.
____________
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Hi,
I need to add a feature to a program to play an audio CD.
However, the audio needs to be output via the soundcard, (not through the auto connector on the back of the CD player...)
has anyone got any tips on where to look for this?
(Main features requires, play a track starting at a certain time into the track, and retrieving track playback progress).
Thanks...
|
|
|
|
|
mci functions can help you.
it works easily, it have High level functions that accept text Commands.
Search it in msdn
|
|
|
|
|
Yes, I have just discovered that they do work without the audio cable connected,
My initial look at them suggested they didn't...
Thanks 
|
|
|
|
|
Hello,
I create some instances of a window based on CFrameWnd inside a thread. The windows are created successful and I can show the windows. But after _endthread () all windows are closed and destroyed automaticly. Why that and what I should do ?
Example:
CViewDiffDlg *diffdlg = new CViewDiffDlg (); <br />
diffdlg->Create (NULL, "");<br />
diffdlg->ShowWindow (SW_SHOW);<br />
<br />
_endthread ();
Thank you for helping and ideas
Stephan
|
|
|
|
|
I think you can send a message to the main thread to create the windows for you, and give the pointer back to your thread, so you can do whatever you want with it. That way the created windows should not die with the thread.
this is this.
|
|
|
|
|
Thank you for the answer, but
that don't solve my problem.
I've try your solution before I write the question to CP. The effect is the same. Window(s) are created and I see all what I want, but if the thread is closed, all windows are destroyed.
I don't need the window pointer anywhere. The window should be open and process his messages. Thats all.
Any other ideas
Best regards
Stephan
|
|
|
|
|
Hello...
The problem is that you create Windows inside from a worker thread which can produce unexpected situations...
You shouldn't directly create and manipulate gui objects in a worker thread...
Try to create and manipulate the window in the main thread...
F.E.: Create custom user messages and send them to mainframe.
like: #define WM_CREATEFRAME WM_USER + 200
#define WM_UPDATEFRAME WM_USER + 201
#define WM_DESTROYFRAME WM_USER + 202
in your worker thread:
void CMainFrame::workProc(LPVOID data)
{
// main window
CMainFrame *fr = static_cast<cmainframe*>(data);
::PostMessage(fr->m_hWnd,WM_CREATEFRAME,NULL,NULL);
while(anyThing)
{
// do a lot of calculations
::PostMessage(fr->m_hWnd,WM_UPDATEFRAME,NULL,NULL);
::Sleep(10);
}
::PostMessage(fr->m_hWnd,WM_DESTROYFRAME,NULL,NULL);
}
The mainframe process the custom messages and do the work on gui objects.
Best regards from germany
|
|
|
|
|
Thank you for the answer,
the idea is good but it doesn'nt solve the problem. Sh*t.
In my case I call SendMessage instead of PostMessage, because the thread should wait until window creation process is finished. If I debug and stop execution before I call _endthread() I see my window in the tasklist. After _endthread() window is killed.
Greetings back from germany to germany
Stephan
|
|
|
|
|
Yo baby yo baby yo
It works. Your solution was good. I had a mistake in the MessageMap.
Thanks to all for helping
Stephan
|
|
|
|
|
I don't have any problem with MFC dialogs. Maybe you need to look into the message pump in CWinThread::Run to see what happens when a main window of an MFC thread closes.
http://blog.joycode.com/jiangsheng
http://blog.csdn.net/jiangsheng
Command what is yours
Conquer what is not
---Kane
|
|
|
|
|
Thank you for the answer,
To try this, I must rewrite my code, because I don't use CWinThread now. I'm from "old school" like using _beginthread () with global Threadfunctions. And so a function should terminate intern via _endthread() (extern TerminateThread()).
I think, here is my problem, because the documentation describes, that _endthread() will clear up all objects from stack (and may be from heap too) they are created inside the thread.
I will try your sugestion with the message pump. May be I can see some mistakes.
Stephan
|
|
|
|
|
MFC thread state is needed by MFC objects. You need begin the thread with AfxBeginThread.
http://blog.joycode.com/jiangsheng
http://blog.csdn.net/jiangsheng
Command what is yours
Conquer what is not
---Kane
|
|
|
|
|
Yo baby yo baby yo
It works. The solution of HumanOsc was good. I had a mistake in the MessageMap.
Thanks to all for helping
Stephan
|
|
|
|
|
Hello again...
My solution is based on the great Articel from Joseph M. Newcomer:
http://www.codeproject.com/threads/usingworkerthreads.asp[^]
This is a very nice Introduction about worker threads.
Be carefull about SendMessage, it can also produce unexpected situations like a deadlock from your app...
Always prever the use of PostMessage to provide a safe gui access.
But Sometimes it's recommend (before or after the end of a worker thread) to get sure thats no (old) messages exists in the message queue.
In this situations use PeekMessage, GetMessage and DispatchMessage in main thread to remove (process) all old Message from Queue...
Best regards... 
|
|
|
|
|
I am searching for the location of the strcmp function so that i may be able to dynamically load it.
In which dll does it reside?
In which dll's do c-runtime libraries reside in general?
|
|
|
|
|
|
If you are programming in C/C++, you would be hard pressed to not already have that DLL loaded (unless you link statically).
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hello,
I need to provide a trial license for my application which should expire after a predefined expiry date. How should I go about doing the time comparison so that it can not be tampered by changing the system date.
Thanks in Advance.
|
|
|
|
|
|
Thanks, but this is a standalone application and can not rely on getting any information from anywhere outside the system.
|
|
|
|
|
You can write the current system time at application exit as Exit-Time. When the user opens application the next time, it should compare the current time with the Exit-Time. If the current time is less than the Exit-Time, just exit the application or whatever.
this is this.
|
|
|
|
|
But the user can reset the system time to an earlier time before exiting the application and use the application for ever.
|
|
|
|
|
I guess you can also write the current time down every five minutes etc, after comparing it with the stored time.
And I am about to logout for the day.
this is this.
|
|
|
|
|
how about instead of letting it run for a certain amount of time, you let them use it a certain number of times. I think that's easier.
My articles
www.stillwaterexpress.com
BlackDice
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
