C / C++ / MFC

Jochen Arndt4-Apr-13 22:42

4-Apr-13 22:42

Check your CMyApp::OnFileOpen() code and the functions that are called from there. Comment all lines in that function except the base class CWinApp::OnFileOpen() call and uncomment step by step until the violation occurs. Then you should know which part of your code is responsible.

_Flaviu4-Apr-13 23:07

4-Apr-13 23:07

Inside of CMyApp::OnFileOpen I didn't call CWinApp:OnFileOpen .. here is the buggy code:

C++

void CMyApp::OnFileOpen(void)
{
	CFileDialog dlgFile(TRUE);
	dlgFile.DoModal();
	return;
}

and in release mode, the application crashes ...

_Flaviu4-Apr-13 23:26

4-Apr-13 23:26

Even if I used:

C++

void CMyApp::OnFileOpen(void)
{
	CFileDialog dlgFile(TRUE);
	return;
}

and the application is crashing down ...

Jochen Arndt4-Apr-13 23:35

4-Apr-13 23:35

Crashes it in this function or later?

If you did not call CWinApp::OnFileOpen(), no document is created. So the reason for the crash is probably somewhere in your document creation. Did you call OnFileNew() or use ProcessShellCommands() to create a document?

_Flaviu4-Apr-13 23:46

4-Apr-13 23:46

No, I didn't call CWinApp::OnFileOpen, but I call OpenDocumentFile(...), something like that:

C++

void CMyApp::OnFileOpen(void)
{
	CFileDialog dlg(TRUE);
	if(IDOK == dlg.DoModal())
	{
		POSITION pos = dlg.GetStartPosition();
		while(pos)OpenDocumentFile(dlg.GetNextPathName(pos));
	}
	// the document is loaded, I can see the bitmap in child frame ...
	AfxMessageBox("By here, everything it's OK.");
}

after all, I think that the problem it's in another place ... I really don't know ...

And this is weird, because if I open the same file from MRU, everything is OK ...

modified 5-Apr-13 5:54am.

Jochen Arndt5-Apr-13 0:12

5-Apr-13 0:12

It's difficult to find such errors in release versions. Using a message box is a good idea to check where the violation occurs. Because it occurs when not calling OpenDocumentFile(), I assumed that it is somewhere in the document handling (e.g. trying to access non-existing documents).

But when it is OK using ProcessShellCommands() (MRU) D'Oh! | :doh:

At the moment I have only two ideas:

Call OpenDocumentFile() with a fixed file name to see what happens (no other calls from within OnFileOpen()).
Perform a complete rebuild if you have changed something in your project.

_Flaviu5-Apr-13 0:27

5-Apr-13 0:27

This is became strange: if I call only:

C++

OpenDocumentFile(_T("D:\\Flaviu\\SampleImages5\\Test.xxx"));

, everything is OK, but when I go through normal way:

C++

CString strFile;
if (dlgFile.DoModal()==IDOK)
{
    pos=dlgFile.GetStartPosition();
    while (pos!=NULL)
    {
        strFile=dlgFile.GetNextPathName(pos);
        AfxMessageBox(strFile);
        OpenDocumentFile(strFile);
    }
}

is crashing down ... in Release mode only ...
I have to digg in ...

Jochen Arndt5-Apr-13 0:31

5-Apr-13 0:31

So the problematic code is at least isolated even when it looks OK. As next step you may assign the fixed file name to strFile ignoring the selection from the dialog.

_Flaviu5-Apr-13 0:32

5-Apr-13 0:32

Another trial:

C++

CString strFile;
if (dlgFile.DoModal()==IDOK)
{
    pos=dlgFile.GetStartPosition();
    while (pos!=NULL)
    {
        strFile=dlgFile.GetNextPathName(pos);
        AfxMessageBox(strFile);
        OpenDocumentFile(strFile);
    }
}

AfxMessageBox("Second chance");
OpenDocumentFile(_T("D:\\Flaviu\\SampleImages5\\Test.xxx"));
AfxMessageBox("Final ...");

the crashes is occur only after the "final" message box ...

SoMad5-Apr-13 0:51

SoMad

5-Apr-13 0:51

Did you try doing a Rebuild All like Jochen suggested?

Soren Madsen

"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

_Flaviu5-Apr-13 1:24

5-Apr-13 1:24

Of course I did ... something weird is happend ... because if I use only CFileDialog dlgFile(TRUE); in CMyApp::OnFileOpen and the application is crashing down .. I wonder if CFileDialog doesn't have some bug ... Confused | :confused:

SoMad5-Apr-13 10:58

SoMad

5-Apr-13 10:58

Sorry, I did not mean to insult you, but when something really weird is going on, Rebuild All is a good thing to do. I wanted to make sure you had tried that because just last week, I had a weird string related problem that I was trying to chase down. Rebuild All was not my first thought, so I ended up spending at least an hour trying to make sense of it before I finally did the rebuild, which fixed the problem.

Soren Madsen

"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

_Flaviu5-Apr-13 2:18

5-Apr-13 2:18

I found the problem: the destructor of CFileDialog has problems, and I had solved in follow way: I used CFileDialog variable on the heap, just like this:

C++

CFileDialog* pDlgFile = new CFileDialog(TRUE);
// do whatever with pDlgFile ...
delete pDlgFile;

and everything it's OK now ...
I want to kindly thank you all of you for your interest and patience ! Best wishes for you ! Bye.

modified 5-Apr-13 9:12am.

David Crow5-Apr-13 3:14

David Crow

5-Apr-13 3:14

Flaviu2 wrote:
I found the problem...

Moving variables from the stack to the heap is usually not the solution to a problem. You likely just masked it.

"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

"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

Richard MacCutchan5-Apr-13 3:35

Richard MacCutchan

5-Apr-13 3:35

Flaviu2 wrote:
the destructor of CFileDialog has problem

More likely you are referring to a variable that has been destroyed as your dialog has gone out of scope.

Use the best guess

Windows Service Controler & CAsyncSocket

SoMad5-Apr-13 7:39

SoMad

5-Apr-13 7:39

I know you say your modification fixed the crash, but it made me recall a problem that existed in previous versions of Visual Studio: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/55664186-aae7-4ae9-a3e9-e38659335df6[^]

So, I did a few searches and came across this: http://mfctips.com/category/cfiledialog/[^]. I realize it does not appear to be an exact match since yours crashes in Release builds, but one of the comments leads to a Microsoft hotfix, which seemed to solve the problem for several people: http://support.microsoft.com/kb/2718841/en-us[^]

Soren Madsen

"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

Member 33971274-Apr-13 20:43

Member 3397127

4-Apr-13 20:43

i have problem with CAsyncSocket class when i called listen in widows service application.

i successfully create Thread but my listen fuction didn't work correctly.

here my code..

C++

BOOL CMyThread::InitInstance()
{	
	while (!AfxSocketInit());
	MySocket sock;
	while (sock.Create(3005)==SOCKET_ERROR);
	while (sock.Listen()==SOCKET_ERROR);
	HANDLE file;
	file=CreateFile(_T("C:\\initinstance.txt"),GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_NEW,FILE_ATTRIBUTE_NORMAL,NULL);
	CloseHandle(file);
	return TRUE;
}

my application create "initinstance.txt" file successfully but when use commmand "netstat -na" port 3005 not listening..
Frown | :(

where is my mistake?

Jochen Arndt4-Apr-13 22:55

4-Apr-13 22:55

There seems to be no error in the posted code. But the error may be in your MySocket implementation.

You may also delete the file first to ensure that the file has not been created by a previous run.

Member 33971275-Apr-13 1:46

Member 3397127

5-Apr-13 1:46

thanks for answer my question
i change a little my code like this...

C++

BOOL CMyThread::InitInstance()
{

	while (!AfxSocketInit());
	MySocket sock;
	while (sock.Create(3005)==SOCKET_ERROR);
	while (sock.Listen()==SOCKET_ERROR);
	HANDLE file;
	file=CreateFile(_T("C:\\initinstance.txt"),GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_NEW,FILE_ATTRIBUTE_NORMAL,NULL);
	CloseHandle(file);
	 Sleep(30000);
	return TRUE;
}

socket listening for 30 sec with 6 thread
and after 30 sec thread is 5 and socket is close.
so...
and i understand my thread is closed after that..
here is my code for create thread...

C++

CMyThread* pThread =
    (CMyThread*)AfxBeginThread(
    RUNTIME_CLASS(CMyThread),
    THREAD_PRIORITY_NORMAL,
    0,
    CREATE_SUSPENDED);
while(pThread==NULL)
{
    Sleep(1);
    pThread =
        (CMyThread*)AfxBeginThread(
        RUNTIME_CLASS(CMyThread),
        THREAD_PRIORITY_NORMAL,
        0,
        CREATE_SUSPENDED);
}
pThread->ResumeThread();

WaitForSingleObject(pThread->m_hThread,INFINITE);

what do you think? do i have mistake here?
and i'm no sure about calling "WaitForSingleObject(pThread->m_hThread,INFINITE);"

Jochen Arndt5-Apr-13 2:18

5-Apr-13 2:18

You are creating a user-interface thread. With socket operations worker threads are usual.

Also, why did you retry to create the thread if the first call fails? This makes no sense.

If the thread creation is done by your main thread, it will be blocked by calling WaitForSingleObject() until the thread terminates.

The skeleton for using a worker thread would look like this:

class CMyClass // optional : public CObject
{
public:
    void StartThread();
protected:
    bool m_bKill;
    CWinThread *m_pThread;
    static UINT ThreadFunc(LPVOID pParam);
};

void CMyClass::StartThread()
{	
    m_pThread = AfxBeginThread(ThreadFunc, this, THREAD_PRIORITY_NORMAL,
        0, CREATE_SUSPENDED);
    // When m_pThread is deleted by this class (e.g. when using a StopThread() function)
//  m_pThread->m_bAutoDelete = FALSE;
    m_pThread->ResumeThread();
}

UINT CMyClass::ThreadFunc(LPVOID pParam)
{
    CMyClass* pThis = reinterpret_cast<CMyClass*>(pParam);
    bool bKill = false;
    while (!bKill)
    {
        // Call WaitForMultipleObjects() here to:
        //  Check for kill event: Break
        //  Check for I/O event: Handle event
        //  Check for timeout: Break or handle it in some way
        // If not using a kill event
        if (pThis->m_bKill)
            break;
    }
    return 0;
}