Re: Resizing a CEdit control to fill its parent DialogBox???
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Wed, 28 Mar 2007 01:58:04 -0500
See below...
On Tue, 27 Mar 2007 09:54:44 -0700, "Nobody" <Nobody@xxxxxxxxx> wrote:
//TODO: Add your reply handler here! Ha! ;)****
Because, it is more important to know what is going on, rather than to payI don't pay too much attention to those comments anymore anyways.Why not?
attention to some
generic comment.
But if you ignore the comment and do the wrong thing, what, exactly, did you learn? THe
comments are not "generic" but in fact are very specific, and come out for different
handlers in different, and for all practical purposes, in the correct place.
****
****
The comment about the RichEditControl is one that is not so generic.
So, I leave that one alone. At least it explains why.
It say's something along the lines "If this is a RichEditControl, return
true, otherwise return false."
That is important to know.
In general, the TODO comments are well-placed. Not always, but nearly allMaybe, maybe not. It depends on what the code is supposed to do. It is
the time, and
the places where they are not quite right tend to be fairly obvious, such
as on
OnGetDlgCode, where you may want to add in values to the value returned by
the superclass.
application specific.
No, nearly all of the time, it is NOT application-specific. The number of times in over
12 years of MFC programming that I've had to make a change is very, very, very small.
****
I have had situations where sometimes I call the base class the first thing,*****
sometimes I call the
base class in the middle and sometimes I call it at the end. It is
application specific.
Not for the MFC handlers. If you get things out of order, you can get into serious
trouble.
*****
****
You can't just state that all code should go before or after the base class,
because that is where the MFC comment
is.
But most of the time, it is right. There are few situations in which something must be
changed. But if you make a mistake because you chose to ignore the comment, it presumes
that you know EXACTLY (all the way back to DefWindowProc) what is happening.
****
****
Somebody might not want the dialog to resize past a certain limit, so they
would pass saved cx and cy values or just return.
No, what they would do is put a GetMinMaxInfo handler in that would limit the size.
****
So, that code would go before the OnSize() method.****
Then again, that is just an example.
But it is a bad example because it is not the way most people would do it.
****
I am not sure exactly how to keep a dialog from resizing past a certian****
limit.
OnGetMinMaxInfo
****
****
It is not wrong!Well, in this case, you mentioned something wrong, and use it as an
example of what might
have gone wrong. If you ignore the comments, and do something else, then
any errors you
make are your responsibility
It is only wrong if it does the wrong thing. The OP had a situation that did the wrong
thing, because the comment was not honored. It takes experience to know when the values
can be changed. It doesn't help that Microsoft implemented most of MFC incorrectly, and
in the name of "efficiency" changed the meaning of a superclass call so that it didn't
actually work right when the base class was called.
*****
I know what the base class is doing.****
I know where I should be calling the base class.
Fine. But most programmers, especially beginners, don't, and the comments are helpful.
*****
Therefore, when I add my own code and my own comments, I don't have to worry*****
if it is wrong, because it is right.
If I did pay attention to the generic comments, then the code would be
wrong.
You seem to be developing complex solutions to simple problems; for example, changing
OnSize parameters instead of using OnGetMinMaxInfo. When you create complex solutions,
you have to know what you are doing. If you do, that's fine. But those who don't should
pay attention to the comments
****
*****
I was stating that I was intimidated by the TODO comments when I first
started programming MFC.
Becuase I didn't know what the base class was doing and just accepted that
my code should go where
the TODO comment said to put my code.
And that is a good first approximation for most instances. Just because they don't cover
every possible case is not a good reason to ignore the comments.
*****
Joseph M. Newcomer [MVP]
Sorry about your operation and all that.
I have heard the story before.
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- Resizing a CEdit control to fill its parent DialogBox???
- From: Peter Olcott
- Re: Resizing a CEdit control to fill its parent DialogBox???
- From: Nobody
- Re: Resizing a CEdit control to fill its parent DialogBox???
- From: Joseph M . Newcomer
- Re: Resizing a CEdit control to fill its parent DialogBox???
- From: Nobody
- Re: Resizing a CEdit control to fill its parent DialogBox???
- From: Joseph M . Newcomer
- Re: Resizing a CEdit control to fill its parent DialogBox???
- From: Nobody
- Re: Resizing a CEdit control to fill its parent DialogBox???
- From: Joseph M . Newcomer
- Re: Resizing a CEdit control to fill its parent DialogBox???
- From: Nobody
- Resizing a CEdit control to fill its parent DialogBox???
- Prev by Date: Re: keybd_event,clipboard problem
- Next by Date: Re: CFileDialog GetFileName()
- Previous by thread: Re: Resizing a CEdit control to fill its parent DialogBox???
- Next by thread: Re: Resizing a CEdit control to fill its parent DialogBox???
- Index(es):
Relevant Pages
|