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.
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?
No, I didn't call CWinApp::OnFileOpen, but I call OpenDocumentFile(...), something like that:
if(IDOK == dlg.DoModal())
POSITION pos = dlg.GetStartPosition();
// 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 ...
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)
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.
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 ...
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.
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
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
static UINT ThreadFunc(LPVOID pParam);
m_pThread = AfxBeginThread(ThreadFunc, this, THREAD_PRIORITY_NORMAL,
// When m_pThread is deleted by this class (e.g. when using a StopThread() function)// m_pThread->m_bAutoDelete = FALSE;
UINT CMyClass::ThreadFunc(LPVOID pParam)
CMyClass* pThis = reinterpret_cast<CMyClass*>(pParam);
bool bKill = false;
// 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 eventif (pThis->m_bKill)
So each time the timer fires, you are updating a progress bar, correct? Is that progress bar owned by the same thread that is running the timer? If so, it may be that the paint messages are not being processed. However, without seeing relevant code, I can't say for sure.
"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
Last Visit: 31-Dec-99 18:00 Last Update: 29-Sep-23 14:11