i got a huge project which works nice in release build
You realize that the assertion is telling you that you are issuing Scroll Bar Functions to an object that is not realized as a window. That is, the fact that m_HWND is NULL means that you are trying to scroll a window that doesn't exist. I'm not sure of your definition of "working fine" but this ain't my definiton. You should fix these.
This post shouldnt be voted down because it is important that beginner programmers understand why DEBUG ASSERTS must be resolved.
mackel90, you really need to learn to program properly. And so do your colleagues who put this project together. Read the other good comments here, and think very very carefully about what is being said.
YOU MUST RESOLVE THESES DEBUG ASSERTS BEFORE YOU BUILD A RELEASE VERSION.
It is also good practice to back up a DEBUG ASSERT with a line of code that checks the same thing and exits the func so in release mode you have the same level of protection.
Take my opinion as a pointer, not a definite answer.
Most likely you are doing something with one of your controls when it is not loaded/initialized yet. For example, say you have a dialogbox named CMainDlg. Now If you try to set text of an editbox in CMainDlg's constructor like this
The foresight of that thought sure seems to be an oxy-moron in hindsight
I want to get my work done quickly today, so I can triple my work tomorrow.
I still don't understand how the current release version can work perfectly, unless he broke the project and can't fix it, or the current release version was never fully tested, and it really doesn't work perfectly.
Perhaps the OP is having a really bad day, and is ready to go postal.
Do not run the ping utility.
ping.exe is an external file that can be deleted and then your objective will fail.
Instead, send a special packet or use a separate socket to send a packet in the OnIdle function or in a timer event.
«_Superman_» I love work. It gives me something to do between weekends.
No, do not use Ping and do not rely on running it in OnIdle(), you should use a timer.
There are several ways a TCP link can "break" without both sides being properly notified, especially over the Internet, but even on a LAN. If it is important to you to have reliable, persistent links and you have control over the server side code, I suggest you define a keep-alive mechanism.
There are many, many ways of doing this. Over the years I have found the following approach to be sufficient just about anywhere I use persistent TCP connections.
- Determine which side will be sending data the most. Let's call that side A, the other side is side B. Depending on the nature of your applications, side A can be either the server or the client.
- Determine the maximum time a link can be down before reacting to it - 1 second, 10 seconds, 30 seconds, etc. Let's call that T. You do not want to flood the network with these messages, so go as high as you can.
- Side A must keep track of the last time a message (data or keep-alive) was sent. If more than T/3 seconds have passed since a message was sent, send a keep-alive message. If the link has gone down, the socket send operation will fail and the program has to react to it.
- Side B must keep track of the last time a message (data or keep-alive) was received. If more than T seconds have passed since a message was received, consider the link down and react to it.