|
is this in your code or is this more "typo" during entry:
Quote: CComBoBox
you have too many capital "B"s in your CComboBox
|
|
|
|
|
Most likely, this is your problem:
CString CXbeefixedDlg::getCurStrInCombobox(const CComBoBox &a) Instead of CComBoBox, it should be CComboBox
Hope that helps.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
First:
The member function listed in the compiler message looks like a conversion constructor for the class CString, taking a parameter of type CComboBox. Apparently the compiler found a function call somewhere in your code that requires a parameter of type CString, but you passed it a parameter of type CComboBox. Therefore it tried to find a conversion function from CComboBox to CString, and because it didn't find one, it issued this error message.
Solution: locate the position in your code that the error message points to and replace the CComboBox argument with one of type String, or convertible to CString.
(P.S.: the error message looks like there's something missing - it might just be what Chuck said)
Second:
This might be a followup error, but I cannot fathom how. You might have forgotten to include the right header, but I doubt that - it would cause quite a lot more errors, and the compiler wouldn't even recognize the symbol CComboBox to be a class. Maybe you mistyped the type CComboBox for ComboBox, like you did in your posting? It might be helpful to see a piece of code that these error messages point to.
|
|
|
|
|
Hi,
The following code in VS2008
CString str;
char Singature[16];
strcpy (str.GetBuffer() , Singature);
str = "_________________Header_________________";
reports me the following message :
"Windows has triggered a breakpoint in xxxxx
This may be due a corruption of the heap, which indicates a bug in xxxx or any of the DLLs it has loaded."
When I delete the strcpy code, then it works fine. What seems to be the problem here ? The mentioned code it worked just fine in VS6.
sdancer75
|
|
|
|
|
The strcpy function keeps copying until it reaches a terminating null.
Since you did not initialize Signature, there is probably no null character contained in it.
Thus, strcpy is writing to memory that it should not. That is the cause of the error.
Try using the following code instead:
char Singature[16] = { 0 };
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
That's not true. The example is just a copy/paste from a bigger application and I forgot the mentioned initialization..
Please take a look in the uploaded example at https://rapidshare.com/files/2185607429/test.zip[^]
The problem is occured at line 104 in the testDlg.cpp file.
sdancer75
|
|
|
|
|
Well how do you expect to get help if you don't post the exact example of code?
No one is going to download a zip file to look at your code. You need to post a snippet here.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Thank you for you reply.
Sorry for the attached zip, it was an empty MFC project with just 4 lines of the offended code.
I get my answer below. Thank you again for your time !!!!
Best Regards,
sdancer75
|
|
|
|
|
is Signature longer than the current contents of str ? if so, you have a probable buffer overrun.
you also need to call ReleaseBuffer.
|
|
|
|
|
The Signature is a char array with 16 elements. The str is just a CString. The CString its a dynamic structure and dont need to make reservations in size before.
Take a look sample at https://rapidshare.com/files/2185607429/test.zip[^]
The problem is occured at line 104 inside testDlg.cpp
thanks
sdancer75
|
|
|
|
|
sdancer75 wrote: The CString its a dynamic structure and dont need to make reservations in size before.
how could a CString possibly know how many bytes you are going to copy into it?
|
|
|
|
|
You are right !!! My stupidity !!!
Thank you for your time !!
sdancer75
|
|
|
|
|
Oh, this statement is so wrong, especially since you are getting a pointer to the CString's buffer and manipulating it yourself, directly and wrongly. You've removed all dynamicicity (is that a word) from CString this way.
|
|
|
|
|
Obviously the example is meaningless so hopefully it is just that.
However the signature for strcpy is strcpy(dst, src).
And strcpy requires a null terminated array for src. Your example does not have that because your src is not initialized.
|
|
|
|
|
The example is just a copy/paste from a bigger application. The src is initialized but i forgot to copy it in my example, sorry.
Please take a care at the sample code i upload at https://rapidshare.com/files/2185607429/test.zip[^] and take a look at line 104 inside the testDlg.cpp. Its almost the same situation.
Regards
George
sdancer75
|
|
|
|
|
Stop reposting this link, nobody is going to download this. Show the code that is causing the problem, including the initialisation pieces, so people can actually understand what your program is trying to do.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Arrrgh. Warning Warning. You are messing with the fundamental forces of the universe.
The CString object goes out of its way to hide the string buffer from you. It manages that buffer itself, manages as in "keeps track of the size and allocation / location" and is free to move it around as it sees fit (like when you add / concatenate / change the contents).
Here, you've used "GetBuffer()" to find out where the string lives, and then proceed to write all over it with strcpy(). Even if you string sizes are fine and the lengths are initialized, etc, you are writing into a buffer you don't own, CString owns it.
This will almost always cause some sort of corruption.
Do not write into buffers you do not own nor control the size of.
I don't know how to say that strongly enough.
PS, you could at least help CString by telling it how big a buffer you wish to write into, like using "GetBuffer(sizeof(Signature))" but, even then, as others have pointed out, Signature is not initialized so who knows how many characters strcpy() will try to move.
Check the docs for GetBuffer() for more information about what you have to do when you done fiddling the buffer, assuming you use the right size. http://msdn.microsoft.com/en-us/library/aa314880(v=VS.60).aspx[^]
|
|
|
|
|
That's true, this is likely the problem... Don't write to a CString buffer directly like this. +5
|
|
|
|
|
|
Yes,that worked just fine.
I was so stupid, that i was pretty sure that CString would resize its internal buffer automatically and I dont even get tried to play with that !!! VC++ 6 did not reported any errors and I just surprised when I met this error in VC2008.
Thank you Richard !!!
sdancer75
|
|
|
|
|
The problem here I think is because CString isnt initialised. You cant copy data using strcpy into an empty CString, it cant allocate storage for the new data.
Instead use:
str = Signature;
or:
CString str(Signature);
==============================
Nothing to say.
|
|
|
|
|
Thank you for your reply.
The problem was not the initialization but the CString internal buffer. I got my answer.
Best Regards,
George
sdancer75
|
|
|
|
|
Hi
I have a tiff viewer that uses tiff library to show tiff files.
Program works fine, but I have problem to show the first frame of this file:
http://www.LogicSims.ir/download/Sample1.tiff[^]
I tested CxImage, it has same problem.
Problem is : this file have uses an Old style JPEG compression, but there must be a way to show it.
If you know a library or a way to show this file please tell me.
Regards
www.logicsims.ir
|
|
|
|
|
Hadi Dayvary wrote: there must be a way to show it
sadly, there is no "must" about this. the reason the "old-style" JPEG-in-TIFF is "old" is that the original JPEG-in-TIFF specification was ambiguous about certain key aspects of the sub-format and so everyone interpreted the spec differently, leading to an uncountable number of mutually-incompatible variations. the new JPG-in-TIFF spec fixes the problem.
the latest version of LibTiff tries very hard to deal with as many of these variations as it can, but it still doesn't have them all. if the current LibTiff doesn't handle it, you can try finding out who wrote the software that created the file and see if they have a reader available.
modified 10-Nov-11 14:37pm.
|
|
|
|
|
Thanks a lot for your your reply.
The problem is that they need to see those kind of images (thousond documents) in this application, so I must find a library that support this old style.
Do you know a library that can help me?
Does your imgsource support this old style?
Regards
www.logicsims.ir
|
|
|
|