|
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
|
|
|
|
|
Hadi Dayvary wrote: Does your imgsource support this old style?
ImgSource uses LibTiff.
i think LibTiff is going to be your best bet. there is nothing that will support all of the variations, but the LibTiff people have been good about adding support as they figure out how each variation works.
|
|
|
|
|
Thank you.
www.logicsims.ir
|
|
|
|
|
Here is a snippet of some documentation I found about this
"
The default implementation performs accelerator-key translation, so you must call the CWinApp::PreTranslateMessage member function in your overridden version.
"
I am intercepting ( in MFC main frame) a user message (WM_ xxx) to initialize my application multiple views and the message gets interpreted by the PreTranslateMessage twice due to the call to
return CMDIFrameWnd::PreTranslateMessage(pMsg);
as implemented by MFC.
I "fixed" it by setting a pass flag so it does not get processed twice.
I am not looking forward to do this for every message I will post to the main frame.
Is that OK?
Thanks for your comments.
Vaclav
|
|
|
|
|
Hi,
I have a use case to validate an path that is given as an input to my application.
I tried to create a file in the path with fopen and added the following check :
FILE *fp= fopen(Input path, "w");
if( fp == NULL)
{
//Invalid path
}
else
{
//Valid path
}
This works well for cases when the input path is invalid or not present.
But in certain cases, when UAC is enabled, a file cannot be created in the C:\Program files location. So in that scenario, if my input path is C:\Program files, fopen doesnt return any error and above code executes the else part, which is wrong.
Can anyone please provide suggestions about this issue?
Sindhu
|
|
|
|
|
How about using PathIsDirectory[^]?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Thanks. But PathIsDirectory() might not tell me if the user has write access to that path right?
|
|
|
|
|
Ah, you didn't mention that, or i missed it, in which case, sorry. Read this[^], maybe you are hitting the same thing.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
sindhumahe wrote: if my input path is C:\Program files, fopen doesnt return any error and above code executes the else part, which is wrong.
Just for grins, have you tried using fp in the else part?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Perhaps you are simplifying your code example, but the condition of fp == NULL could be true for many more reasons than just invalid path. You might want to make a call to GetLastError[^]. The returned error number will allow you to detect all manor of error conditions. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Chris Meech wrote: You might want to make a call to GetLastError[^].
Does fopen() call SetLastError()? I would have thought it would use errno instead.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Good point. I've become so used to calling GetLastError to solve things, but you may be correct that errno could be checked instead. 
[EDIT]
And now that I've checked fopen[^] in MSDN, it does set errno. :slaps head: 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
