On Debug Mode. After I make a call to Save Dialog and save the information from the edit boxes and then close the window I get an assertion error.
Printable View
On Debug Mode. After I make a call to Save Dialog and save the information from the edit boxes and then close the window I get an assertion error.
I can assure you that to the best of my knowledge there's no virus, check for viruses first though.
Code://we incremente iCount to accomodate for the NULL character
//OK, so why don't you increment it then, having said you would?
NameOfFile=new char [iCount];
// now you lie about the size of the allocated memory
GetWindowText(NameEditBoxHwnd,NameOfFile,iCount+1);
// what is the point of this?
// you allocate it here, you pass it to another function below
// then you free it
FileToSave= new char [iCount+1];
OpenFileName.hwndOwner = NULL;
OpenFileName.lpstrFile = NameOfFile;
OpenFileName.lpstrFileTitle =FileToSave;
> I get an assertion error.
In the memory manager no doubt, judging from the number of places where you try and put n+1 bytes into an n-byte buffer.
Thanks I'll look into it.....I see that I increment icount after a call to GetWindowsText
GetWindowText(NameEditBoxHwnd,NameOfFile,iCount+1) ;
FileToSave= new char [iCount+1];
The problem might lie there............thanks
PS. I really didn't know computers were so picky about pointers in memory.
I think I found the problem...
Code:
NameEditBoxHwnd=GetDlgItem(DialogHandle, IDC_NOMBRE);
iCount=GetWindowTextLength(NameEditBoxHwnd);
//we incremente iCount to accomodate for the NULL character
NameOfFile=new char [iCount];
I am only allocating enough space on NameOfFile to fit the Name of the Client, but when GetSaveFileName (&OpenFileName) returns after I filled part of the structure like so.
OpenFileName.lpstrFile =NameOfFile;
After the function returns NameOFile will contain.......
"Pointer to a buffer that contains a filename used to initialize the File Name edit control. The first character of this buffer must be NULL if initialization is not necessary. When the GetOpenFileName or GetSaveFileName function returns successfully, this buffer contains the drive designator, path, filename, and extension of the selected file. "
So basically I just needed a bigger buffer. Thank you.
So now I changed.......
NameOfFile=new char [iCount];
to
NameOfFile=new char[150];
Thus allocating a bigger buffer
Perhaps it would be better or at least safer to useQuote:
Originally posted by incognito
So now I changed.......
NameOfFile=new char [iCount];
to
NameOfFile=new char[150];
Thus allocating a bigger buffer
instead because MAX_PATH defines the maximum chars a path can have (260). it's defined in windef.hCode:NameOfFile=new char [MAX_PATH];
Yeah very true.
> NameOfFile=new char [MAX_PATH];
There's not a lot of point using new to allocate space with a known length at compile time.
char NameOfFile[MAX_PATH];
makes life so much simpler.
Also very true....I wasn't thinking about the extra things that were going to be added to the buffer when I was coding it, that's why I put it like that, you're right I will change it.