|
Woaw, that's very bad code 
First, you allocate a buffer of 22 characters and tries to assign 22 characters in it (you didn't take into consideration the terminating zero).
BUT, you in fact don't copy the string into your buffer. You simply just assign a pointer into wFile (your string is in fact a pointer). Later you try to delete this pointer, which of course will fail because your string was not allocated on the heap (not allocated with new).
So, two things to take into consideration:
1) Always make your buffer 1 place larger to be able to store the null-terminating zero
2) Use strcpy whenever you want to copy a string. This will copy the contents of your string and not simply make a pointer assignement.
|
|
|
|
|
strlen is expecting a null terminated string, your new statement allocates 22 entries, your assignment fills all 22 places with non null data, I think you have to make the first line something like char[23] enough space to include the terminating null character.
|
|
|
|
|
iayd wrote: wFile = "010B000304140601000000";
The above line is a mistake. You should do
char *wFile = new char[23];
strcpy(wFile, "010B000304140601000000");
BTW even correct, the above code is wasteful, using a two lines you can do all the stuff:
const char * pStr = "010B000304140601000000";
WriteFile(HD,(LPVOID) pStr , strlen(pStr),&Bytes,NULL);
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
modified on Friday, May 16, 2008 10:49 AM
|
|
|
|
|
iayd wrote: char *wFile = new char[22];
wFile points to an address that can hold 22 characters.
iayd wrote: wFile = "010B000304140601000000";
You've now assigned wFile to a different address.
iayd wrote: delete[] wFile;
delete is expecting to delete from the address returned from new, but will fail because wFile points someplace else.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
|
Hi,
I have a wierd problem that I hope someone here can help me out with. And if I posted in the wrong forum please redirect me.
Anyway, I have a program where I load a Dll, which then loads a bunch of other dlls. I recently did some changes so that the program would support unicode. After the changes I got these wierd problems:
One of the dlls causes a debug assertion failed when loading from it's resource, and another doesn't. They both use the following code:
HRESULT CPictureWnd::LoadResource(WORD wId, LANGID wLangId) {
LPCTSTR sTemplateName = MAKEINTRESOURCE(wId);
HINSTANCE hInst = AfxFindResourceHandle(sTemplateName, _T("GIF_IMAGE"));
HRSRC hResInfo = ::FindResourceEx(hInst, _T("GIF_IMAGE"), sTemplateName, wLangId);
if (!hResInfo) hResInfo = ::FindResourceEx(hInst, _T("GIF_IMAGE"), sTemplateName, 0x409);
...(other code)
return hr;
}
The Dll that manages to call the function uses this code:
CTM_MODULE_API BOOL module_mtype_init(LPMODULE_MTYPE_DATA mtype)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
mtype->pUserData = (_MODULE_MTYPE_USER_DATA*)calloc(sizeof(_MODULE_MTYPE_USER_DATA),1);
mtype->pUserData->m_picIcon = new CPictureWnd;
mtype->pUserData->m_picIcon->LoadResource(IDB_PATHICON,mtype->langId);
return TRUE;
}
And the one who gets the assertion uses this:
CTM_MODULE_API BOOL module_mtype_init(LPMODULE_MTYPE_DATA mtype)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
mtype->pUserData = (_MODULE_MTYPE_USER_DATA*)calloc(sizeof(_MODULE_MTYPE_USER_DATA),1);
mtype->pUserData->m_picIcon = new CPictureWnd;
mtype->pUserData->m_picIcon->LoadResource(IDB_PATHICON,mtype->langId);
return TRUE;
}
I get the debug assertion failes at the following row:
HINSTANCE hInst = AfxFindResourceHandle(sTemplateName, _T("GIF_IMAGE"));
I also get an assertion failure in my dll which loads the other dlls in the following code:
Cctm::Cctm(void)
:m_lock("Cctm::lock")
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
m_initialized=FALSE;
...other code
CString sFile;
GetModuleFileName(AfxGetResourceHandle(), sFile.GetBuffer(_MAX_PATH + 1), _MAX_PATH);
...other code
}
The last row causes an assertion. If I comment out AFX_MANAGE_STATE(AfxGetStaticModuleState()); things seems to work better, but then it fetches texts from the wrong resource files and I got some wierd krasch.
All this worked before I switched to Unicode. Anyone have any idea of whats going on? I really need to get this stuff to work and I don't understand why it doesn't.
Environment: VS 2003, C++, XP Pro, MFC in shared dll to the program and all the dlls.
|
|
|
|
|
Is it possible one or more pieces might have been missed in the UNICODE conversion?
Another issue might be string sizes, possibly in your _MODULE_MTYPE_USER_DATA structure. If one of the DLL's has that structure with _TCHAR arrays for strings, and the other has char arrays, that would make the structures different sizes, causing all sorts of Bad Things to happen due to buffer overruns.
Did you redeclare your strings as arrays of _TCHAR's, or do you use CString's everywhere?
|
|
|
|
|
It's possible that I missed to redeclare some of the chars to TCHARs and messed up the sizing. Thanks for the tip, I'll have to check on that. But I don't understand why the GetModuleFileName casues an assetion when AFX_MANAGE_STATE(AfxGetStaticModuleState()) is used. As far as I can see that error shouldn't depend on any TCHAR/char mismatch.
Cctm::Cctm(void)
:m_lock("Cctm::lock")
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
m_initialized=FALSE;
m_session=NULL;
m_sModuleStatus[0]=0;
m_iApprovedModuleStatus = 0;
m_sActivityStatus[0]=0;
m_iApprovedActivityStatus = 0;
m_showCode=TRUE;
m_moduleTypes=NULL;
m_usedDisplayMasks=0;
m_dbinfo=NULL;
std_functions_init();
HINSTANCE l = afxCurrentResourceHandle;
CString sFile;
GetModuleFileName(AfxGetResourceHandle(), sFile.GetBuffer(_MAX_PATH + 1), _MAX_PATH);
Or could it have something to do with the sFile.GetBuffer(_MAX_PATH + 1)? Could that cause some wierd behaviout now when it's unicode?
|
|
|
|
|
The other possibility is the AfxGetResourceHandle() call. Have you tried stepping into the method with the debugger?
|
|
|
|
|
I tried to do that, I have a vague memory that I've managed to that before, but now the debugger couldn't find any source code, so I had to go to disassembly. Anyway, I managed to figure out that it uses afxCurrentResourceHandle, and when I use it in my code it return null, and thats probably why AfxGetResourceHandle() causes assrt failure.
Isn't AFX_MANAGE_STATE(AfxGetStaticModuleState()) supposed to set me to the right resource?
Do you know how can I get the handle to be a valid handle to my dll?
|
|
|
|
|
It sounds like one or more of your DLL's are release compiles. In order for you to debug into them, they all need to be debug builds.
|
|
|
|
|
hmm...no, my Dlls are debug builds, but in that case it seems like the debugger can't find the MFC debug dlls where GetModuleFileName and AfxGetResourceHandle() is. Is there some sort of wierd switch? except for _DEBUG?
|
|
|
|
|
finally found something.
Seems like this code is causing the assertion:
_AFXWIN_INLINE HINSTANCE AFXAPI AfxGetResourceHandle()
{ ASSERT(afxCurrentResourceHandle != NULL);
return afxCurrentResourceHandle; }
Seems like afxCurrentResourceHandle haven't been properly set. I thought that was what AFX_MANAGE_STATE(AfxGetStaticModuleState()) was doing. You wouldn't happen to know any reason why it would fail?
|
|
|
|
|
Not off hand, I'm afraid.
If you are creating MFC extension DLL's, then that might be a problem. Try looking that up on MSDN.
|
|
|
|
|
Slolved it. It was a stupid lib file I used that had to be unicode compiled as well. Didn't notice it because the compiler didn't complain.
Thanks for your help.
|
|
|
|
|
I had problem in migrating from VC6 to VC2005
typedef _A::size_type size_type; works fine in the vc 6 and flashes the below error after migrating to VC 2005
"thirdparty\dinkumpatches\xstring(39) : error C2146: syntax error : missing ';' before identifier 'size_type'"
pls advice
|
|
|
|
|
ptr_Electron wrote: pls advice
My advice is that if you are going to use third party libraries then contact the vendor for support rather than posting messages in a forum.
led mike
|
|
|
|
|
how to do an ordinary operation of disabling an edit controlbox when we chose a radiobutton,iam not able to acess the radiobutton using their variables,how to make the onclick event in radiobuttons,and iam working on visualstudio2005
Raja
|
|
|
|
|
Open the Resource Editor and click the radio button, Visual Studio will write the OnClick code skeleton for you.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
REPOST[^]
what's wrong with the answers you got there ?
|
|
|
|
|
Mohanraj D wrote: how to do an ordinary operation of disabling an edit controlbox...
Why are you reposting?
Use EnableWindow(FALSE).
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I think you asked and I told you m_Edit.EnableWindow(1 or 0); if you have a variable for editbox.
|
|
|
|
|
Hamid. wrote: I think you asked...
I asked nothing. 
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Oh I am agree with you it was a reply to Mohanraj D,sorry. 
|
|
|
|
|
I think you asked and I told you m_Edit.EnableWindow(1 or 0); if you have a variable for editbox,right?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
