|
I agree with Joaquín.
The only thing I would add is to not take exceptions lightly. Learn how to properly use them and you should be fine. Poor exception handling will usually make a program worse and not better. The biggest mistake people make is that when they start doing exception handling, they stop thinking about error handling. They assume things will just work out in the end. Even though exceptions might require less code, they require just as much forethought as older style error checking.
Even though I personally hate exceptions and avoid them at all cost, they do work when used right.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
There is really no way anybody can tell you how to handle errors, especially in the case of allocation failures. Many people think that all they need to do is use exception handling an the problem magically goes away. Software just isn't that easy.
If you are doing a client/server system where transactions can be considered mostly atomic in nature (i.e. send request, get a response), then having an exception handler to catch out of memory conditions is viable. You can always abort the transaction and return an error.
For other types of applications, trying to handle an out of memory error and then continue processing usually just results in the program dying in another section of the code. Or in some cases, you have the UI up, but every time the user tries something, they just get another error.
Some of the questions you have to ask yourself is what type of program are you creating. Is it a fault fatal, fault resistant, or a fault tolerant application (i.e. mission critical).
Fault fatal applications are the worst type of applications. They expect that the input is always good and that every GDI call always works. These are the bastard programs that die for no real reason when you run them.
Fault resistant application are ones that have been designed to check for your normal class of errors. They make sure that all user input is good and check for your most common GDI problems. However, fault resistant application don't go the extra mile to make sure that the program survives unlikely failures such as out of memory conditions. The reason I consider out of memory conditions to be unlikely is because there are three main causes, the first is that the user specified bad data and thus some allocation might have requested a 3GB allocation. Since fault resistant applications verify user input, this should not be a concern. The second class of out of memory conditions is if the user makes a request that just taxes the system too much. Even though the user input is valid, the system might not be able to complete the request. For the most part, these are the types of allocations you should be able to recover from if it fails. The final type of out of memory condition is when the system is truly out of memory. These conditions generally are fatal since there will probably not be any reasonable resolution to the problem. All future allocations will probably fail and the program will generally become unusable anyway.
In the case of a fault tolerant application, it tries to survive ALL forms of error conditions. These applications can be VERY hard to write.
For my software, we have always done fault resistant software. The main reason is that it doesn't take much more effort to do. However, fault tolerant software takes a LARGE amount of time. Don't let people fool you into thinking that a good sprinkling of try blocks will result in fault tolerant software. Poorly designed exception handling usually only leads to delaying the inevitable crash of the software.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote:
Don't let people fool you into thinking that a good sprinkling of try blocks will result in fault tolerant software. Poorly designed exception handling usually only leads to delaying the inevitable crash of the software.
Absolutely.
On top of that, it can sometimes be detrimental to use too many exception handlers, for performance reasons. Every time a try block is encountered, the program has to save the current machine state and stack state so it can unwind things properly. For a large application that is time critical, such as a busy web server, this performance penalty can be unacceptable.
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
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"
|
|
|
|
|
I've had to deal with something similar recently, and it is very hard to find any relevant materials. While many sources will tell you how to implement exception handling, your questions are similar to mine, and the answers are not found in how to structure exception handling or use return codes.
An unremembered source provided a very intriquing question in response to all of my questions, and the question dealt with the impact to the user. Have you ever used a word processing program that after you typed up your letter you went to print and the application came back with "The application encountered an error and will have to close." That's great, except what happened to my letter? It appears to be gone. DAMN!!!!
So, much of error recovery strategy can be focused on what happens to the user (or to other applications if this is an embedded app or something such). Will a memory error cause something fatal that will be a real inconvenience to the user? Enough so that he may not ever want to use this app again? Will a file error cause his work to be lost? Will invalid input cause something else to go wrong? What are the sources of errors that will hamper the user?
When the answers are determined by an impact to the user of your app, then error recovery starts to become clearer. If, at all costs, you value the user and want to isolate him from any irritation caused by something in your app, then whether you use exceptions or return codes becomes an implementation detail of a larger topic.
Good luck,
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
Is it possible to process the enter key in my CEdit derived class.
Im new to programming so perhaps its very simple.
//Jonas
|
|
|
|
|
Define what you mean by "process."
|
|
|
|
|
I already feel stupid, i just want to know when it have ben pressed, in some way, via a message. I thought it would be logical that the OnKeyDown message was sent to it, but it isnt.
|
|
|
|
|
Well, you have to send the message to some
window I guess? Or a button?
jhaga
|
|
|
|
|
So its not possible to catch it in the CEdit box?
|
|
|
|
|
Yes, an edit box is a window. But it must have
the focus of course.
jhaga
|
|
|
|
|
You'll need to derive a class from CEdit. In this class' OnChar() handler, look for nChar equal to VK_RETURN.
|
|
|
|
|
I found it in CWnd, thanks a lot!
|
|
|
|
|
Uhhhh, i just saw that it was to be found in the message map the entire time... at least i learned something new...
|
|
|
|
|
Hi,
Also try with "ES_WANTRETURN" style in CEdit button (or click "Want Return" checkbox in resource
properties" along with DavidCrow's suggestions.
Hope this helps
regards
~Hari~
|
|
|
|
|
void CMyEditView::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
switch(nChar) {
case VK_RETURN:
// do something
break;
default:
CRichEditView::OnKeyDown(nChar, nRepCnt, nFlags);
// TODO: Add your message handler code here and/or call default
}
}
and remember
ON_WM_KEYDOWN() in the
MESSAGE_MAP
jhaga
|
|
|
|
|
Yes, i noticed that it didnt work after all, i was mistaken. Perhaps(not really) i pressed another key. I hope it works now...
|
|
|
|
|
Process NM_RETURN message, if the edit control has the focus.
// Afterall I realized that even my comment lines have bugs
|
|
|
|
|
Edit control is not the same as CEdit, is it?
jhaga
|
|
|
|
|
Yes, and it still doesnt work. Im really lame sorry, but i dont even get a
BOOL CGlosEdit::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
// TODO: Add your specialized code here and/or call the base class
return CEdit::OnNotify(wParam, lParam, pResult);
}
message...
|
|
|
|
|
The parent is a CListCtrl derived class, and is waiting for my CEdit derived class:s modal loop to finish, i have even specified the ES_WANTRETURN style for it(and unspecified)...
|
|
|
|
|
jhaga wrote:
Edit control is not the same as CEdit, is it?
The CEdit class provides the functionality of a Windows edit control, and NM_RETURN is the notification code sent when the user presses enter while the input control (in our case the edit control) has the focus. NM_RETURN is a code for common controls.
// Afterall I realized that even my comment lines have bugs
|
|
|
|
|
It also depends on where he wants to catch(or process) the key.
jhaga
|
|
|
|
|
Override the PreTranslateMessage virtual function for the dialog class that contains your CEdit-derived control:
BOOL CMyDlg::PreTranslateMessage(MSG *pMsg)
{
if (pMsg->message == WM_KEYDOWN && pMsg->wParam == VK_RETURN)
{
CWnd *pFocus = GetFocus();
if (pFocus == GetDlgItem(RESOURCE_ID_OF_CEDIT_DERIVED_CONTROL))
{
return TRUE;
}
}
return CDialog::PreTranslateMessage(pMsg);
}
-Sean
----
Shag a Lizard
|
|
|
|
|
Hi, i am beginner to visual c++, and some problems with list control and hope that somebody can help me out. Currently i have made a WebBrowser using active x. I want to capture the navigation when i surf the net with the WebBrowser.
So far i know that
void CIETEST2Dlg::OnNavigateComplete2Explorer1(LPDISPATCH pDisp, VARIANT FAR* URL)
{
CString strURL = m_WebBrowserCtrl.GetLocationURL();
SetDlgItemText(IDC_XXX, strURL); //IDC_XXX whereby is what tool control you use
}
i tried "SetDlgItemText(IDC_EDIT, strURL);" //whereby IDC_EDIT is edit box. And it works but it can display 1 URL at a time...
i tried creating a list control named IDC_LIST but it can't work. Now i have no idea on how to display the captured navigation to display out on the List control.
I hope that sombody could kindly help me with this problem. Thanks a million
-Desperate for help
I'm a newbie to visual c++. Simpler terms please
|
|
|
|
|
you can't use SetDlgItemText to set the text in a list control. You need to actually add the string to the list box. If you have an actual CListCtrl object you can call the InsertItem function. If you don't have the CListCtrl object already you can also do a
<br />
CListCtrl* pListCtrl = ( CListCtrl* ) GetDlgItem( IDC_LISTCTRLIDGOESHERE );<br />
pListCtrl->InsertItem( );<br />
Hope that helps.
Note: A simpler alternative to a ListCtrl object would be to use a list box. When using a list box you can use a similar method to get it if you don't have CListBox object but the functions are a bit simpler to use ( but provide less functionality ). Either way you can't use SetDlgItemText. You can use AddString() for a CListBox.
Cheers!
Joseph Dempsey
joseph_r_dempsey@yahoo.com
"Software Engineering is a race between the programmers, trying to make bigger and better fool-proof software, and the universe trying to make bigger fools. So far the Universe in winning."
--anonymous
|
|
|
|