|
here is what I got from command message box:
(930.754): Wake debugger - code 80000007 (!!! second chance !!!)
eax=0012f5e8 ebx=00000000 ecx=00010101 edx=00000000 esi=005043a8 edi=00000000
eip=77e589a7 esp=0012f5d8 ebp=0012f608 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
USER32!NtUserWaitMessage+0xb:
77e589a7 c3 ret
0:000> .ecxr
eax=0012f5e8 ebx=00000000 ecx=00010101 edx=00000000 esi=005043a8 edi=00000000
eip=77e589a7 esp=0012f5d8 ebp=0012f608 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
USER32!NtUserWaitMessage+0xb:
77e589a7 c3 ret
does it mean" USER32!NtUserWaitMessage+0xb: 77e589a7 c3 ret" is there place that exe crash?
I was testing windbg, so I changed the "return CView::PreCreateWindow(cs);" to "return 0", when I debug the exe, it pops up message says "failed to create enpty document". thanks for looking!
|
|
|
|
|
Two suggestions,
1. Maybe you are looking at wrong thread? Try '~*' command to see what threads are there.
2. Try issuing 'kb' to dump call stack and see if that call stack makes sense.
|
|
|
|
|
0:000> ~
. 0 Id: 930.754 Suspend: 1 Teb: 7ffde000 Unfrozen
0:000> kb
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
0012f5d4 77e33604 00000000 00000000 0000ffff USER32!NtUserWaitMessage+0xb
0012f608 77e441d4 00400348 00000000 00000001 USER32!DialogBox2+0x216
0012f62c 77e34110 77e10000 001371c0 00000000 USER32!InternalDialogBox+0xd1
0012f8e4 77e344ac 00000030 0012fa84 ffffffff USER32!SoftModalMessageBox+0x757
0012fa2c 77e3399f 00000001 00000000 00000028 USER32!MessageBoxWorker+0x247
0012fa84 77e34237 00000000 00136230 00135520 USER32!MessageBoxExW+0x77
0012fab4 77e333d0 00000000 002f419c 002f2518 USER32!MessageBoxExA+0xa0
0012fad4 5f460f22 00000000 002f419c 002f2518 USER32!MessageBoxA+0x49
0012fc14 5f460fb0 002f419c 00000030 0000f104 MFC42D!CWinApp::DoMessageBox+0x17f
0012fc2c 5f46105f 002f419c 00000000 0000f104 MFC42D!AfxMessageBox+0x2c
0012fc60 5f444e55 0000f104 00000000 0000f104 MFC42D!AfxMessageBox+0x93
0012fcbc 5f45a7c4 00000000 00000001 0012fedc MFC42D!CSingleDocTemplate::OpenDocumentFile+0x1a5
0012fd58 5f4616ea 004177d0 0012fd9c 5f43749c MFC42D!CDocManager::OnFileNew+0x121
0012fd64 5f43749c 0012fedc 00000000 7ffdf000 MFC42D!CWinApp::OnFileNew+0x2a
0012fd9c 5f437bcb 004177d0 0000e100 00000000 MFC42D!_AfxDispatchCmdMsg+0xa2
0012fdf4 5f498003 0000e100 00000000 00000000 MFC42D!CCmdTarget::OnCmdMsg+0x274
0012fe44 004015e6 0012feb0 00000000 00000000 MFC42D!CWinApp::ProcessShellCommand+0x63
0012fee8 5f4335c3 00000000 00000000 7ffdf000 HL!CHLApp::InitInstance+0xf6 [C:\HL\HL\HL.cpp @ 88]
0012ff08 00403138 00400000 00000000 00132cb0 MFC42D!AfxWinMain+0x83
0012ff20 00403043 00400000 00000000 00132cb0 HL!WinMain+0x18 [appmodul.cpp @ 30]
It kind of make sense now, because I changed the BOOL PreCreateWindow(CREATESTRUCT& cs) funtion in HLVIEW.cpp, it couldn't created the window, so it crash on HL.cpp at line 88.....the line 88 is like this "if (!ProcessShellCommand(cmdInfo))
return FALSE;"
did I get this right? Thanks a lot for your help!!!
-- modifed at 11:38 Thursday 25th August, 2005
|
|
|
|
|
It looks to me like the last thing that happened was a message box on the screen.
0012f5d4 77e33604 00000000 00000000 0000ffff USER32!NtUserWaitMessage+0xb
However, that message box was probably in response to the failed window creation, which was probably previously attempted in response to this function's internals:
0012fcbc 5f45a7c4 00000000 00000001 0012fedc MFC42D!CSingleDocTemplate::OpenDocumentFile+0x1a5
When MFC framework opens a file:
0012fd58 5f4616ea 004177d0 0012fd9c 5f43749c MFC42D!CDocManager::OnFileNew+0x121
It will attempt to create a document matching the file, and that document wants a CView-based class to display the document within. You set off a chain reaction of failures when you did not create the CView for the document.
|
|
|
|
|
this is exactly what have happened!!
but I just couldn't see it.....Thank you so much for all your help!
|
|
|
|
|
I use VC.net to create a MFC regular DLL. VC wizard generates a skeleton for me.
// CVCMFCDLL_App
BEGIN_MESSAGE_MAP(CVCMFCDLL_App, CWinApp)
END_MESSAGE_MAP()
// CVCMFCDLL_App construction
CVCMFCDLL_App::CVCMFCDLL_App()
{
// TODO: add construction code here,
// Place all significant initialization in InitInstance
}
// The one and only CVCMFCDLL_App object
CVCMFCDLL_App theApp;
// CVCMFCDLL_App initialization
BOOL CVCMFCDLL_App::InitInstance()
{
CWinApp::InitInstance();
return TRUE;
}
All these is not what I expected. I want to export my own Class. What are those for? may I delete all those stuff?
Why it contains a "theApp"? it is really confused!
|
|
|
|
|
xianwuluo wrote:
I want to export my own Class.
Sounds like you want an MFC Extension DLL then.
xianwuluo wrote:
What are those for?
Initialization, globals, whatever.
|
|
|
|
|
I don't want MFC extention DLL. regular is enough. I just found these skeleton useless.
I delete these stuff, it works!
another problem:
I don't want my class private member to be exposed to Client. I know I have to use .def file to export class. but when I do
EXPORTS
; Explicit exports can go here
CMyClass
I got compile error. CMyClass is not recongnized by compiler.
|
|
|
|
|
xianwuluo wrote:
I don't want my class private member to be exposed to Client.
Isn't that what private means ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Yes, Client can not access to it. but as the private variables or functions are listed in .h file. Client is going to include in this application. It would be nicer, that Client only see public stuff of the class.
|
|
|
|
|
Two notes:
1) C++ does name mangling to encode additional information in exported symbols. You need to list the mangled names in the .def file, or use Microsoft-specific commands in your code to make this happen. (hint: the latter is far easier than the former)
2) Because of the way C++ works, you can't expose a class without exposing private member variables. If you don't want your client to see these when reading the header file, then you'll need to go to some extra effort to make that happen - export a class that doesn't have the private member variables, but internally uses the class that does to do what it needs. Do a search for "facade pattern" if that doesn't make sense.
|
|
|
|
|
|
hi,
does anyone know how to call a program(such as mspaint, word or any other program/ executable present) from our vc++ application. i.e. on executing an application it should call another windows program.
thanks
aditya
|
|
|
|
|
See here.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
DavidCrow wrote:
See here.
... plus the spawn functions.
|
|
|
|
|
Why? Those are simply a holdover from the days of Unix. Unless you are doing 16-bit work, they have no place in Windows development.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Aditya Rao wrote:
executing an application it should call another windows program.
you can try this also www.codeproject.com/system/newbiespawn.asp[^]
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
I have a simple question. I have inherited a VC++ application that uses a 3rd party software (Roguewave Stingray) for its GUI grids, tree controls, etc. Since I inherited this app, plus the fact that I don't have much experience writing large pc-based apps from scratch, my question is:
What is the advantage of using 3rd party tools for grids, tree controls, etc.? Doesn't MFC have this functionality built in, or is it just not robust enough for large-scale apps? My app is approx. 8 years old, so is the answer to this question different now than it was 8 years ago?
Thanks for any feedback.
Pat
|
|
|
|
|
normally, one buys a toolkit if the current one does not offer what she really want.
for example, there is/were not real spreadsheet/grid control in MFC, and companies ( roguewave, dundas, ... ) decided that there was a market to build such a control to sell to us programmers.
MFC is good enough for applications that stay within a strict MFC/Windows application guideline, and is simple enough so that it does not have a stepp learning curve. The problem arise when the programmer wants to do something that is not supported or already done ( grid, advanced editors, trees, ... ); the programmer has to learn more than just the class structures, and basic win32 API, he has to learn how to program with low(er) level API than MFC, and for some companies, having someone spend days or week developping a control that can be bought is not good meny spent.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Hi!
Here's the problem: I have a chat window using a rich edit control, with a vertical scrollbar. When a user is scrolled to the bottom of the rich edit, the text should automatically scroll down when new text is added. But if the user is scrolled up higher in the rich edit, reading something that was written awhile ago or catching up on the chat or something, it should not scroll down.
If I just do nothing to it, everything works except that until the user actually physically scrolls to the bottom ONCE, the text will not automatically scroll down.
I've tried using the GetScrollInfo function to get the max scroll position and compare it to the current position, but the info gleaned by GetScrollInfo doesn't seem to coincide to itself; i.e. when the user has fully scrolled to the bottom, nPos != nMax, the max seems to be a lot larger than the position.
What to do??
Thanks!
Kelly Ryan
|
|
|
|
|
I am using VC++ in visual studio dotNET. I wrote a program that has several threads running doing stuff, and a dialog box that is updated by the main thread. Everything works well when I hit "run" in the development environment. But when I run the executable, everything seems fine, but if I so much as click anything outside of the dialog box window, the window does not get updated again, it does not repaint, and it appears to have stopped responding. The other threads, however, are still running, and when they finish, the main window is updated with all the information that it should have been displaying along the way. I am a little new to the ms environment, and I thought that running through the development environment and running the .exe should be the same. Does anyone know what is going on here?
I could really use some help.
|
|
|
|
|
DaveHuber wrote:
...and a dialog box that is updated by the main thread.
Does the main thread own the dialog box?
DaveHuber wrote:
...but if I so much as click anything outside of the dialog box window, the window does not get updated again, it does not repaint, and it appears to have stopped responding. The other threads, however, are still running, and when they finish, the main window is updated with all the information that it should have been displaying along the way.
This is a classic problem with threads. Read here and here for more.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
the program is just a dialog box that is owned and exclusively updated by the main thread
|
|
|
|
|
So has the main thread created these other threads to do some work? How are they communicating with the main thread?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
The main thread starts the other threads with afxBeginThread, they go and do their work, and then when they're done, the last thing they all do before killing themselves is fill a global array with their results. but while they are working, the main thread doesn't seem to be doing anything. I don't understand why it works ok when I run it through development environment, but not otherwise.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
