|
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
|
|
|
|
|
That would be easier. But the users require trial periods based on time.
|
|
|
|
|
See here.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Thanks for the link. This works fine once the license expires. But, the user can work by changing the system date back to an allowed date before starting the application so that he never gets the license expired message. This way i think he can use the application for ever.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
