C / C++ / MFC

Difference between _stat() and _fstat()

18-Jan-11 14:07

This is a good indication that your error handling isn't very good.

Make sure you are checking the return value of all functions that you call in CSerial.
I dont know of any virtual COM ports, but a good place to start would be google[^].

gomathylakshmanan17-Jan-11 19:47

gomathylakshmanan

17-Jan-11 19:47

Hi All,

Both _stat() and _fstat() are used to obtain the opened file information._stat() does not require FileDescriptor whereas _fstat() needs FileDescriptor to obtain the file Info.

Is any other differences between these?In what scenario these can be used?

Can any one clarify my doubt?

Thanx.

Re: Difference between _stat() and _fstat()

Andrew Brock17-Jan-11 19:53

CTypedPtrArray & CStringArray

17-Jan-11 19:53

Reffer to MSDN for function documentation.

_stat[^]
_fstat[^]

_fstat gets information based on a file descriptor (acquired with _open or fopen)
_stat gets information based on a file path

mesajflaviu17-Jan-11 9:10

17-Jan-11 9:10

Can you tell me if I use in corect way these classes , CTypedPtrArray & CStringArray ?

These are member variable to CMyDoc class :

typedef CTypedPtrArray<CObArray,CStringArray*> CTableArray;

class CMyDoc : public CDocument
{
// Attributes
public:
	CStringArray m_saTable;
	CTableArray m_saTables;
...
}

and here is code snipped for use of them :

m_saTable.Add("String Test");
m_saTables.Add(&m_saTable);
CStringArray* saTest = m_saTables.GetAt(0);
CString sTest = saTest->GetAt(0);
TRACE("\n %s \n",sTest);

but , where I need to delete elements ?
I try to delete items in OnCloseDocument(...)

void CMyDoc::OnCloseDocument() 
{
	// TODO: Add your specialized code here and/or call the base class

	m_saTable.RemoveAll();
	m_saTables.RemoveAll();
	TRACE("\n %d - %d \n",m_saTable.GetSize(),m_saTables.GetSize());

	CDocument::OnCloseDocument();
}

But with or without remove code , I didn't have memory leaks in debug window ... is really necesary to delete the items ?
Any help , I will appreciated ! Thanks !

Chris Meech17-Jan-11 10:01

Chris Meech

17-Jan-11 10:01

Just one point to offer. Having two member variables named so similarly is likely going to lead to confusion at some later point. Try to come up with names that are more meaningful to the actual use of the data. For example if the strings in the string array class are all people names, cities of the world or street names, try to use that instead of m_saTable. Similarly with the member m_saTables. Just a suggestion. Smile | :)

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]

mesajflaviu17-Jan-11 19:06

17-Jan-11 19:06

Thanks for the suggestion , I will fix that .

Andrew Brock17-Jan-11 16:04

17-Jan-11 16:04

Firstly, make sure you are dumping the memory leaks correctly. There are a number of ways to do this, but the best is by adding

#if defined(DEBUG) || defined(_DEBUG)
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
#endif

as early in your code as possible, in your case it will be the constructor of your App object BOOL CxxxApp::CxxxApp()
This is the only way will dump the memory leaks after all static objects have been destroyed. All other ways that I know of will give misleading results if you have static objects

If no destructor is provided for your class 1 is generated which calls the destructors of all member classes, otherwise the destructors of all member classes is called after your destructor code.
In destructors you only need to delete memory allocated by new, malloc or the likes.

Either way, your code is calling the destructors to m_saTable and m_saTables and these destructors will free any memory associated with it.

Having said that, your CTableArray is storing pointers, which means that the destructor for the table will only free the pointers, and not the actual data.
You will need to enumerate each item and free its memory manually. CMyDoc::OnCloseDocument() would be a good place to do this.

INT_PTR nElements = m_saTables.GetCount();
for (int nIndex = 0; nIndex < nElements; ++nIndex) {
	delete m_saTables.GetAt(nIndex); //assuming the elements inserted were created with "new CStringArray"
}

mesajflaviu17-Jan-11 19:38

17-Jan-11 19:38

At this code :

#if defined(DEBUG) || defined(_DEBUG)
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
#endif

give me the follow error :

error C2501: '_CrtSetDbgFlag' : missing storage-class or type specifiers

Because I use VC6 ?

Andrew Brock17-Jan-11 19:51

17-Jan-11 19:51

Possibly.
Try #include <crtdbg.h> and see if that fixes the problem, otherwise try _CrtDumpMemoryLeaks(); as the last statement in the App destructor CxxxApp::~CxxxApp()

I havn't used VC 6 in a many years, and it may not have these debugging functions. MSDN only has version 7.1 (2003) onwards.

If I might make a suggestion, it might be an idea to upgrade.
VC++ 7.1 (2003) is the latest version to support Windows 95, VC++ 8.0 (2005) is the latest version to support Windows 98/ME, VC++ 9.0 (2008) and 10.0 (2010) support Windows 2000 onwards.
Unless you are wanting to support these older platforms I would suggest upgrading to at least VS 2008 Express. It is a free download from the Microsoft website with a Windows Live ID.

mesajflaviu17-Jan-11 22:11

17-Jan-11 22:11

I don't know if is corect , but I think that I solve it :

//    CMyDoc.h
typedef CTypedPtrArray<CObArray,CStringArray*> CDumpArray;
class CMyDoc : public CDocument
{
protected: // create from serialization only
	CMyDoc();
	DECLARE_DYNCREATE(CMyDoc)

// Attributes
public:
	CDumpArray m_arrDump;
...
};

//    CMyDoc.cpp
	CString sText = "one";
	CStringArray* pTable = NULL;
	pTable = new CStringArray();
	pTable->Add(sText);
	sText = "two";
	pTable->Add(sText);

	m_arrDump.Add(pTable);

	pTable = new CStringArray();
	sText = "three";
	pTable->Add(sText);
	sText = "four";
	pTable->Add(sText);

	m_arrDump.Add(pTable);

void CMyDoc::OnCloseDocument() 
{
	// TODO: Add your specialized code here and/or call the base class

	TRACE("\n m_arrDump %d \n",m_arrDump.GetSize());

	CString sTemp;
	for(int n = 0;n < m_arrDump.GetSize();++n)
	{
		TRACE("\n StringArray no %d \n",n);
		CStringArray* pTable = m_arrDump.GetAt(n);
		for(int t = 0;t < pTable->GetSize();++t)
		{
			sTemp = pTable->GetAt(t);
			TRACE("\n %s \n",sTemp);
		}
	}
	int nCount = m_arrDump.GetSize();
	for(int i = 0;i < nCount;++i)delete m_arrDump.GetAt(i);
	m_arrDump.RemoveAll();

	TRACE("\n m_arrDump %d \n",m_arrDump.GetSize());

	CDocument::OnCloseDocument();
}

Andrew Brock17-Jan-11 22:36

17-Jan-11 22:36

I cant see anything wrong with this, however a better solution for CMyDoc::OnCloseDocument() would be

void CMyDoc::OnCloseDocument() 
{
	// TODO: Add your specialized code here and/or call the base class

	TRACE("\n m_arrDump %d \n",m_arrDump.GetSize());

	CString sTemp;
	int nCount = m_arrDump.GetSize();
	for(int n = 0;n < nCount; ++n)
	{
		TRACE("\n StringArray no %d \n",n);
		CStringArray* pTable = m_arrDump.GetAt(n);
		for(int t = 0;t < pTable->GetSize();++t)
		{
			sTemp = pTable->GetAt(t);
			TRACE("\n %s \n",sTemp);
		}
		delete pTable; //You can delete these here for better code locality. You are only deleting the memory associated with them, not the item from the array.
	}
	//You dont need this next call unless you plan on reusing THIS instance of CMyDoc (which you shouldn't). CMyDoc::~CMyDoc() will clean it all up
	m_arrDump.RemoveAll(); //Remove all the (now invalid) items from the array

	CDocument::OnCloseDocument();
}

mesajflaviu18-Jan-11 1:47

Display dialog after SDI app opens

18-Jan-11 1:47

Thanks , works fine ! Thank you all !!!

David Crow17-Jan-11 3:01

David Crow

17-Jan-11 3:01

In my SDI app, I want to display a dialog after the main window is showing (this is to verify the starting path of some file processing). I've set breakpoints in locations like CFrameWnd::OnCreate(), CFrameWnd::PreCreateWindow(), CListView::OnInitialUpdate(), but none of them are hit before the action starts in CDocument::OnNewDocument().

I've seen a few examples of this with the dialog being displayed before the main window is showing, but that's not the look I am after.

Thanks for any help you might have.

- DC

"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

"Man who follows car will be exhausted." - Confucius

Maximilien17-Jan-11 3:30

Maximilien

17-Jan-11 3:30

Have you tried CView::OnActivateFrame ?

Seems to be working on my sample test; you might have to use a bool to guard the code because OnActivateFrame is called often.

Watched code never compiles.

David Crow17-Jan-11 3:39

David Crow

17-Jan-11 3:39

Maximilien wrote:
Have you tried CView::OnActivateFrame ?

CDocument::OnNewDocument() is still hit first.

Andrew Brock17-Jan-11 3:54

17-Jan-11 3:54

The window shows where you have the m_pMainWnd->ShowWindow(SW_SHOW); call in CxxxSDIApp::InitInstance() or during if (!ProcessShellCommand(cmdInfo)) if the program was started with SW_SHOW option (which it is when run from the debugger and the Windows Explorer.

Depending on what you want the dialog to do, you may be able to just make a modeless dialog right there, otherwise you will need to m_pMainWnd->SendMessage() or m_pMainWnd->PostMessage() to tell the main window to open the modal dialog.

SendMessage() will do it right then, whereas PostMessage() will do it some time in the near future.

EDIT: HTML formatting error

David Crow17-Jan-11 8:36

David Crow

17-Jan-11 8:36

Displaying the dialog at the tail end of CWinApp::InitInstance() did the trick. Thanks.

Alain Rist17-Jan-11 5:48

Alain Rist

17-Jan-11 5:48

Hi Dave,

In your main window OnCreate() call PostMessage(WM_COMMAND, ID_SHOWDIALOG) - and handle the command Smile | :)

.

The message will be queued and processed after full completion of the creation process.

cheers,
AR

When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)