|
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++
|
|
|
|
|
|
|
|
You are missing the point of the post. The problem is that if you ever catch that exception, you should never try to handle it in the way that the snippet demonstrates.
There are only two reasons to get that exception (ignore the fact that some developers call AfxThrowMemoryException() for the wrong reasons): [1] A heap request cannot be allocated due to an out of memory condition, and [2] the heap is corrupted and Thinks it is out of memory .
For either case, you probably should not be then trying to allocate memory again.
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!)
|
|
|
|
|
Well, sometime happens. Making confusion between heap and stack, we are in a hurry calling others "stupid" then abort (call AfxAbort).
Ovidiu Cucu
Microsoft MVP - Visual C++
|
|
|
|
|
Of course I do...
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 can just see a developer, patting himself on the back with having put together an exception handler and then stress testing to see it invoked and wondering why the messagebox is never displayed.
This is a really good example of not seeing the forest for the trees solution to a problem.
Chris Meech
I am Canadian. [heard in a local bar]
When no one was looking, every single American woman between the ages of 18 and 32 went out and got a tatoo just above their rumpus. [link[^]]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
