Discussion:
enum { IDD = something} public or not?
(too old to reply)
Oliver Regenfelder
2011-07-22 08:42:47 UTC
Permalink
Hello,

Should the

enum { IDD = IDD_SOME_VALUE }

entry of an MFC class be public or can it also
be protected, or private?

Best regards,

Oliver
Stuart Redmann
2011-07-22 15:45:10 UTC
Permalink
Post by Oliver Regenfelder
Hello,
Should the
enum { IDD = IDD_SOME_VALUE }
entry of an MFC class be public or can it also
be protected, or private?
I guess the dialog ID is made public because you may want to create
the dialog modeless through CDialog::Create, and one of the overloaded
versions of Create needs the dialog ID. Since the modeless creation of
CDialog seems quite defective (CDialog behaves as if it is always
created as modal dialog, unless you overwrite the OnOkey/OnCancel
handlers), this is probably a relict from the olden days. If you only
ever use your dialogs as modal dialogs, you should be save to declare
the IDD private/protected.

Regards,
Stuart
Joseph M. Newcomer
2011-07-24 21:51:39 UTC
Permalink
See below...
Post by Stuart Redmann
Post by Oliver Regenfelder
Hello,
Should the
enum { IDD = IDD_SOME_VALUE }
entry of an MFC class be public or can it also
be protected, or private?
I guess the dialog ID is made public because you may want to create
the dialog modeless through CDialog::Create, and one of the overloaded
versions of Create needs the dialog ID. Since the modeless creation of
CDialog seems quite defective (CDialog behaves as if it is always
created as modal dialog, unless you overwrite the OnOkey/OnCancel
handlers), this is probably a relict from the olden days. If you only
ever use your dialogs as modal dialogs, you should be save to declare
the IDD private/protected.
****
I have no idea what this paragraph is trying to say, because a lot of it is complete
nonsense.

A dialog is created modal if you call DoModal. It is created as modeless if you do
CDialog::Create using the symbol IDD, .e.g,
CDialog * modeless; // in the class definition

void CSomething::CreateMyModelessDialog()
{
ASSERT(modeless == NULL); // don't forget to initialize it!
// or, if you don't want to do the extra work to disable the dialog creation, see
below
modeless = new CMyDialog;
modeless->Create(IDD);


Another way to handle it is

void CSomething::CreateMyModelessDialog()
{
if(modeless != NULL)
{
modeless->ShowWindow(SW_RESTORE);
modeless->ShowWindow(SW_SHOW);
}
else
{
...create as shown previously
}

it is frequently desirable to "dismiss" the modeless dialog by overriding OnClose:

void CMyDialog::OnClose()
{
ShowWindow(SW_HIDE):
}

The statement that CDialog behaves as if it is always created as modal unless you override
(not overwrite!) CDialog::OnOK and CDialog::Cancel is complete and utter gibberish. The
rule is that a modal dialog terminates by calling EndDialog() and a modeless dialog
terminates by calling DestroyWindow, so the only reason you need to override (not
overwrite!) OnOK and OnCancel is to make sure they do NOT call EndDialog, which would
cause erroneous behavior. This is not a "relic", it is how dialogs are defined to work!

Note that you should do

void CMyDialog::PostNcDestroy()
{
... stuff
delete this;
}

and this means you had better have a way to set that variable to NULL. Importing the
class definition that has that variable would be erroneous program construction, and the
correct form is to typically do

PostNcDestroy:
...stuff
parent->SendMessage(UWM_I_HAVE_BEEN_CLOSED);
delete this;
}

where parent is a CWnd * (not a CView*, or CMainFrame*, or anything OTHER that a CWnd *)
in which you store the pointer to the window to be notified of closure:

LRESULT CWhatever::OnIHaveBeenClosed(WPARAM, LPARAM)
{
modeless = NULL;
return 0;
}

See my essay on message management on my MVP Tips site.
joe
****
Post by Stuart Redmann
Regards,
Stuart
Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
2011-07-22 17:29:00 UTC
Permalink
This must be public.
joe
Post by Oliver Regenfelder
Hello,
Should the
enum { IDD = IDD_SOME_VALUE }
entry of an MFC class be public or can it also
be protected, or private?
Best regards,
Oliver
Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
David Webber
2011-07-22 22:41:58 UTC
Permalink
Hi Joe,

I don't normally argue with you <g> but why? I couldn't see any reason why
it should be, so, following your message, and I just changed one of mine to
private and it seems to compile and run well enough.

Dave

-- David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm

"Joseph M. Newcomer" wrote in message news:***@4ax.com...

This must be public.
joe

On Fri, 22 Jul 2011 10:42:47 +0200, Oliver Regenfelder
Post by Oliver Regenfelder
Hello,
Should the
enum { IDD = IDD_SOME_VALUE }
entry of an MFC class be public or can it also
be protected, or private?
Best regards,
Oliver
Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
2011-07-24 22:00:30 UTC
Permalink
Sorry, I was rushing off to a critical health meeting and this was the simplest answer. Of
course, it really depends on whether or not you need it outside the class, which any C++
programmer should have known the answer to anyway.
joe
Post by David Webber
Hi Joe,
I don't normally argue with you <g> but why? I couldn't see any reason why
it should be, so, following your message, and I just changed one of mine to
private and it seems to compile and run well enough.
Dave
-- David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
This must be public.
joe
On Fri, 22 Jul 2011 10:42:47 +0200, Oliver Regenfelder
Post by Oliver Regenfelder
Hello,
Should the
enum { IDD = IDD_SOME_VALUE }
entry of an MFC class be public or can it also
be protected, or private?
Best regards,
Oliver
Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

David Webber
2011-07-22 16:56:20 UTC
Permalink
Post by Oliver Regenfelder
Should the
enum { IDD = IDD_SOME_VALUE }
entry of an MFC class be public or can it also
be protected, or private?
The only place it is used (I think) is in the constructor of the CDialog
base class of your dialogue box class. So unless you want to use it
yourself from outside the dialogue box, it should be fine to make it
protected or private.

In fact a lot of dialogue variables which the class wizard creates as public
can be made private (as long as you provide any get and set methods you may
need). Microsoft have not always been too keen on protecting data in
classes :-)

Dave

-- David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Goran
2011-07-23 04:57:54 UTC
Permalink
Post by Oliver Regenfelder
Hello,
Should the
enum { IDD = IDD_SOME_VALUE }
entry of an MFC class be public or can it also
be protected, or private?
Private.

Why?

I bet you that in a vast majority of cases, using a dialog boils down
to this:

CSomeDlg d;
SetDialogData(data, d);
if (d.DoModal())
GetDialogData(newData, d);

If so, then any code that even sees CSomeDlg has a silly dependency.
CSomeDlg could even be in a *.cpp, and it's use should be e.g.

extern auto_ptr<CSomeDialogData> Edit(const CSomeDialogData&
original);

auto_ptr<CSomeDialogData> PNewData = Edit(data);
if (PNewData.get())
TakeNewData(*PNewData);

I also bet you that in a majority of cases when your dialog isn't
modal, you can easily get away from not seeing it's complete
implementation, and ending in a better code.

Goran.

Goran.
David Webber
2011-07-23 09:14:02 UTC
Permalink
Post by Goran
....
I also bet you that in a majority of cases when your dialog isn't
modal, you can easily get away from not seeing it's complete
implementation, and ending in a better code. <

I wrap *all* my dialogues in functions - schematically:

BOOL editThisAndThat( int &nThis, int &nThat, CWnd *pParent )
{
BOOL bResult = FALSE;

// Set the resource handle here to the module which
// corresponds with the language in use
...


CDgThisAndThatEditor dgThisAndThatEditor( nThis, nThat, pParent );

if( dgThisAndThatEditor.DoModal()==IDOK )
{
nThis = dgThisAndThatEditor.getThis();
nThat = dgThisAndThatEditor.getThat();
bResult =TRUE;
}

// Set previous resource handle here
....

return bResult;
}


It means that practically all aspects of the dialogue class (apart from the
constructor, and get functions) can be private. I prefer it that way.

Dave

-- David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Loading...