|
The "next" and "back" buttons suggest that you might find it useful to build your app around a CPropertySheet in so-called wizard mode. Look at the CP Property Sheet and Property Page articles[^] for a start.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I am having a problem with GDI+. I have created a Bitmap object from a BMP file. I then use LockBits/UnlockBits to give me access to the image data so I can perform a color correction. Finally, I want to save it as a JPEG. I get an "Invalid Parameter" error returned from the Bitmap::Save method.
If I remove the code that does the color correction, the save works properly.
Does anyone know why the Save method doesn't like me changing the bitmap data?
|
|
|
|
|
Hi !
I'm invovled in a new project, and we have to define how we'll handler errors. I never had to think too much about this problem and now, I'm wondering what is the best way to handle errors. For instance, let's say that a method in a class has to allocate memory, but the allocation fails. What do you do ? Will the method have to deal itself with this problem, and display a message and stop (for example) the application ? Do you have a global object, handling errors which can be used anywhere for this purpose ?
Well, as you can see, my mind is not clear about this issue. Any ideas, hints, or links which would help me will be greatly appreciated !
Thanks !
Jerome
|
|
|
|
|
Error handling depends on the critical level of the error. For example, I consider memory allocate failure a critical error, so one solution would be to throw an exception.
Kuphryn
|
|
|
|
|
If you're starting from scratch, and all the programmers in the group are competent enough, exceptions are IMHO the way to go. Grouping the exceptions into well structured hierarchies gives you the ability to handle different groups of errors in well localized pieces of code (which are high level in the sense that they enter into action well up the call stack, relieving the inner code from having to deal with unexpected situations). Also, exception-driven code tends to be smaller in size than code using more traditional techniques like return codes and stuff.
Will the method have to deal itself with this problem, and display a message and stop (for example) the application?
No no no  Inner code should not attempt to do any high level recovery like shutting down the app; instead, errors should propagate up to the core of the application, where there exists enough visibility about the various components integrating the system and which is the best way to deal with the problem.
Do you have a global object, handling errors which can be used anywhere for this purpose ?
If you abandon the scattered error recovery mechanisn, there's no need for such objects, altough they can be a good method to group error handling code.
Well, as you can see, my mind is not clear about this issue. Any ideas, hints, or links which would help me will be greatly appreciated !
There are some other issues to be considered that impact the choice of the best error recovery mechanism to adopt. single threading / multitheading is one of them, for instance. Also, in GUI apps is harder to have centralized error handling code, and exceptions are of limited usefulness (basically because all code is executed as a call from the system in response to a user input, so there's no high level orchestrator that can deal with unexpected situations).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
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)...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
