C / C++ / MFC Discussion Boards

Re: ASSERT()! Why?And how to resolve it?

KarstenK14-Jun-07 0:37

14-Jun-07 0:37

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) Dead | X|

Greetings from Germany

Re: ASSERT()! Why?And how to resolve it?

kcynic14-Jun-07 1:20

kcynic

14-Jun-07 1:20

I think there is no window destroyed and no handle is acessed during such process,because no action I had done.

Re: ASSERT()! Why?And how to resolve it?

KarstenK14-Jun-07 1:41

KarstenK

14-Jun-07 1:41

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. Mad | :mad:

Greetings from Germany

Re: ASSERT()! Why?And how to resolve it?

kcynic14-Jun-07 2:11

kcynic

14-Jun-07 2:11

I create the second dialog in the function of the first dialog. I also using GetCurrentThreadId() to indicate the thread ID is the same.

Re: ASSERT()! Why?And how to resolve it?

KarstenK14-Jun-07 2:20

KarstenK

14-Jun-07 2:20

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

Re: ASSERT()! Why?And how to resolve it?

kcynic14-Jun-07 3:07

kcynic

14-Jun-07 3:07

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?

Re: ASSERT()! Why?And how to resolve it?

KarstenK14-Jun-07 3:17

KarstenK

14-Jun-07 3:17

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

Re: ASSERT()! Why?And how to resolve it?

Roger Stoltz14-Jun-07 1:04

Roger Stoltz

14-Jun-07 1:04

A few lines down from the position in wincore.cpp you refer to is a comment that says:

// Note: if either of the above asserts fire and you are
// writing a multithreaded application, it is likely that
// you have passed a C++ object from one thread to another
// and have used that object in a way that was not intended.
// (only simple inline wrapper functions should be used)
//
// In general, CWnd objects should be passed by HWND from
// one thread to another.  The receiving thread can wrap
// the HWND with a CWnd object by using CWnd::FromHandle.
//
// It is dangerous to pass C++ objects from one thread to
// another, unless the objects are designed to be used in
// such a manner.

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

Re: ASSERT()! Why?And how to resolve it?

kcynic14-Jun-07 1:17

kcynic

14-Jun-07 1:17

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.

Re: ASSERT()! Why?And how to resolve it?

Roger Stoltz14-Jun-07 1:32

Roger Stoltz

14-Jun-07 1:32

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

Re: ASSERT()! Why?And how to resolve it?

kcynic14-Jun-07 2:08

kcynic

14-Jun-07 2:08

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.

Re: ASSERT()! Why?And how to resolve it?

Roger Stoltz14-Jun-07 3:45

Roger Stoltz

14-Jun-07 3:45

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

Re: ASSERT()! Why?And how to resolve it?

kcynic14-Jun-07 19:35

kcynic

14-Jun-07 19:35

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.

Re: ASSERT()! Why?And how to resolve it?

kcynic14-Jun-07 19:54

kcynic

14-Jun-07 19:54

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.
}

Re: ASSERT()! Why?And how to resolve it?

Roger Stoltz15-Jun-07 0:15

Roger Stoltz

15-Jun-07 0:15

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

Re: ASSERT()! Why?And how to resolve it?

kcynic15-Jun-07 0:44

kcynic

15-Jun-07 0:44

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

Re: ASSERT()! Why?And how to resolve it?

Roger Stoltz15-Jun-07 1:35

Roger Stoltz

15-Jun-07 1:35

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

Re: ASSERT()! Why?And how to resolve it?

kcynic14-Jun-07 20:32

kcynic

14-Jun-07 20:32

And the theApp is the main thread.But if I pass messages to it,how to retrieve returns from theApp?

picture control

tyagineha14-Jun-07 0:17

tyagineha

14-Jun-07 0:17

how to insert a picture control in following article :::

http://www.codeproject.com/directx/LiveVideo.asp?df=100&forumid=50103&fr=26

i wanna know the steps...

NT

Re: picture control

Mark Salsbery14-Jun-07 7:50

Mark Salsbery

14-Jun-07 7:50

tyagineha wrote:
i wanna know the steps...

You could always download the source code from the article - I bet the steps are there Smile | :)

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Re: picture control

Hamid_RT14-Jun-07 20:09

Hamid_RT

14-Jun-07 20:09

Mark Salsbery wrote:
You could always download the source code from the article - I bet the steps are there

I think yes but if we always have source code.;)

WhiteSky

Re: picture control

tyagineha14-Jun-07 20:17

tyagineha

14-Jun-07 20:17

Can u tell me the link........

NT

Re: picture control

Mark Salsbery15-Jun-07 5:37

Mark Salsbery

15-Jun-07 5:37

I got the link from you Smile | :)

The Link[^]

Look for the "Download source files" link at the top of the article.

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Getting TCP/UDP Tables with ProcessIDs before XP

Akin Ocal13-Jun-07 23:17

Akin Ocal

13-Jun-07 23:17

It can be done with GetExtendedXXXTable functions of IPHelper API , but i cannot use under Windows2000 , i only have GetXXXTable for it but they dont give me process ids , i mean i want to learn which processes do any thing on tcp/udp ports in Win2000. How can it be done like TCPView on Pre-XP Systems ?

Thank you very much...

Debugging in VC++

Raj Prathap13-Jun-07 23:08

Raj Prathap

13-Jun-07 23:08

Hi,
I have a for loop, which executes for 100 times. I want to skip initial 50 iterations, and from 51st iteration, I want to execute the code statement by statement.
Please suggest, if any easy method is there.

Thanks and regards,
Raja Pratap

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.