C / C++ / MFC

Re: First Chance exception

13-Apr-07 12:39

To go to C# would be a rewrite - different framework, different language.

C++/CLI is the only language that allows you to mix unmanaged code with managed code.
While this is powerful, it also adds to the complexity. Going back and forth between managed and
unmanaged code is tricky at first - there's a learning curve there.

If you want to hold on to your MFC-based codebase, and still take advantage of the rich .NET
framework, then C++/CLI is the only way to go. From my experience this works well.

My 2 cents.
Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

First Chance exception

namratab13-Apr-07 11:10

namratab

13-Apr-07 11:10

Hello,
I have a dialog with edit fields. and i store the data entered into them into MS SQL. Now, for data validation for CString fields, I use simple tes like
If(str=="")
{
Messagebox(something);

}
but for integer fields, VC++ 6.o automatically gives a message "please enter an integer" ,if the integer field is left blank . I get a first chance exception "0xE06D7363: Microsoft C++ Exception." and a messageBox "Please enter an integer." I guess that is because when I call UpdateData(true), there is no value for DoDataExchange. But Is there any way of disabling this message and allow me to display my own message as my application starts behaving unexpectedly after it encounters this exception. Also Could you tell me how to catch this exception thrown because of UpdateData. I could not catch it with normal CExeption * e.
Please help.

bob1697214-Apr-07 7:55

bob16972

14-Apr-07 7:55

CException only covers MFC exceptions.

If your exception is a C++ exception, you should catch the appropriate exception class or type.

If your unsure what exception class or type could be "thrown" in a particular context, then it would be advisable to research "exception handling" in MSDN as their are different types that you should get familiar with.

If you are in a hurry, you can catch "(...)" which will get just about anything, but this will possibly be frowned upon by some in the community since you basically lose the exception context and basically defeat the exception mechanism. Using "(...)" essentially turns exception handling into an overpriced "goto". To be fair, there are likely some in the community that feel "(...)" is ok to use and even handy. I find myself sitting on the fence with this one.

If the exceptional condition is avoidable, it might be better to locate where it's getting thrown, and prevent the condition in the first place. It just depends on the exception context since some exceptions are, by design, unavoidable, real world, common occurences like file and database exceptions. Some just shouldn't happen like divide by zero and memory access violations These usually indicate flawed logic and should be removed/rethought/redesigned instead of wrapping in a try/catch.

Thats just my 2 cents.

Destructor Not Getting Called

CoffeeAddict1913-Apr-07 11:09

CoffeeAddict19

13-Apr-07 11:09

I'm having a problem with a class I wrote- the destructor isn't being called for some reason and I'm getting a rather large memory leak as a result. I verified that the destructor was not being called through the use of breakpoints. Any help would be appreciated.

Here is the class defenition:

class CCharLinkedList
{
public:
	CCharLinkedList();
	~CCharLinkedList();
	void AddNodeToHead(char DataToAdd[]);
	void AddNodeToTail(char DataToAdd[]);
	bool DeleteFromHead();
	bool DeleteFromTail();
	bool CopyFromHead(char DataToCopy[]);
	bool CopyFromTail(char DataToCopy[]);
	void PrintHeadToTail();
	void PrintTailToHead();
protected:
private:
	void DeleteList();
	CharLinkedListNodeType* HeadPtr;
	CharLinkedListNodeType* TailPtr;
};

The destructor implementation:

CCharLinkedList::~CCharLinkedList()
{

	DeleteList();
	HeadPtr = NULL;
	TailPtr = NULL;
}

DeleteList():

void CCharLinkedList::DeleteList()
{
	CharLinkedListNodeType* IterationPtr = HeadPtr;
	CharLinkedListNodeType* DeletePtr = NULL;

	while(IterationPtr != NULL)
	{

		DeletePtr = IterationPtr;
		IterationPtr = IterationPtr->ForwardPtr;
		delete DeletePtr;
	}
}

The class is declared in the free store in another class header file. The other class has been working fine for a long time. So far I have been able to use the linked list to add nodes, but when it is time to call the destructor upon exiting and delete all the nodes, nothing happens.

Mark Salsbery13-Apr-07 11:23

13-Apr-07 11:23

You've shown the code for the class but it's irrelevent to the problem.

What's important is the creation and destruction of the CCharLinkedList object(s).
Are they created/destroyed with new/delete?
Are they member variables in another class? If so, when does the object of THAT class get deleted
or go out of scope?
etc...

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

CoffeeAddict1913-Apr-07 11:32

CoffeeAddict19

13-Apr-07 11:32

I only have one CCharLinkedList object. It is allocated on the free store (not new/delete), here:

class CRatiosWin : public CFrameWnd
{
public:
	CRatiosWin(); //default constructor
	~CRatiosWin(); //destructor
	CRatiosLogic RatiosLogic;
	bool GetNewFilePath(CString & Path);
	void PrintResults(string results);
	//accessor functions
	bool ReturnValidFilePathSet();
	//manipulator functions
	void ResetSearchDialogFlag(); //set that the search dialog has not been opened
	void SetDatabaseFilePathStatus(bool FilePathWasSet);
	void SetTimeParameterStatus(bool NewTimeParametersWereSet);
protected:
private:
	//classes
	CRatiosNewSearchDialog NewSearchDialog;
	CRatiosSearchTimeParameters TimeParametersDialog;
	CCharLinkedList TestLinkedList; :(
	//other private members
	CEdit ResultsBox;
	BOOL NewSearchDialogIsVisible; //if TRUE, the NewSearchDialog is active
	bool ValidFilePathSet;
	bool TimeParametersWereSet;
	afx_msg void OnClose();
	afx_msg void OnOpenFile();
	afx_msg void OnNewSearch();
	afx_msg void OnOpenSearch();
	afx_msg void OnAbout();
	afx_msg void OnTestList();
DECLARE_MESSAGE_MAP()
};

I loaded some text into the list by calling this at runtime:

afx_msg void CRatiosWin::OnTestList()
{
	fstream ListFileStream;
	char chLine[MAXNUMCHARS_LINKLISTNODE];
	string strLine = "";

	ListFileStream.open("list_test.txt");
	while(ListFileStream.eof() == false)
	{
		getline(ListFileStream, strLine);
		ASSERT(strLine.length() < MAXNUMCHARS_LINKLISTNODE);
		strcpy(chLine, strLine.c_str());
		TestLinkedList.AddNodeToTail(chLine);
	}
	MessageBox("Sent to file.", "Boink", MB_OK);
	ListFileStream.close();
}

All of the above worked fine. But I set breakpoints in the destructor in the previous post and none of them were reached, plus I have a big memory leak.

Mark Salsbery13-Apr-07 11:36

13-Apr-07 11:36

Cool thanks. In that case you need to look at when the CRatiosWin object is destroyed.
It is then that the CCharLinkedList member object will be destroyed.

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

CoffeeAddict1913-Apr-07 11:48

CoffeeAddict19

13-Apr-07 11:48

Can I assume that CRatiosWin is not getting deleted in this segment of code?

class CPRatiosApp : public CWinApp
{
	public:
	BOOL InitInstance()
	{
		_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
		m_pMainWnd = new CRatiosWin;
		m_pMainWnd->ShowWindow(m_nCmdShow);
		m_pMainWnd->UpdateWindow();
		m_pMainWnd->SetWindowText("Ratios v0.1b");
		m_pMainWnd->MoveWindow(0,0,800,600);
	return TRUE;
	}
} CRatiosApp;

Mark Salsbery13-Apr-07 12:10

13-Apr-07 12:10

CoffeeAddict19 wrote:
Can I assume that CRatiosWin is not getting deleted in this segment of code?

Yes...correct.

I can't find where m_pMainWnd is destroyed in the MFC source...When I find it I'll post. Roll eyes | :rolleyes:

Try adding this override to your CPRatiosApp class:

virtual int ExitInstance()
{
   if (m_pMainWnd)
   {
      m_pMainWnd->DestroyWindow();
      m_pMainWnd = 0;
   }
 
   return CWinApp::ExitInstance();
}

Your destructor should be called when the m_pMainWnd->DestroyWindow(); is executed.

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Mark Salsbery13-Apr-07 12:33

13-Apr-07 12:33

Ok....after reviewing MFC source -

Your destructors should get called when you close the main window (since frame windows are self-
deleting). I found no place where the app classes destroy the main window explicitly.

The ExitInstance() code I posted won't help. You'll need to close the main window before a
breakpoint in your destuctor will be called Smile | :)

Mark

"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

LogOff User from a Service running as System

John R. Shaw14-Apr-07 15:57

John R. Shaw

14-Apr-07 15:57

When I learned to program we had to write stuff like this – why are you? You should be using the ‘list’ template.

Some of the modern MS languages allow you to ignore the fact that if you use ‘new’ you need to supply a ‘delete’, may be that is the problem. Any thing you allocate you need to deallocate – even in C++.

INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra

Gurkenscheibe13-Apr-07 10:44

Gurkenscheibe

13-Apr-07 10:44

Hello you wise people out there,

how can I log off a user on Windows NT, XP, Vista platform from a Windows Service?

Do I have to impersonate the user and send a certain message or can I use ExitWindowsEx(0,0)? Which privileges does the Service need?

Thanks for your help

I'm just a beginner longing for wisdom

which one is parent?

iayd13-Apr-07 9:02

iayd

13-Apr-07 9:02

Hi I have 3 dailog boxes(Dlg1,Dlg2,Dlg3) which create a fourth dialog box which is called ChildDlg.How can I understand which one is the parent of the ChildDlg? I tried that;
ChildDlg::Something()
{
Dlg1 *dlg = (Dlg1*)GetParent();
if(Dlg1 is not the parent)
{
delete dlg;
Dlg2 *dlg = (Dlg2*)GetParent();
if(Dlg2 is not the parent)
{
Delete dlg;
Dlg3 *dlg = (Dlg3*)GetParent();
}
}
(After that part of the code I am using dlg as the object of the parent.)
)
I have many methods like this method which I should know which one is the parent.Where is the mistake in this method.It doesn't work.I know I asked a question similar to this one but still I have problems about that subject.
Thanks

Wes Aday13-Apr-07 9:54

Wes Aday

13-Apr-07 9:54

Exactly what is it that you are trying to do?

Why is common sense not common?

Never argue with an idiot. They will drag you down to their level where they are an expert.

Sometimes it takes a lot of work to be lazy

Maximilien13-Apr-07 9:56

Maximilien

13-Apr-07 9:56

why don't you just pass the parent pointer to the ChildDlg when it's created and check the GetParent against that pointer ?

Maximilien Lincourt
Your Head A Splode - Strong Bad

CPallini13-Apr-07 10:10

CPallini

13-Apr-07 10:10

Maximilien wrote:
why don't you just pass the parent pointer to the ChildDlg when it's created and check the GetParent against that pointer ?

I think that, stated the way above, you're check will always return true.
Smile | :)

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.

CPallini13-Apr-07 10:06

CPallini

13-Apr-07 10:06

You can make the three candidate parents to implement the same interface (pure abstract class) that defines a method returning some type info. For instance, Suppose you define IMyTypeInfo:

class IMyTypeInfo 
{
public:
  virtual int getType()=0;
}

then you can do something similar to:

class Dlg1 : public CDialog, public IMyTypeInfo
{
public:
 virtual int getType(){return 1;}
...
}

class Dlg2 : public CDialog, public IMyTypeInfo
{
public:
 virtual int getType(){return 2;}
...
}

class Dlg3 : public CDialog, public IMyTypeInfo
{
public:
 virtual int getType(){return 3;}
...
}

finally, you child dialog, can safely do the following cast:

int iType = ((IMyTypeInfo *)GetParent())->getType();

and retrieve parent's type.

(you can also go through RTTI...)

hope that helps.

Smile | :)

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.

bob1697213-Apr-07 10:10

bob16972

13-Apr-07 10:10

Be careful if these dialogs are modeless. What GetParent() and GetWindow() report differs depending on the dialog style (i.e. popup, overlapped, or child)

Be aware of the differences of parent and owner depending on these styles.

Window Owners and Parents
[^]

JudyL_MD13-Apr-07 10:14

JudyL_MD

13-Apr-07 10:14

This example is MFC

In each parent, create the child like:
CChildDlg childDlg (this)
This will pass the parent CWnd to the child and the standard MFC implementation will store the CWnd pointer.

In the child, when something occurs that has to be sent back to the parent, simply do:
GetParent ()->PostMessage (build whatever message and parameters you need)

If the child really cares about _which_ parent called him, modify the child's constructor to include another parameter and pass in an indicator that the child can store in its member variables that shows who created the child.
CChildDlg childDlg (this, flag_value)
Now, in the child, when you want to call into a specific parent, cast the parent CWnd pointer to the appropriate parent class based on the flag

if (flag_value == parent_1)<br />
{<br />
Dlg1 *pDlg = (Dlg1 *) GetParent ();<br />
// use pDlg<br />
}<br />
else if (flag_value == parent_2)<br />
{<br />
Dlg2 *pDlg = (Dlg2 *) GetParent ();<br />
// use pDlg<br />
}<br />
else<br />
// you get the idea

You need to be careful when you call back into another window class that you don't do things that may cause your window to redraw. In general, it is much better to post a windows message than it is to call directly when communicating between windows.

Judy