|
In case of objects allocated with new operator, the number of items seems to be stored in a word before the pointer:
MyClass * a = new MyClass[10];
__int32 size = *(((__int32*)a) - 1);
This works only when the class contains destructor.
The size does not seem to be stored in such manner for destructor-less objects and for fundamental types. But for this cases, _msize appears to return the size in bytes.
|
|
|
|
|
The short answer, is no. The long answer is that if you know something about the memory, you may be able to. For example, if it is a BSTR you can look 4 bytes before its "handled" address or use SysStringLen(...).
If you know that the memory came from a particular heap (or heap manager), you may be able to crack the heap structures used to maintain memory allocations. You also need to know where the memory came from in order to use functions like _msize(...), _msize_dbg(...), GlobalSize(...), etc.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Here it is:
LPVOID data = MapViewOfFile(m_hMap, _dwDesiredAccess, 0, _dwOffset, _dwNbBytes);
I need to know the size of the data buffer.
I call this code after resizing a map file with 8ko but I can acess only the first 4ko 
could someone help me?!!
|
|
|
|
|
hatemtalbi wrote: I need to know the size of the data buffer.
Isn't that what _dwNbBytes represents?
hatemtalbi wrote: I call this code after resizing a map file with 8ko but I can acess only the first 4ko
What in the world is "ko?"
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
no, _dwNbBytes == 0
ko mean kb == 1024 bytes
thx
|
|
|
|
|
hatemtalbi wrote: no, _dwNbBytes == 0
Then you simply need to look at the size of the file, since the entire file was mapped.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
that s the problem!!! it seems that the size of the file is larger than the memory buffer returned. I don't understand why
|
|
|
|
|
wrote smth like this...
variables:
CTabCtrl m_tabctrl;
CDlg1* dlg1;
CDlg2*dlg2
MyDialog constructors ... :
CDlg1::CDlg1(CWnd* pParent /*=NULL*/)
//: CDialog(CDlg1::IDD, pParent)
{
this->Create(CDlg1::IDD, pParent);
this->ShowWindow(SW_NORMAL);
}
BOOL CMainDlg::OnInitDialog()
{
CDialog::OnInitDialog();
m_tabctrl.InsertItem(0,_T("1111"));
m_tabctrl.InsertItem(1,_T("2222"));
dlg1=new CDlg1(GetDlgItem(IDC_TAB1));
dlg1->ShowWindow(SW_SHOW);// error IsWindow=false
}
|
|
|
|
|
Hope I understood your question
<br />
dlg1=new CDlg1();<br />
dlg1->create(...)<br />
dlg->GetDlgItem(IDC_TAB1)->ShowWindow(SW_SHOW); <br />
whitesky
|
|
|
|
|
did as u say....
CMyDialog *MyDialog;//in MainDlg header file
MyDialog = new CMyDialog; //in mainDlg constructor
CMainDlg::OnInitDialog{
TC_ITEM TabItem;
TabItem.mask = TCIF_TEXT;
TabItem.pszText = _T("111111");
m_tabctrl.InsertItem( 0, &TabItem );
TabItem.mask = TCIF_PARAM;
TabItem.lParam = (LPARAM)MyDialog;
m_tabctrl.SetItem(0, &TabItem);
VERIFY(MyDialog->Create(CMyDialog::IDD, &m_tabctrl));
MyDialog->ShowWindow(SW_SHOW);
}
CMyDialog constructor
CMyDialog::CMyDialog(CWnd* pParent /*=NULL*/)
: CDialog(CMyDialog::IDD, pParent)
{
/*this->Create(CThumbViewDlg::IDD, pParent);
this->ShowWindow(SW_NORMAL);*/
}
error in HWND CDataExchange::PrepareCtrl
if (pSite == NULL)
{
TRACE(traceAppMsg, 0, "Error: no data exchange control with ID 0x%04X.\n", nIDC);
ASSERT(FALSE);
AfxThrowNotSupportedException();//<-------------------------------------|
}
|
|
|
|
|
one question "VERIFY(MyDialog->Create(CMyDialog::IDD, &m_tabctrl));"
your previous code was good this->Create(CThumbViewDlg::IDD, pParent);
this->ShowWindow(SW_NORMAL);
and why you dont use MyDialog->Create();
whitesky
|
|
|
|
|
NoName II wrote: dlg1=new CDlg1(GetDlgItem(IDC_TAB1));
dlg1->ShowWindow(SW_SHOW);// error IsWindow=false
you just allocated the memory.
You may have to create the dialog using CreateDialog or CreateDialogIndirect
SaRath.
"Do Next Thing..."
My Blog | Understanding State Pattern in C++
|
|
|
|
|
I'm not sure whether your purpose for this will allow for it, but you might try using a PropertySheet/PropertyPage setup instead of a tab control. You can configure the PropertySheet to look just like a tab control and don't have to write the transition code yourself.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
|
OK... In a pseudo-bet, I am wondering if the MFC developers out there can see what is wrong with the following catch clause extracted from an example. I am hoping that something obvious pops out of it.
catch( CMemoryException *pExMem )
{
CString csError;
TCHAR caErr[128+1];
pExMem->GetErrorMessage(caErr,128);
csError.Format(_T("An exception has been encountered:\n%s"),caErr);
AfxMessageBox(csError,MB_EXCLAMATION);
pExMem->Delete();
} Hint - it is not about NUL termination.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Either you are trying to delete a stack object or the exception you are throwing might have declared locally.
e.g
try
{
CMemoryException e;
throw &e;
}
or
CMemoryException e;
try
{
throw &e;
}
SaRath.
"Do Next Thing..."
My Blog | Understanding State Pattern in C++
|
|
|
|
|
Well, generally you do not create CException-based objects directly, you are supposed to use the AfxThrow*Exception(...) functions, and CException-based objects are only supposed to be caught by pointer (never by copy or reference), and you are always supposed to call the Delete() function on them unless you are going to re-throw them.
So, no, that is not the problem. 
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
This is only the case if you follow the MFC-style exception usage. When using STL-style exceptions, you generally pass them by const-reference. I probably would have passed this exception by const-reference simply because if you are getting a memory exception, something in your memory is royally screwed (meaning, you shouldn't keep using the heap and expect normal results).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: This is only the case if you follow the MFC-style exception usage.
Yep - That is why I specifically mentioned CException.
Zac Howland wrote: I probably would have passed this exception by const-reference simply because if you are getting a memory exception, something in your memory is royally screwed (meaning, you shouldn't keep using the heap and expect normal results).
Remember that MFC is free to allocate that exception object on another memory area as well, like static and/or global. The special AfxThrow*Exception(...) functions may not just use the "plain" heap to allocate the thrown exception object. And it should always be safe to call Delete() off that pointer (not the delete operator) because the exception object knows if it is heap-based or not.
FWIW, I generally catch other types of exception as const reference as well. You generally do not know what to do with a pointer (should I free it, and if so, how?), and there is that whole "slicing" thing...
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Maybe CMemoryException is too catastrophic error, therefore mentioned actions, which requires heap-allocation, cannot be done? In case of fatal errors, the documentation recommends to finish the application with AfxAbort().
-- modified at 8:48 Monday 26th June, 2006
|
|
|
|
|
Thank you! You would be suprised how often I see code like this, where coders are so stupid that they do not realize that if you are in an out-of-memory situation, you should not be trying to allocate memory! 
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Yeah indeed that can be the exception of exceptions. Theoretical... 
Practical, appear more "trivial" memory exceptions like (I wrote INT_MAX just as an example of big number, but hopefully you can get the point)
try
{
char* x = new char[INT_MAX];
}
and no something like
try
{
char* x = new char[3];
}
catch(CMemoryException* e)
{
}
Ovidiu Cucu
Microsoft MVP - Visual C++
|
|
|
|
|
You forgot to call Delete() on that exception pointer.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
I don't see any harmful error there.
Just MB_EXCLAMATION is not a MessageBox flag and that can be observed/fixed (replaced with MB_ICONEXCLAMATION) after the first compilation.
Don't shoot the typist!
Ovidiu Cucu
Microsoft MVP - Visual C++
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
