Prev: MFC SDI Application without a default “New Document” on Startup
Next: How to handle Windows 7 screen resolution change?
From: Joseph M. Newcomer on 22 Apr 2010 00:11
See below...
On Wed, 21 Apr 2010 20:51:07 +0200, Oliver Regenfelder <oliver.regenfelder(a)gmx.at> wrote:

>Hello,
>
>Joseph M. Newcomer wrote:
>> No, you can't do it on the stack.
>
>Sorry for the wrong formulation. I actually ment non pointer member
>variable instead of a stack variable.
****
I use non-pointer member variables all the time for this and have never had a problem.
****
>
>> THere is no reason to go around creating objects dynamically if you can create them
>> without 'new'. You want the objects to be self-destructing when the containing object is
>> deleted. Every time you create a 'new' object on the heap, you create an opportunity for
>> a storage leak.
>
>I know, that is why I mentioned that 'besides C++ problem' stuff. What I
>am interested in are special windows/MFC problems which might occure if
>,lets say, I do use a member pointer variable for a control like CEdite*
>allocate with new in the constructor and deallocate with delete in the
>destructor of the window containing the CEdit. I know that this is not
****
It is a common mistake to put code like this into constructors or destructors. These are
precisely the WRONG place to put code like this! You must not create windows in the
constructor because the parent window does not exist, and you must not do the delete in
the destructor because the parent has already been destroyed, taking the child window with
it.

If you do use the pointer technique, which I consider poor practice, you must do a
DestroyWindow on the control in the OnDestroy handler of the parent window, and in the
PostNcDestroy handler of the control should say
delete this

but this is poor practice to use dynamic allocation without any good reason.
****
>a good Idea - I just want to know whether this also triggers some
>strange Windows Problems (as David Ching already suggested). I did
>some googling about this CWnd m_bAutoDelete but couldn't find any
>truly helpful stuff.
****
If you just declare a non-pointer variable you don't have ANY of these problems! Better
still, you place the control at design time, especially for a CEdit.
joe
****
>
>Best regards,
>
>Oliver
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Saint Atique on 22 Apr 2010 00:53
You people are genius. I wonder how had you been?

Can you recommend me a book that will teach me these simple but
interesting things?
From: David Ching on 22 Apr 2010 10:41
"Saint Atique" <unix9n(a)gmail.com> wrote in message
news:9afd1444-ac44-4156-afd3-76c39fb8106c(a)y14g2000yqm.googlegroups.com...
> You people are genius. I wonder how had you been?
>
> Can you recommend me a book that will teach me these simple but
> interesting things?

Ivor Horton's "Beginning Visual C++ 2010"

He also has versions for 2005 and 2008.

-- David

From: Oliver Regenfelder on 23 Apr 2010 03:33
Hello,

Joseph M. Newcomer wrote:
> ****
> I use non-pointer member variables all the time for this and have never had a problem.

Me too. The question was more out of interest and for deeper
understanding which I should have pointed out more clearly.

> It is a common mistake to put code like this into constructors or destructors. These are
> precisely the WRONG place to put code like this! You must not create windows in the
> constructor because the parent window does not exist, and you must not do the delete in
> the destructor because the parent has already been destroyed, taking the child window with
> it.
>
> If you do use the pointer technique, which I consider poor practice, you must do a
> DestroyWindow on the control in the OnDestroy handler of the parent window, and in the
> PostNcDestroy handler of the control should say
> delete this

Thanks for the explanation.

> If you just declare a non-pointer variable you don't have ANY of these problems! Better
> still, you place the control at design time, especially for a CEdit.

I normaly place them inside the Dialog editor (or edit the .rc) file and
generate the necessary control/value variables. Then mostly one day
later I figure I have accidentaly made them public and then change them
to protected (worst default settings ever...).

Best regards,

Oliver
From: Joseph M. Newcomer on 23 Apr 2010 21:57
See below...
On Fri, 23 Apr 2010 09:33:02 +0200, Oliver Regenfelder <oliver.regenfelder(a)gmx.at> wrote:

>Hello,
>
>Joseph M. Newcomer wrote:
>> ****
>> I use non-pointer member variables all the time for this and have never had a problem.
>
>Me too. The question was more out of interest and for deeper
>understanding which I should have pointed out more clearly.
>
>> It is a common mistake to put code like this into constructors or destructors. These are
>> precisely the WRONG place to put code like this! You must not create windows in the
>> constructor because the parent window does not exist, and you must not do the delete in
>> the destructor because the parent has already been destroyed, taking the child window with
>> it.
>>
>> If you do use the pointer technique, which I consider poor practice, you must do a
>> DestroyWindow on the control in the OnDestroy handler of the parent window, and in the
>> PostNcDestroy handler of the control should say
>> delete this
>
>Thanks for the explanation.
>
>> If you just declare a non-pointer variable you don't have ANY of these problems! Better
>> still, you place the control at design time, especially for a CEdit.
>
>I normaly place them inside the Dialog editor (or edit the .rc) file and
>generate the necessary control/value variables. Then mostly one day
>later I figure I have accidentaly made them public and then change them
>to protected (worst default settings ever...).
***
In the entire history of MFC, all the way back to Win16 versions, there has NEVER been a
sensible reason to EVER make a control variable or an event handler 'public'. But the
poor design and implementation of the ClassWizard parser required that all this stuff be
together. Instead of excercising any form of intelligent design (we know software must
'evolve' because we see no trace of intelligent design) when the new parser was written,
Microsoft chose to leave these as 'public', which is simply stupid. I hand-edit my .h
files to make EVERYTHING which does not NEED to be 'public' be 'protected' (sadly, some
beginners confuse 'protected' with 'private' and make everything 'private', which is just
about as stupid, since you will not be able to derive a subclass from this.)

The default is a horrible choice, and the randomization of the .h file (things appear in
the order they are added, instead of being grouped intelligently) is another horrible
choice.

But that's why we have text editors.

"Parameterization is how we deal with anticipated change. The way we deal with
unanticipated change is a text editor" -- Brian Kernighan
joe
****
>
>Best regards,
>
>Oliver
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: MFC SDI Application without a default “New Document” on Startup
Next: How to handle Windows 7 screen resolution change?