|
Thanks for your reply.
The stack at the level of my program says:
489gui.exe!CMainFrame::OnCmdMsg(unsigned int nID=0x0000e141, int nCode=0x00000000, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 132 + 0xf C++
I kind of new to MFC programming so you'll have to bear with me while I try and understand this all.
I can double-click the top-left box of the dialog and it quits fine, if that helps. I'm not sure what WM_QUIT resolves to as a number. m_wndView is a member of the CMainFrame class.
Somehow it's stopped crashing recently though, but I have a feeling the problem will come back.
|
|
|
|
|
I just moved some stuff around, mainly inserted a new segment in the status bar. Now I get a crash before I see a window. In my InitInstance, I call "pFrame->ShowWindow(SW_SHOW);" and in there it crashes on "return m_pCtrlSite->ShowWindow(nCmdShow);" but m_pCtrlSite is a pointer to the address 0xfeeefeee which is not right. I think I know what's wrong but I have no idea how to fix this one either.
|
|
|
|
|
Creating of toolbars and status bars are generally done in the OnCreate function of the CMainFrm class. The value of your pointer indicates that the frame has not been created yet.
Steve
|
|
|
|
|
I'm curious to know of this is an AppWizard created program, or an MFC program created from scratch.
As Steve said, the toolbars and status bars are generally initialized in the Frame's OnCreate. If this was created by AppWizard, then there should already be some code there to create the initial status bar and toolbar, if you want to look at an example.
Bob Ciora
|
|
|
|
|
This program was originally written from scratch mainly to immerse myself in Windows programming. After reaching a plateau of understanding and realizing the app code is filled with failed attempts at doing things that don't need to be done, I started a new project, using the AppWizard and simply fill in the routines from my old code.
I had a feeling the problem is because of the toolbar because that's what I changed immediately before this recent error cropped up, but I don't see how to fix it without reverting my changes. Here's the code for my status bar now:
<br />
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) {<br />
... (creates view window and toolbar here) ...<br />
if (!m_wndStatusBar.Create(this) || !m_wndStatusBar.SetIndicators(indicators, sizeof(indicators)/sizeof(UINT))) {<br />
TRACE0("Failed to create status bar\n");<br />
return -1;
} else {<br />
int i;<br />
m_wndStatusBar.SetPaneInfo(0, ID_INDICATOR_INFOLINE, SBPS_STRETCH, 80);<br />
m_wndStatusBar.SetPaneInfo(1, ID_INDICATOR_WORKING, SBPS_NORMAL, 150);<br />
m_wndStatusBar.SetPaneInfo(2, ID_INDICATOR_COMMSETTINGS, SBPS_NORMAL, 125);<br />
m_wndStatusBar.SetPaneInfo(3, ID_INDICATOR_USIZE, SBPS_NORMAL, 125);<br />
m_wndStatusBar.SetPaneInfo(4, ID_INDICATOR_SENTLENGTH, SBPS_NORMAL, 90);<br />
m_wndStatusBar.SetPaneInfo(5, ID_INDICATOR_RECVLENGTH, SBPS_NORMAL, 120);<br />
m_wndStatusBar.SetPaneInfo(6, ID_INDICATOR_CSIZE, SBPS_NORMAL, 140);<br />
<br />
m_wndStatusBar.SetPaneText(0, "No File Loaded", true);<br />
for (i=1; i<6; i++) { m_wndStatusBar.SetPaneText(i, "", true); }<br />
... (sets toolbar style here) ...<br />
return 0;<br />
}<br />
The COMMSETTINGS toolbar segment is the one I added. CMainFrame is derived from CFrameWnd.
|
|
|
|
|
Did you remember to put the ID_INDICATOR_COMMSETTINGS in the indicators array and is it in the 3rd position (or are there at least 7 entries in the indicators array)?
Steve
|
|
|
|
|
Yes I did, here's the array declared above:
static UINT indicators[] = {<br />
ID_INDICATOR_INFOLINE,
ID_INDICATOR_WORKING,
ID_INDICATOR_COMMSETTINGS,
ID_INDICATOR_USIZE,
ID_INDICATOR_SENTLENGTH,
ID_INDICATOR_RECVLENGTH,
ID_INDICATOR_CSIZE
};
|
|
|
|
|
If you've rebuilt the application using AppWizard, you most likely don't need to call m_mainWnd::OnCmdMsg() (as you showed in your initial post). For most MFC apps, you don't have to write your own OnCmdMsg. Is there anything specific to m_mainWnd that requires you to do this?
When you quit the app with either the top right [x] or by double-clicking the top left icon, that generates a WM_CLOSE windows message. If you quit the app by selecting File->Exit, that generates an ID_APP_EXIT command, which is actually passed as the WPARAM of a WM_COMMAND windows message. WM_COMMAND messages are what are passed to OnCmdMsg, while the WM_CLOSE follows its own path.
So there are different code paths when you exit the app in those different ways. Does your m_mainWnd do something special in its OnCmdMsg when it sees the ID_APP_EXIT command? My suspicion on the whole thing is still that something is being invalidated/destroyed in m_mainWnd's OnCmdMsg, then the default CMainFrame::OnCmdMsg is trying to destroy the same thing, causing the crash.
In your OnCmdMsg handler, try adding a little "trap" at the beginning, something like this:
BOOL CMainFrame::OnCmdMsg( UINT nID, int nCode, void* pExtra,
AFX_CMDHANDLERINFO* pHandlerInfo)
{
if( nID == ID_APP_EXIT )
{
int nDummy = 0;
}
if (m_wndView.OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))
return TRUE;
return CFrameWnd::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo);
}
You can then set a breakpoint on the "dummy" line (using F9) to trap the ID_APP_EXIT command when it's recieved. After that, you can single-step through the remainder of the function using F11 (this will step into functions) or F10 (to step over them).
I'd suggest stepping into your m_mainWnd::OnCmdMsg and see what it does when it gets this ID_APP_EXIT command.
Bob Ciora
|
|
|
|
|
I understand what you mean, I knew clicking the X or double-clicking the upper-left command box was different from the menus exit because the former still works, but I didn't know how the app handles each way.
I commented out the status bar because of the problems it's giving me which you may or may not be aware of branched off of my original thread starter.
When I add that code and I click on just File in the menu, it breaks at that point with this on the stack:
489gui.exe!CMainFrame::OnCmdMsg(unsigned int nID=0x0000e141, int nCode=0xffffffff, void * pExtra=0x0012f120, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 128 C++<br />
I tried stepping through anyway and everything seemed in order, but then again, I started to lose understand of what is happening.
I added to the if statement to catch when the ID_APP_EXIT nID is received and the nCode is 0x00000000 which is the case when the program crashes. However, both cases in which nCode is 0xFFFFFFFF and 0x00000000 happens before the menu is drawn, prematurely stopping the program before the instance in time we are waiting for when the Exit menu option is selected.
If I remove the breakpoint, I just noticed something, I don't think it's been there before, but 4 levels up from the CMainFrame::OnCmdMsg call, that the proper exit procedure is called, C489guiApp::OnAppExit(). It looks like my app is handling the menu click right but like you say, however something is getting destroyed and then is attempted to be used which crashes my app.
|
|
|
|
|
The first break would be when MFC is doing the OnUpdateUI processing for the menu item (where you can check/uncheck, enable/disable, etc. the various items in the menu), and the second break is the actual ID_APP_EXIT command. Does the program crash under both instances? The second time around is what you're really interested in.
One thing you may also consider looking at (and this may seem odd) is the "this" pointer in the Watch window, if you reenable the breakpoint. See if it's actually valid at the time of the second call. It's very possible that your MainFrame object isn't even valid (having been destroyed by your CWinApp derived class in OnAppExit. Again, this may seem odd, but it can happen.
Best of luck...isn't software fun?!!!! 
Bob Ciora
|
|
|
|
|
One other thing you can do is, when you see OnAppExit in the Call Stack window, you can double-click on that entry and it'll pop up a window showing the CWinApp core code with a green hilite line showing where the next call in the call stack was made.
You can always poke around this code, and even set a breakpoint higher up so that you can single step through OnAppExit to get a feel for what it's doing prior to the call that eventually leads to the crash.
Just a few more thoughts...
Bob Ciora
|
|
|
|
|
Thanks for your replies, Bob.
It actually doesn't crash when nCode is 0xFFFFFFFF or 0x00000000 (which is what it's set at when it does crash), so the nCode isn't at least obviously what's wrong. I tried putting the breakpoints back in but it kept interrupting my menu clicks by breaking, so I inserted this code first thing in CMainFrame::OnCmdMsg:
CString message;<br />
FILE * outfp;<br />
outfp = fopen("debuginfo.txt", "a");<br />
if (nID == ID_APP_EXIT) { <br />
message.Format("message: nID=0x%X, nCode=0x%X, this=0x%X\n", nID, nCode, this);<br />
fputs(message, outfp);<br />
}<br />
fclose(outfp);
That will append to the a debug file and only output when the message it's handling is ID_APP_EXIT. I opened the text file and found this:
message: nID=0xE141, nCode=0xFFFFFFFF, this=0x334AA8
message: nID=0xE141, nCode=0x0, this=0x334AA8
message: nID=0xE141, nCode=0xFFFFFFFF, this=0x334AA8
message: nID=0xE141, nCode=0x0, this=0x334AA8
So this stays valid the entire time. The only thing I have in OnAppExit() is "exit(0);".
About the stack, I fixed some bugs that I could fix earlier using the stack and it helped me figure out where things went wrong. I might pass by value here but expecting an address there, giving me access violation errors. This one just puzzles me.
|
|
|
|
|
Did you write your own OnAppExit, adding the "exit(0)" or was that in the base class? When you use AppWizard to build the program, you don't have to worry about overriding methods like OnAppExit, unless you really really need to. The base class implementation will do just fine. You don't need to add an explicit exit() call, since this will be taken care of automatically.
As far as looking at the this pointer, I was suggesting looking at the pointer in the Watch window. Once you've hit your breakpoint in the code, you can open the Watch window by selecting View->Debug Windows->Watch from the main menu. Add this to the list of watched variables, and it'll show up like a tree where you can expand and look at the member variables.
It's entirely possible that "this" or something within "this" has been destroyed while the pointer itself remains "valid." Within your block of code that dumps command info to the debug file, you may consider breaking there and just examining what's inside "this." If you see anything that looks "off kilter," that may suggest the problem.
You can always add some assertions within your debug block as well. Check things like ASSERT(GetSafeHwnd()) and do the same for the Frame's main View. At some point, the window handles may have been released without your knowledge.
Bob Ciora
|
|
|
|
|
I think I just took the template project I built onto it, but I think I put "exit(0)" there. I tried removing it and the menu didn't exit the app. I also run a function to terminate serial communications in the deconstructor and I tried remarking that out but that didn't help.
I have been looking at this because it is important. The problem is the crash occurs in uxtheme.dll under 8 layers of dll calls that I don't have the source for so I can't identify what individual variable is causing the crash so I can't trace it's path back. The last place on the stack that VS can retrieve sources for is in mfc70d.dll and I can see this and some items are null and some aren't and I don't know what to look for. The app is in the process of being deconstructed so even some items being null should be normal.
In an effort to fix the situation, I dumped the information I thought most relevant into a webpage if you want to look at what I'm looking at. Sorry if the middle column is too wide. It would have taken an immense amount of time to shift the columns over to get a better approximation of the tree structure of this, so I improvised. You have the minus and plus signs to help out, plus I applied different text styles to the page. this is bold and italic and is at the highest level. The bold items are directly under this. The italic items are directly under the bold item it follows. Again, I don't know what to look for and I have no recourse, except to strike the Exit menu item and force users to use the close box if this won't work.
|
|
|
|
|
Have you tried a full recompile of everything? I've sometimes found that this cures these problems. Sometimes, the incremental compilation/linking fails to produce correct code.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
yeah, I cleaned the project then rebuilt it, no change, both Release and Debug versions too.
|
|
|
|
|
i m working with MFC application and i have two listbox contaning float values. now i want to plot a graph as one listbox data considers as x axis and other as y axis so how to plot listbox data on graph and also how to make such as it limits changes accordingly as the values in listbox changes.
|
|
|
|
|
well, first you need to create a window to display the graph on. I'm assuming you know how to create a window already. Inside the window's OnPaint method, use the CDC object's MoveTo and LineTo functions.
-- Rocky Dean Pulley
|
|
|
|
|
There are some great free controls on codeproject for this, much simpler than doing your own.
NTGraph 2D
NTGraph 3D
|
|
|
|
|
This is not a question about some error that I may have. I am asking for your advice since this is the first (somewhat big) application for me.
Where would you save the options of a program ( like directories, and many other stuff),...in the registry...or using an options files.
And what is the best practice of those during, first the testing period (I have to give samples to my friends), and second after everything is done.
Thanks
|
|
|
|
|
Using options files is generally easier. Easier to code, and easier for users to modify directly if they need to. The other advantage to using files is that the application will be easier to port to another operating system. Outside of those advantages, the registry is a fine place to store stuff, but don't store too much junk there. If your options file ends up being a few hundred kilobytes, you may want to stick with a file and not clutter up the registry.
-- Rocky Dean Pulley
|
|
|
|
|
I would strongly recommend using one or more files. Your users (and testers) will bless you when they move your app between machines. The registry is evil. No, really. 
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Two votes for files...
Thanks for your suggestions
M Tarik
|
|
|
|
|
I usually Prefer Registry,as at some secure system you don't have write access in your C:\(generally wher your program is installed).
so to play safe bet i prefer saving my option in Registry (at least even in some part of HKEY_CURRENT_USER ,even Guest account has Write Priviledge).
"I Think this Will Help"
[Vote One Here,.....]
<h5
alok gupta="" <br=""> visit me at http://www.thisisalok.tk
|
|
|
|
|
Could someone lead me to a source for writing to and reading from COM1 in pure binary mode as simple as possible. Looking to send and receive single bytes in range of 0x00-0xff. The final code needs to work on WinXP platform. Thanks.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
