|
but I using VS2005 to debug it.How should I doing such things?
|
|
|
|
|
You may be using an unassigned variable or deleting a pointer that does not exist or doing some other incorrect operation. It should ideally not be the MFC files that would show an Assertion error.
Did you try and debug your code?
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
but I did nothing when the dilog disapeared.
It would crash after about one min!
|
|
|
|
|
was this dialog created by a non mfc-thread ?
|
|
|
|
|
no,this dialog was create in a function of its parent dialog which also derived from CDialog
|
|
|
|
|
are you calling the DoModal() with a NULL from a different thread ?
|
|
|
|
|
I only using its member function ShowDialog(TRUE) to make the dialog appeared after I create the modeless dialog.That wat right or wrong to use modeless dialog?
Thanks
|
|
|
|
|
the handle is valid that is clear. It means there is something wrong. In most cases the windows has been destroyed or the windows was not properly (created, from another Thread) 
Greetings from Germany
|
|
|
|
|
I think there is no window destroyed and no handle is acessed during such process,because no action I had done.
|
|
|
|
|
As I see you havent read my posting with the needed correctness. If you have 2 dialogs and share some data, as handles or messaging you HAVE to create them in the SAME thread.
Greetings from Germany
|
|
|
|
|
I create the second dialog in the function of the first dialog. I also using GetCurrentThreadId() to indicate the thread ID is the same.
|
|
|
|
|
That sounds fine.
Can you indentify to which windows the asserting handle belongs? (Tooltip?)
Are you creating others windows in one of the dialogs?
Greetings from Germany
|
|
|
|
|
No,I only cound found the assertion occured in the wincore.cpp,but nothing .
How should I know witch code I write bring up such problem?
|
|
|
|
|
You must step back to find the position or put out all window handles, or look at the call stack. There is also the Spy++ program.
I think the problem is to heavy for your experience, you should ask someone to debug your code. A collegue or a friend. SCNR
Greetings from Germany
|
|
|
|
|
A few lines down from the position in wincore.cpp you refer to is a comment that says:
You should read this article[^] the "Thread Maps" section in this article[^].
After you've read those articles you will know what to do and how to pass a MFC window object from one thread to another.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
according to the note,the problem is because the parameters I had passed.
There,in my codes,I only created a modeless dialog using create() function,and then call its ShowDialog(TRUE) to show it.In the second dialog's new operator function,I pass the current dialog's point as its first parameter,when I created it,I pass the current dialog's point as the first parameter again.
In another hand,I only pass a thread point which was create and start in the parent dialog.
That's all.There is no other parameter passed from one to another.Is any problems?
Best Wishes.
|
|
|
|
|
kcynic wrote: I only pass a thread point which was create and start in the parent dialog.
 What do you mean by "passing a thread point"?
Are you, or are you not, using multiple threads?
You'd better post some code snippets showing how you create your dialogs as well.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Oh,I had usint the example [^]" rel="nofollow"> [^][ [^]">^]you send to me somedays before,and I also sent a e-mail to you of my problem of testing such example.I have pass the CClientThread point between some dialogs.
|
|
|
|
|
Ok, so you've used Newcomer's example as starting point.
As I understand it, you're passing the CClientThread pointer between dialogs. I don't see why though... You have to explain this because this could be part of your problem.
When I asked about some code snippets I wasn't joking; it's impossible to help you further if you don't show what you've done so far. It should be sufficient with the code that creates the dialogs.
For some reason I feel like your dialogs are created in the threads that contains the sockets. This is not a good thing for many reasons. You should post messages to the main thread to do this stuff so that the main window is the parent for your dialogs.
By the way:
I haven't received any mail from you regarding your problems and even if I did I would would have informed you not to post to me, or anyone on the boards, directly.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Yes,you are right,I did really using the example and passed CClientThread pointer between dialogs.
And it worked well at begining.But when it is connected with the server,I want to pass the connection to other dialogs and keep it active and no-recreated.What should I do?
Thanks.
|
|
|
|
|
I passed the thread like this:
parentDialog::function()
{
CThirdDlg* dlg=new CThirdDlg(this);
m_pClientThread->SetTarget(dlg);
m_pClientThread->m_socket.SetTarget(dlg);
...//other initializing
dlg->Create(IDD_MYDIALOG,this);
dlg->ShowDialog(TRUE);//i didn't know why it didn't show itself if no such code.
}
|
|
|
|
|
kcynic wrote: m_pClientThread->m_socket.SetTarget(dlg);
This implies that you've modified the original source code that Newcomer wrote since the m_socket member was originally protected and the above would generate a compiler error if it still is. So you "fixed" the compiler error by making the member publicly declared instead.
The bad news is that you've made this change to the original code in order to use it in a way it wasn't intended.
The design that Newcomer made is built on the idea that each socket informs the main window/thread about things of interest, such as when the socket thread has started and when the user has to be notified for some reason. You should not brake this design.
When the socket thread needs to notify the main window, it posts a user defined message to it. This is what the target member is for. Changing the target to a "temporary" window while the thread is running will create various race conditions that eventually will lead to the ASSERT you got. This may happen since at some point the socket thread will try to post a message to a window that doesn't exist any longer or for some other obscure reason. You may find the reason if you follow Naveen.R's advice about the call stack. You will probably find a call to CWnd::PostMessage() or CWnd::SendMessage() in the call stack in a socket thread.
What you should do is keep the design and let the main window be the "information collector". If you want to create other windows, they could register themselves as observers to the main window so the main window can inform them about events of interest.
But whatever you do you cannot change the "target" window after the socket thread has been allowed to start.
I guess it boils down to a question about design.
What are your dialog windows supposed to do?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Here,I want the client connect the sever using translate its username and password in the login dialog.When the server checked the user account correct, the server would return a success flag to the client,then,the client create the second dialog. Others who using the likely second dialog would send messages to it and it also cound return messages to the others.
There also would create the third dialog and translate messages each other.
But all the clients should keep connected to the server and doesn't create second connect. I have no idea to resolve such problems.
I had done such things by changing the m_socket from protected to public as you said. Since there will be some wrong way,I could not know how to do,now.
Thanks
|
|
|
|
|
kcynic wrote: I want the client connect the sever using translate its username and password in the login dialog.
When you've received the request for authentication in the main window, you should pop up a modal dialog asking the user for login information, i.e. user name and password. This means that the main window is the parent of the "login dialog" and the dialog itself doesn't need to have a connection; it simply takes some user input that the main window can get when the dialog is dismissed by the user. The login information should then be sent by the socket thread by the main window in order to reach the server for authentication.
kcynic wrote: There also would create the third dialog and translate messages each other.
I don't really understand the point of this third dialog.
In Newcomer's example there is a control that displays the data sent and received. Does the third dialog substitute this control?
If the answer is 'yes' I suggest you create the third dialog modeless and put the information there from the main window, keeping the main window as "information collector".
kcynic wrote: But all the clients should keep connected to the server and doesn't create second connect. I have no idea to resolve such problems.
If you by "all clients" mean "all your windows", you don't need more than one connection. Simply let the main window be the central point that gathers the information and reacts to it, dispatching the information to other windows if needed.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
And the theApp is the main thread.But if I pass messages to it,how to retrieve returns from theApp?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
