|
Hi,
the big try-catch is great as a fall-back, to exit gracefully with a log;
but it is no substitute for the regular try-catch blocks you should implement at
critical points in the code.
Also it only catches exceptions in the main thread. So there is a lot more to it to get
it right.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Luc Pattyn wrote: which also depends on the .NET version
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi Mark,
the sentence, while IMO correct if you use .NET, was deleted the minute I posted my reply,
so the reply does not show a "modified..." message. I am surprised you were able to see it anyway.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Luc Pattyn wrote: I am surprised you were able to see it anyway.
It's a multithread issue depending on .NET version I suppose...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
I have always been assuming a post only became visible after a 2 to 3 minutes, giving
the author the opportunity to correct it without creating replies like these...
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Nah It's fast. What are the odds a goofball like me would catch it the instant you posted
and give you a hard time about it?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
hehe I just happened to refresh as you posted the first time
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Luc Pattyn wrote: the big try-catch is great as a fall-back, to exit gracefully with a log;
but it is no substitute for the regular try-catch blocks you should implement at
critical points in the code.
I Know. My "I don't know if it is a good idea" was about that.
Luc Pattyn wrote: Also it only catches exceptions in the main thread. So there is a lot more to it to get
it right.
he may repeat the pattern in all program threads.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
CPallini wrote: he may repeat the pattern in all program threads.
and in all callback functions/methods (e.g. timer ticked, serialport datareceived),
requiring the implementation of an exception tracing mechanism, so the info does not
get lost.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
I make a guess: he is not developing a OS from scratch...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
CPallini wrote: I make a guess: ...
I'm not a guessing guy, and the OP explicitly asked how to catch all possible exceptions,
hence...
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Luc Pattyn wrote: I'm not a guessing guy
Well, I will not keep going at your limitations...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
|
Exceptions depednds to your program,what's your code?
|
|
|
|
|
Every time I used TextOut (e.g. TextOut(dc,20,20,S,strlen(S)); ) with Borland C++ 4.52 under Windows 95 or Windows 98, the position of the text (in the second & third args) was relative to the window that the calling application was running in. But with Visual C++ under Windows Vista the text is positioned (here, at (20,20)) relative to the whole screen. This is a nuisance. What is happening? How can I position the text relative to my application's window?
modified on Saturday, April 12, 2008 9:01 AM
|
|
|
|
|
I dont know why the phenomenon happens, anyway ClientToScreen [^] function maybe useful.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
TextOut() in the context you show is a Windows API - it shouldn't vary between compilers.
It could vary between Windows versions, but that would break a lot of apps.
The problem is your DC. The device context determines where the text goes, based on how the DC
was acquired, its mapping mode, its text alignment settings, etc.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I made the device context using ordinary familiar GetDC(hwnd) .
|
|
|
|
|
Then hwnd must have been NULL.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi!
I know this may looks a little funny! But when I use CDialog::EndDialog to terminate my dialog based app, the main window (dialog) disapears well, but when looking at Task Manager, I found it already running!
Can U help me PLS?
|
|
|
|
|
Hi,
If you have other threads running, the app will wait for them to terminate, unless they
are set to be background threads.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Thanks 4 Ur reply!
I've not made any thread myself;
Is it possible for MFC classes to create threads by themselves? (Specially I used CRecordset frequently in my app!)
Thanks 4 Ur attention!
|
|
|
|
|
Usef Marzbani wrote: Is it possible for MFC classes to create threads by themselves?
I don't know, it could be. If so, it must be documented, and the doc should tell you what
to do about it, say call Close(), Stop() or whatever is appropriate.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
EndDialog() may be the wrong method for shutting down your app.
It depends on how and where you create the main dialog. Is it modal or modeless?
Where in the code do you create it?
CDialog::EndDialog is for modal dialogs. That means your main dialog needs to be created modal.
When control returns from the modal dialog, your app needs to exit. It should be something like this:
BOOL CMyApp::InitInstance()
{
CMyMainDlg dlg;
m_pMainWnd = &dlg;
INT_PTR nResponse = dlg.DoModal();
if (nResponse == IDOK)
{
}
else if (nResponse == IDCANCEL)
{
}
return FALSE;
}If you return TRUE from InitInstance(), that would cause the behavior you're seeing, since the app
would still be running but the dialog would be gone.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Your My(Perfect & Hero)
Thank you!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
