|
Thanks for your propositions !! I tried everything and.... I do not understand better the problem !!
If you change the MessageBox() to a TRACE() do you still get the exception? Maybe the stack is screwed before ZANErrorExit() is called.
I don't have any exception thrown with the TRACE ! The document hasn't been destroyed because this function is called from another function wich is called by OnNewDocument! If an error occur, this function returns an error code to OnNewDocument() that will return FALSE so the document will be deleted after ! Something I forgot to tell you: this code is used also on other projects and sometimes it works fine and sometimes not (depending of the project) !
If you wrap the code in ZANErrorExit() in a try .. catch what happens <\i>
The exception is caugth and that's it !
If you open the Assembly window and step through the assembler code when MessageBox() is reached what happens.
A lot (really a lot !) of assembly code is executed and then suddenly the exception is thrown (don't ask me at wich instruction, assembler is nt easy to read )
So, any idea to this strange bug ???
|
|
|
|
|
My guess is the problem has nothing to do with ZANErrorExit(). Can you temporarilly remove the code the creates data etc. and causes the error to occur. Instead fake a call to ZANErrorExit() and see what happens. It may be that whatever is causing the error that ZANErrorExit() is reporting on, is corrupting the stack, heap, or memory. This is where I'd be looking.
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
You know what, the more you suggest intersting things, the more I become crazy !! Here it's really mad:
So, in the first line of the OnNewDocument() function, I make a call to ZANErrorExit.
BOOL CDebitVolDoc::OnNewDocument()
{
ZANErrorExit(ZANERR_WRONGCOMMANDLINEARG);
if (!CDocument::OnNewDocument())
return FALSE;
And guess what ?? I still have the problem . So, from where is it comming ?? Do you think I've discovered some extra-terrestrial intelligence (Sorry, I go crazy )??
|
|
|
|
|
If you are running W98/ME/SE then I would suggest trying a reboot after getting an exception, or at least restart VC++. Does it happen both in Debug and Release Builds?
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
I'm running under Win2K. And I have also the bug with the release build !
|
|
|
|
|
cedric moonen wrote:
I'm running under Win2K.
I'd restart W2K just in case. Does it also happen in a Debug build?
If you change: ZANErrorExit(ZANERR_WRONGCOMMANDLINEARG); to just a call to MessageBox( ... ) is there still a problem?
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
Hmmm!! Something better:
I call
MessageBox(NULL,"Test","Test",MB_OK);
in the first line of the OnNewDocument() function and I have the same problem !
So it has nothing to do with the function itself, but rather with the message box !!
|
|
|
|
|
Calling MessageBox() will cause a change of window focus. That may be relevant. I can't recall what state things are in when OnNewDocument() is called. Has the Views window been created yet.
23:11 time for me to go to bed. Good luck in your hunt and let us know what happens.
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
No it's not because of the the view that hasn't been created because calling MessageBox in OnNewDocument in some other project I have causes no problems: it jusst show the message box.
So, good night then, I'll keep you informed if I'll find the solution
|
|
|
|
|
cedric moonen wrote:
with the debugger it jumps inside a completely different
Which class ? One you own or a MFC one ?
~RaGE();
|
|
|
|
|
One of mine wich is used to store text strings for the current language (loaded from a text file). (Is it a coïncidence ???)
But the pointer on this class is initialized after (first I check the command-line and then I load this file it it exist). But here, I never make a call to this class !!!
|
|
|
|
|
That sounds to me like a memory problem. Check your initialisations, maybe use #define DEBUG_NEW to trace memory leaks.
~RaGE();
|
|
|
|
|
Hmmm... don't think so: take a look at the message I posted with Frank: if I call the function at the first line of OnNewDocument, I still have the bug!
|
|
|
|
|
Maybe give us a copy of the CallStack where the bug occurs.
|
|
|
|
|
here is the copy of the callstack just after the bug (I cannot giv it just before because it runs through assembler code and I can't detect where is the failure! :
TEXTDEF::nr(unsigned int 57345, char * 0x0068e16c `string') line 64 + 6 bytes
CMainFrame::GetMessageString(unsigned int 57345, CString & {""}) line 186 + 20 bytes
CFrameWnd::OnSetMessageString(unsigned int 57345, long 0) line 1513
CWnd::OnWndMsg(unsigned int 866, unsigned int 57345, long 0, long * 0x0012f3dc) line 1815 + 17 bytes
CWnd::WindowProc(unsigned int 866, unsigned int 57345, long 0) line 1585 + 30 bytes
AfxCallWndProc(CWnd * 0x013d1900 {CMainFrame hWnd=???}, HWND__ * 0x00030360, unsigned int 866, unsigned int 57345, long 0) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00030360, unsigned int 866, unsigned int 57345, long 0) line 368
USER32! 77e01d0a()
USER32! 77e01bc8()
USER32! 77e01cef()
USER32! 77e16d62()
USER32! 77e2ca3b()
USER32! 77e2c475()
USER32! 77e2d47e()
USER32! 77e25c19()
USER32! 77e25ba6()
CDebitVolDoc::OnNewDocument() line 144 + 22 bytes
CSingleDocTemplate::OpenDocumentFile(const char * 0x00000000, int 1) line 151 + 11 bytes
CDocManager::OnFileNew() line 829
CWinApp::OnFileNew() line 29
_AfxDispatchCmdMsg(CCmdTarget * 0x006cd008 class CDebitVolApp theApp, unsigned int 57600, int 0, void (void)* 0x0052b330 CWinApp::OnFileNew(void), void * 0x00000000, unsigned int 12, AFX_CMDHANDLERINFO * 0x00000000) line 88
CCmdTarget::OnCmdMsg(unsigned int 57600, int 0, void * 0x00000000, AFX_CMDHANDLERINFO * 0x00000000) line 302 + 39 bytes
CWinApp::ProcessShellCommand(CCommandLineInfo & {CCommandLineInfo}) line 31 + 30 bytes
CDebitVolApp::InitInstance() line 104 + 12 bytes
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00133094, int 1) line 39 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00133094, int 1) line 30
WinMainCRTStartup() line 198 + 54 bytes
KERNEL32! 77e8ca90()
The first line is the instruction that causes the bug: I (hmm, not me but the compiler )calls a method from a class that hasn't been instancide (nr() funtion) !
|
|
|
|
|
Looks to me like your app is trying to update the status bar line..... and you probably don't have a window created/initialized.... so... find in your code where you are trying to update the status bar text.
|
|
|
|
|
Hi!
I try to use two pc to work on a project. pc A get raw data from a card, then do some process, then pass the parsed data to pc B to render it into image.
I wanna know the fastest API to push data form pc A to pc B. I think socket will not the fastest for it is base on tcp/ip. Then will pipe in win32 the fastest one?
Any other idea?
|
|
|
|
|
Not sure which is the fastest (will there be any difference? - it's all going over the same wires ), but this article[^] and the ones it's linked to may help you decide...
(BTW - if the link doesn't work, Google for the strings "Plugs and Jacks" and Asche, that should take you there)
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
Actually, TCP/IP, in my experience, is faster due to the fact that Named Pipes is an authenticated protocol.
|
|
|
|
|
Does authentication affect the communication process after the channels been established? Must admit, I've got no experience of how these different protocols compare performance-wise, I'm just intrigued...
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
Hi!
I just try to add some exception procession in my console program. But it seems work in debug but not in release. I don't know what's up. In debug, it output a "catch it" and stop itself. but in release, there is a dialog popup out "Integer Divide by Zero".
int a = 0;
int b;
try
{
b = 10 / a;
printf("b = %d a = %d\n", b, a);
}
catch (...)
{
printf("catch it");
return -1;
}
return 0;
|
|
|
|
|
To catch an error you have to throw an exeption by calling throw. In debug mode certain exeptions are handled by the debuger, but that's not the case in your release version.
If an exception is not caught by any catch statement because there is no catch statement with a matching type, the special function terminate will be called.
This function is generally defined so that it terminates the current process immediately showing an "Abnormal termination" error message. Its format is:
void terminate();
int a = 0;
int b;
try
{
b = 10 / a;
if( a == 0 ) throw "Error";
printf("b = %d a = %d\n", b, a);
}
catch (...)
{
printf("catch it");
return -1;
}
// Afterall I realized that even my comment lines have bugs
|
|
|
|
|
Toni78 wrote:
...because there is no catch statement with a matching type...
But there is: He has written catch(...) to catch ALL exceptions!
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
jhwurmbach wrote:
But there is: He has written catch(...) to catch ALL exceptions!
These are the definitions for try, catch, and throw:
"The code within the try block is executed normally. In case that an exception takes place, this code must use throw keyword and a parameter to throw an exception. The type of the parameter details the exception and can be of any valid type.
We can also define a catch block that captures all the exceptions independently of the type used in the call to throw. For that we have to write three points instead of the parameter type and name accepted by catch."
You have to throw an exception because you can't just simply expect the compiler to throw every kind of exception that there is out there.
Of course you can argue and say that division by zero is a standard exception and I agree with you on that, but catch(...) doesn't catch ALL the ecxeptions unless you throw some of them. Otherwise, programs would never crash.
// Afterall I realized that even my comment lines have bugs
|
|
|
|
|
Pal, sorry. I still not very clear about it.
Does it mean we can't catch a "divide by zero" exception at all? We have to exam every number whether it is zero before we do a divide if we want the program wont crash with a 0? Any code to solve my example?
|
|
|
|