=?Utf-8?Q?Re:_Why_we_have_seperate_Create=28?= =?Utf-8?Q?=E2=80=A6=29_in_MFC?=

From:

"Tom Serface" <tom@nospam.camaswood.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Tue, 6 Jan 2009 10:45:25 -0800

Message-ID:

<EBB46ADA-F162-4205-97E9-4DB94DD81EFD@microsoft.com>

Yes, sometimes there is a fine line between "error" and "something that is
not necessarily the smartest way to do it" :o)

Tom

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:6247m490oqiafipoiqt1m319qsgnjcl5rf@4ax.com...

I have no problem with that scenario. And how often does it occur? Right.
That's my
point.
joe

On Mon, 05 Jan 2009 23:21:19 +0100, Colin Peters <cpeters@coldmail.com>
wrote:

Tom Serface wrote:

I think you guys are just talking a matter of perspective.

Tom,

Not just. There are circumstances where adding a control at design time
won't work. Not for a button, but take the following example:

You have an ActiveX component and you're not sure if the ActiveX will be
available at runtime (maybe you're not in control of the install). If
you put the ActiveX on the dialog at design time and try to run without
the OCX then your program will terminate. If you add the control at
runtime, only after having checked if the OCX is available, then your
dialog will still show, albeit with an empty space where the control
would have been.

Another example is when you don't know how many buttons you need until
runtime. You could of course add more buttons than you need then hide
the excess, but that's not very elegant.

Another example is when you want to implement a dialog in a static
library without having to include bits of rc text in the consuming exe.

Another example is where you don't want to reveal to Spy users what
buttons are potentially available (and their command IDs) if the user
pays the full licence.

I admit that these are not mainstream uses, but to dismiss dynamic
creation as erroneous is....well...erroneous.

Creatinga

button with 'new' requires a corresponding 'delete' somewhere along the
line so it's often easiest to just include the control as a member in
the dialog or view class even if the window is to be dynamically
created. The wrappers for the control are pretty small so, from my
perspective, the convenience is worth the very small cost.

That said, allocating memory for a control object is certainly as legal
as allocating memory for any other kind of object. At the end of the
day someone is allocating the memory even if we don't do it ourselves.

Tom

"Colin Peters" <cpeters@coldmail.com> wrote in message
news:4962800a$1_2@news.bluewin.ch...

Joe,

It's not an error to dynamically create a control. (Unless you didn't
mean to do it in the first place!) And there's lots of circumstances
where dynamic creation is appropriate. Showing/hiding controls has
its' place too, and more often than not it more convenient to do this.
But there's definitely no error in adding a control at runtime.

Joseph M. Newcomer wrote:

It's simple, really. There is a difference between a C++ object and
a kernel object.
Declaring a C++ object declares a C++ object; it does not create the
kernel object that
goes along with it. There are many reasons you would want to
decouple these, such as
needing a variable that represents an existing object.

If it created the button, you would need a separate constructor, that
included parameters
such as the control ID, control rectangle, and parent window.
Therefore, you would not
write

CButton button;

you would write

CButton button(rect, id, this);

or

CButton * button = new CButton(rect, id this);

Note that there are many reasons you want to create pointers to
objects, but be aware that
it is a common beginner's error to think that you have to use 'new'
everywhere, such as
dynamically creating a button. Dynamically creating a button is a
separare concept from
dynamically creating a window, and it is not at all uncommon to have
a structure that
contains a CButton, and you create the structure first (such as a
CDialog-derived class)
and only later create the button object and bind it to the variable.
In addition, there
is another common error: if you want a control to be optional, there
is a belief that you
only create it if you need it. Instead, the typical practice is to
create it at design
time, mark it as invisible/disabled in either the dialog editor or
OnInitDialog, and do a
ShowWindow(SW_SHOW)/EnableWindow(TRUE) when you need it.

So what is it you are actually trying to accomplish?
joe
****
On Mon, 5 Jan 2009 10:11:43 -0800 (PST), Mishra <mt.vijay@gmail.com>
wrote:

Hi All,
I have one question which is not regarding any compilation or logical
issue. It is related to MFC.

In below code,

CButton *pbutton = new CButton; // Just to create object;
Pbutton->create(.) // to create actual button control.

Anyone has idea that what the purpose of having separate Create(.)
function in MFC?
I mean, we could have different CButton Constructor which would
initialize and create Button control also. Then why we have different
function "Create"

Button control can be created using CButton constructor if MFC would
have allowed us.

Thanks,
Mishra

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm