You do not provide a compilable project, and from your description it's not clear what kind of error you get. Is it compile time error? run time error? If run time, did you try to debug your code and inspect the parameters that were passed to memcpy?
As for the WM_PAIN handler design, it seems you totally ignored all my comments provided in the other thread's post. So please be aware that you keep going wrong way.
So what's the result of Arjay's request from post #2?
All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!
I find my mistake and cleared. Its a exceed buffer size problem.
Code:
BYTE * src = new BYTE[bytes];
src = (BYTE*)bm1.bmBits;
Do you see what's wrong with those two lines? Forget about bitmap data for a moment -- on a C++ level, do you see the issue with those two lines above?
The new[] returns a pointer value. Then on the second line, you just throw it away and replace that value with another. How are you going to deallocate the memory if you throw away the original value?
Your code is no different than just doing this:
Code:
src = (BYTE*)bm1.bmBits;
but it's worse now that you've introduced a memory leak.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; June 23rd, 2013 at 11:31 PM.
Please, do not put more than one statement in the same line! Code written in such a manner (two or three statements per line) is very hard to read, very hard to debug and very hard to maintain!
Besides, why do you insert an empty line after each line with code? It only makes sense if you separate some logical parts or blocks of your code, but there is no any in your code snippet!
I'm in beginner stage. If i'm doing any mistake, please take me to a right path at all time.
Code:
int main()
{
int x = 0;
int *p = new int [10];
p = &x;
}
This is basically what your bit of code I pointed out is doing. You tell us -- do you see what's wrong with those three lines of code above? It gets worse if you then do this:
Code:
int main()
{
int x = 0;
int *p = new int [10];
p = &x;
delete [] p;
}
What is wrong with the lines above? If you don't know, then you have a much larger issue than bitmap handling -- you need to know how to use the C++ language properly.
i understood like, pointer p allocate the memory using new operator. So we must use the delete operator to deallocate.
But here,
Code:
p = &x; // declaration is wrong - reference operator & can't allow to deallocate the memory
The "&" used above is not the reference operator. That is the address-of operator, and has nothing to do with references. The code is perfectly valid. There is nothing wrong syntactically with it.
What is wrong is that the pointer value returned by operator new[] is stored in p, but then it is thrown away by assigning another address to "p" immediately afterwards. That is exactly what your code you say is "resolved" was doing, so nothing has been "resolved".
All you did in your new code was to move the memory corruption bug somewhere else. These lines did absolutely nothing except cause a memory leak, and worse, it masked the underlying problem:
Code:
BYTE * src = new BYTE[bytes]; // allocating memory, storing pointer value to allocated memory in "src"
src = (BYTE*)bm1.bmBits; // throwing away pointer value returned by new[] above with another pointer value. This is wrong!
Do you see the similarity between the code above, and the simple example I posted?
What I suggest is that you get rid of your "solution", bring back the old code that caused the problem, and fix the program correctly without throwing random lines of code that just masks the bug (i.e. changes the executable image so that the memory bug is hidden, but not fixed).
Unlike other computer languages, it is very easy to think that a problem is "resolved" in C++ by writing random lines of code and seeing the problem seemingly disappear without reason. But that is not a solution -- the only coded solutions in C++ are ones that can be explained coherently as to why the new code solves the problem.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; June 28th, 2013 at 05:08 AM.
Unlike other computer languages, it is very easy to think that a problem is "resolved" in C++ by writing random lines of code and seeing the problem seemingly disappear without reason. But that is not a solution -- the only coded solutions in C++ are ones that can be explained coherently as to why the new code solves the problem.
True, so true. When trying to find a problem in a program the one thing I hate above all others is to add an innocuous print statement and either find the problem 'has gone away' or a different problem appears. This invariably means a memory corruption problem somwhere and a late night debugging session! Just because a c++ program seems to work on your computer doesn't mean that it will work correctly on another computer - or even on yours the next day! That's why c++ programs need to be carefully designed, coded, tested and thoroughly debugged to make sure they are robust.
All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!
That's why c++ programs need to be carefully designed, coded, tested and thoroughly debugged to make sure they are robust.
You make it sound like C++ is necessarily so.
You can just as well adopt methodology and use/by/develop libraries that will let you develop C++ code with the same ease as other languages while still allowing you to go "out of the confines of the box" if such is needed.
Yes, C++ allows you to write "messy" code, that doesn't mean it's smart to do so
You can just as well adopt methodology and use/by/develop libraries that will let you develop C++ code with the same ease as other languages while still allowing you to go "out of the confines of the box" if such is needed.
Yes, C++ allows you to write "messy" code, that doesn't mean it's smart to do so
Agreed. But IMO this comes back to a recurring theme in these forums - correct teaching of c++.
All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.