enum { IDD = IDD_DIALOG};
-
why dialog box ID is enumerated as the IDD member? Is there any special reason that it is enumerated?
KIRAN PINJARLA
-
why dialog box ID is enumerated as the IDD member? Is there any special reason that it is enumerated?
KIRAN PINJARLA
Because macros suck, unless there in no better solution. In this case there is. For example, macros can't be
classmembers but anenumcan (and in this case is).Steve
-
why dialog box ID is enumerated as the IDD member? Is there any special reason that it is enumerated?
KIRAN PINJARLA
Not exactly sure, but I think has mostly to do with the wizards that create the dialog classes, because as far as I can tell, IDD is is only passed to the constructor of CDialog as the resource ID. I could be way wrong of course...
- S 50 cups of coffee and you know it's on!
-
Because macros suck, unless there in no better solution. In this case there is. For example, macros can't be
classmembers but anenumcan (and in this case is).Steve
Stephen Hewitt wrote:
Because macros suck,
:| Why? If we use macros carefully they are very helpful. Mainly because of irrational use most of the BUGs happen. For me macros are indispensable.
Nibu thomas A Developer Programming tips[^] My site[^]
-
why dialog box ID is enumerated as the IDD member? Is there any special reason that it is enumerated?
KIRAN PINJARLA
It's how the Class Wizard recognises and remembers which classes are tied to which dialogs. If you remove that line, Class Wizard won't recognise which dialog belongs to the class any more.
-- Help me! I'm turning into a grapefruit! Buzzwords!
-
Stephen Hewitt wrote:
Because macros suck,
:| Why? If we use macros carefully they are very helpful. Mainly because of irrational use most of the BUGs happen. For me macros are indispensable.
Nibu thomas A Developer Programming tips[^] My site[^]
As I said, if there is no better solution macros are fine. But there are many problems with them and they’re overused by many C/C++ programmers. Some of the problems with them are: - Can’t be overloaded. - Make debugging harder. - Don’t obey C/C++ scoping rules. - Can cause nasty side effects. All of these problems with macros – and more besides – are well known.
Steve
-
As I said, if there is no better solution macros are fine. But there are many problems with them and they’re overused by many C/C++ programmers. Some of the problems with them are: - Can’t be overloaded. - Make debugging harder. - Don’t obey C/C++ scoping rules. - Can cause nasty side effects. All of these problems with macros – and more besides – are well known.
Steve
Stephen Hewitt wrote:
- Can’t be overloaded.
They are not meant to be overloaded. If that's the purpose there are functions we should use them.
Stephen Hewitt wrote:
- Make debugging harder.
TRUE.
Stephen Hewitt wrote:
- Don’t obey C/C++ scoping rules.
Macros were not made for this purpose. They acts as just pure inline code replacement routine. If not used carefully ....
Stephen Hewitt wrote:
- Can cause nasty side effects.
TRUE. They should be extremely well written. :)
Nibu thomas A Developer Programming tips[^] My site[^]
-
It's how the Class Wizard recognises and remembers which classes are tied to which dialogs. If you remove that line, Class Wizard won't recognise which dialog belongs to the class any more.
-- Help me! I'm turning into a grapefruit! Buzzwords!
Yup, and this now ties the resource file (with every resource) to the header, so any user of the header had to re-compile, any time any resource element changes, no matter how unrelated....
