|
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?
|
|
|
|
|
novachen wrote:
Does it mean we can't catch a "divide by zero" exception at all?
I am not sure how the VC6 compiler handles this particular case so take a look at CException. If you are not using MFC then you have to write your own code.
novachen wrote:
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?
If you want to handle a divide by zero exception in your own way (not the compilers way) yes you have to check for every number before you divide, and you have to throw the error.
novachen wrote:
Any code to solve my example?
You could check my first reply to your message.
// Afterall I realized that even my comment lines have bugs
|
|
|
|
|
For me, it works in Debug as well as Release build.
The message is "First-chance exception in test4.exe: 0xC0000094: Integer Divide by Zero."
Did you disable exceptions in the Project settings under the 'C++ Language'-tab?
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
yes, Exception is enable in 'C++ Language' as default.
I won't like a "First-chance exception in test4.exe: 0xC0000094: Integer Divide by Zero." message. That's just i get in release version.
What i want is a console output "catch it" and end the program like the behavior in debug version.
|
|
|
|
|
VC6?
There is a bug in the optimizer with VC6 that causes simple try/catch blocks from working. What happens is that the compiler thinks there can't be an exception so it optimizes the try/catch block away.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|