Prev: MFC SDI Application without a default “New Document” on Startup
Next: How to handle Windows 7 screen resolution change?
From: David Ching on 21 Apr 2010 10:42
"Oliver Regenfelder" <oliver.regenfelder(a)gmx.at> wrote in message
news:91017$4bcefd03$54772cd9$13933(a)news.inode.at...
> Hello,
>
> David Ching wrote:
>> Rename PEdit to m_edit and make it a member of SAFrame. (Not a pointer,
>> but a CEdit instance). Child windows like this are meant to have member
>> instances and not pointers (due to the way the object is destroyed).
>
> Could you explain this a bit more in detail please? What would be the
> problem if I make it
>
> CEdit* m_edit;
>

Google for "CWnd m_bAutoDelete". It has to do with whether MFC performs a
"delete this" while handling WM_NCDESTROY. For CFrameWnd derived classes,
it does, therefore, it is expected your CFrameWnd derived class is allocated
on the heap (e.g. "new SAFrame"). But it does not with CWnd derived classes
like CEdit. Therefore it is expected your CEdit is allocated on the stack
(e.g. as a member variable of SAFrame).

-- David


From: Joseph M. Newcomer on 21 Apr 2010 10:59
It is not at all clear why a 'new' is required; this is generally the mark of a beginner.

Just declare a varriable
CEdit m_edit;
in the class of the window that is supposed to be the parent of the edit control, and
simpy do
m_edit.Create(...);

The 'new' operator is overused in such contexts. It is almost never needed to create an
instance of a CWnd-derived class (modeless dialog boxes are one of the very few and rare
exceptions to this)
joe

On Wed, 21 Apr 2010 15:26:12 +0200, Oliver Regenfelder <oliver.regenfelder(a)gmx.at> wrote:

>Hello,
>
>David Ching wrote:
>> Rename PEdit to m_edit and make it a member of SAFrame. (Not a pointer,
>> but a CEdit instance). Child windows like this are meant to have member
>> instances and not pointers (due to the way the object is destroyed).
>
>Could you explain this a bit more in detail please? What would be the
>problem if I make it
>
>CEdit* m_edit;
>
>allocate it inside OnCreate
>m_edit = new .... // and so on
>
>and then deallocate it inside the destructor like
>if(m_edit)
> delete m_edit
>
>
>I would be interested especially in windows API/MFC implications of
>doing this not any strictly C++ ones (like use
>std::auto_ptr/std::unique_ptr).
>
>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: Oliver Regenfelder on 21 Apr 2010 12:36
Hello,

Joseph M. Newcomer wrote:
> It is not at all clear why a 'new' is required; this is generally the mark of a beginner.

I didn't say that a new is required, I know that I can do things on the
stack and be saved from some problems already C++ wise.
The intend of my question was to figure out why the new is a bad Idea in
terms of MFC/Win API interaction. Partly because I have to deal with
code who does such things, and partly to enrich my understanding of the
underlying technology.

Best regards,

Oliver
From: Joseph M. Newcomer on 21 Apr 2010 12:41
No, you can't do it on the stack. If you do, when the variable goes out of scope, the
window disappears (not for a pointer on the stack, which puts the object on the heap).

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.
joe

On Wed, 21 Apr 2010 18:36:53 +0200, Oliver Regenfelder <oliver.regenfelder(a)gmx.at> wrote:

>Hello,
>
>Joseph M. Newcomer wrote:
>> It is not at all clear why a 'new' is required; this is generally the mark of a beginner.
>
>I didn't say that a new is required, I know that I can do things on the
>stack and be saved from some problems already C++ wise.
>The intend of my question was to figure out why the new is a bad Idea in
>terms of MFC/Win API interaction. Partly because I have to deal with
>code who does such things, and partly to enrich my understanding of the
>underlying technology.
>
>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: Oliver Regenfelder on 21 Apr 2010 14:51
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.

> 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
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.

Best regards,

Oliver
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?