Activating the class wizard on a derived-derived Cwnd class 
Author Message
 Activating the class wizard on a derived-derived Cwnd class

Take a look at this class hierarchy:

class COpenGlWnd:public CWnd {
....

Quote:
}

class COpenVrmlWnd:public COpenGlWnd {
....

Quote:
}

Both of them are inserted with the Insert->New class menu option but,

while the first class in the Hierarchy (COpenGlWnd) is recognized by
the classwizard it seems i can't activate the classwizard on
COpenVrmlWnd.

Is there a way to have the classwizard working also with COpenVrmlWnd
or shall i resign to add any message map and virtual functions
ovveride by hand??

Regards
Luca Regini



Fri, 02 Apr 2004 15:15:31 GMT  
 Activating the class wizard on a derived-derived Cwnd class
This is a defect in ClassWizard; it won't go down more than one level
in the hierarchy. Create it as a subclass of CWnd and change it by
hand.
                        joe



Quote:
>Take a look at this class hierarchy:

>class COpenGlWnd:public CWnd {
>....
>}

>class COpenVrmlWnd:public COpenGlWnd {
>....
>}

>Both of them are inserted with the Insert->New class menu option but,

>while the first class in the Hierarchy (COpenGlWnd) is recognized by
>the classwizard it seems i can't activate the classwizard on
>COpenVrmlWnd.

>Is there a way to have the classwizard working also with COpenVrmlWnd
>or shall i resign to add any message map and virtual functions
>ovveride by hand??

>Regards
>Luca Regini

Joseph M. Newcomer [MVP]

Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm


Sat, 03 Apr 2004 01:00:23 GMT  
 Activating the class wizard on a derived-derived Cwnd class

Quote:
> This is a defect in ClassWizard; it won't go down more than one level
> in the hierarchy. Create it as a subclass of CWnd and change it by
> hand.
>                    joe

Thanks for ur suggestion.
I prefer to go on adding message maps and stuff by hand: the benefits
i get from my design are much more higher than some automatic editing.
It's awkward to do so but the MFC framework works anyway , with or
without  classwizard's help.

Regards
Luca



Sat, 03 Apr 2004 15:56:34 GMT  
 Activating the class wizard on a derived-derived Cwnd class
Class wizard won't let you create a control typ member variable of a control more than one
level below a MFC class.

However, it will let you select the class so you can use class wizard to add message
handlers, you don't have to do this by hand.

If the class doesn't show in class wizard, try deleting the .clw file for your project and
let visual studio recreate the .clw file (press ctrl+w and answer OK to everything).

Ruben


Quote:
>This is a defect in ClassWizard; it won't go down more than one level
>in the hierarchy. Create it as a subclass of CWnd and change it by
>hand.
>                    joe



>>Take a look at this class hierarchy:

>>class COpenGlWnd:public CWnd {
>>....
>>}

>>class COpenVrmlWnd:public COpenGlWnd {
>>....
>>}

>>Both of them are inserted with the Insert->New class menu option but,

>>while the first class in the Hierarchy (COpenGlWnd) is recognized by
>>the classwizard it seems i can't activate the classwizard on
>>COpenVrmlWnd.

>>Is there a way to have the classwizard working also with COpenVrmlWnd
>>or shall i resign to add any message map and virtual functions
>>ovveride by hand??

>>Regards
>>Luca Regini

>Joseph M. Newcomer [MVP]

>Web: http://www3.pgh.net/~newcomer
>MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm



Sat, 03 Apr 2004 18:54:50 GMT  
 Activating the class wizard on a derived-derived Cwnd class
Bad idea. It is a lot easier to edit a couple names than worry about
all the details of creating message maps by hand, and once you've
modified the class, ClassWizard will be happy to continue working with
it. Why waste time? In six years of MFC programming, I've never felt
that ignoring the tools gave me any benefits. Sometimes you work
around them, but the workarounds are so much less effort than ignoring
them that ignoring them makes no sense. (When I was in industry,
another Career Limiting Move on the part of one of my people was to
say "I don't need no stinkin' tools, I can do this myself" He got a
VERY bad annual review, since everyone on the committee thought this
was really dumb, and shortly thereafter left the company).
                                joe



Quote:

>> This is a defect in ClassWizard; it won't go down more than one level
>> in the hierarchy. Create it as a subclass of CWnd and change it by
>> hand.
>>                        joe

>Thanks for ur suggestion.
>I prefer to go on adding message maps and stuff by hand: the benefits
>i get from my design are much more higher than some automatic editing.
>It's awkward to do so but the MFC framework works anyway , with or
>without  classwizard's help.

>Regards
>Luca

Joseph M. Newcomer [MVP]

Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm


Sun, 04 Apr 2004 01:15:18 GMT  
 Activating the class wizard on a derived-derived Cwnd class
Well, i have 9 types of openvrmlwnds that i can use in my application
and all of them share a lot of common code. By adding some mfc maps by
hand i have to write little code to add functionality to the classes.
If i follow ur suggestion than i have to cut and paste 5 pages of code
for each type of window.
The c++ OOP way is to share common code in base classes and not to cut
and paste stuff around.
Regarding ur carrer considerations yes i agree with u and the point of
view u bring is correct. If I had been working at Microsoft ( which is
one of my secret dreams...) i would follow  strictly the company
directions; anyway i work in research so i am my own production
manager and in my opinion the benefits i get from using more levels of
inheritance are higher than that i get from being able to use
classwizard. If i am ever going to change this code ( which in fact is
quite probable) i'll have to concentrate only on one file and not on 9
different files. Moreover if i'll be wrong i'll be the only one to pay
and it wont be my company, my manager or someone else.

P.S: I have already done what i've said, adding mfc maps is as easy as
cutting and pasting code but 10 rows instead of 5 pages. By the way
the code works fine: MFC has nothing to do with classwizard.

Luca


Quote:
> Bad idea. It is a lot easier to edit a couple names than worry about
> all the details of creating message maps by hand, and once you've
> modified the class, ClassWizard will be happy to continue working with
> it. Why waste time? In six years of MFC programming, I've never felt
> that ignoring the tools gave me any benefits. Sometimes you work
> around them, but the workarounds are so much less effort than ignoring
> them that ignoring them makes no sense. (When I was in industry,
> another Career Limiting Move on the part of one of my people was to
> say "I don't need no stinkin' tools, I can do this myself" He got a
> VERY bad annual review, since everyone on the committee thought this
> was really dumb, and shortly thereafter left the company).
>                            joe




> >> This is a defect in ClassWizard; it won't go down more than one level
> >> in the hierarchy. Create it as a subclass of CWnd and change it by
> >> hand.
> >>                   joe

> >Thanks for ur suggestion.
> >I prefer to go on adding message maps and stuff by hand: the benefits
> >i get from my design are much more higher than some automatic editing.
> >It's awkward to do so but the MFC framework works anyway , with or
> >without  classwizard's help.

> >Regards
> >Luca

> Joseph M. Newcomer [MVP]

> Web: http://www3.pgh.net/~newcomer
> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm



Mon, 05 Apr 2004 15:28:00 GMT  
 Activating the class wizard on a derived-derived Cwnd class
If they have common code, why are they not subclasses of each other?
If you have that much code in common, it strongly suggests that the
code should be in a superclass. Note that none of this requires
hand-editing a message map, because the subclasses inherit the
behavior of the superclasses, including message maps. This does not
seem inconsistent with your assertion that OOP is the way to share
common code. I do  this quite often, and never have to hand-edit the
message maps. Using ClassWizard is in no way inconsistent with
multiple levels of inheritance. You shouldn't have to cut and paste
anything (I don't).
                        joe



Quote:
>Well, i have 9 types of openvrmlwnds that i can use in my application
>and all of them share a lot of common code. By adding some mfc maps by
>hand i have to write little code to add functionality to the classes.
>If i follow ur suggestion than i have to cut and paste 5 pages of code
>for each type of window.
>The c++ OOP way is to share common code in base classes and not to cut
>and paste stuff around.
>Regarding ur carrer considerations yes i agree with u and the point of
>view u bring is correct. If I had been working at Microsoft ( which is
>one of my secret dreams...) i would follow  strictly the company
>directions; anyway i work in research so i am my own production
>manager and in my opinion the benefits i get from using more levels of
>inheritance are higher than that i get from being able to use
>classwizard. If i am ever going to change this code ( which in fact is
>quite probable) i'll have to concentrate only on one file and not on 9
>different files. Moreover if i'll be wrong i'll be the only one to pay
>and it wont be my company, my manager or someone else.

>P.S: I have already done what i've said, adding mfc maps is as easy as
>cutting and pasting code but 10 rows instead of 5 pages. By the way
>the code works fine: MFC has nothing to do with classwizard.

>Luca


>> Bad idea. It is a lot easier to edit a couple names than worry about
>> all the details of creating message maps by hand, and once you've
>> modified the class, ClassWizard will be happy to continue working with
>> it. Why waste time? In six years of MFC programming, I've never felt
>> that ignoring the tools gave me any benefits. Sometimes you work
>> around them, but the workarounds are so much less effort than ignoring
>> them that ignoring them makes no sense. (When I was in industry,
>> another Career Limiting Move on the part of one of my people was to
>> say "I don't need no stinkin' tools, I can do this myself" He got a
>> VERY bad annual review, since everyone on the committee thought this
>> was really dumb, and shortly thereafter left the company).
>>                                joe




>> >> This is a defect in ClassWizard; it won't go down more than one level
>> >> in the hierarchy. Create it as a subclass of CWnd and change it by
>> >> hand.
>> >>                       joe

>> >Thanks for ur suggestion.
>> >I prefer to go on adding message maps and stuff by hand: the benefits
>> >i get from my design are much more higher than some automatic editing.
>> >It's awkward to do so but the MFC framework works anyway , with or
>> >without  classwizard's help.

>> >Regards
>> >Luca

>> Joseph M. Newcomer [MVP]

>> Web: http://www3.pgh.net/~newcomer
>> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

Joseph M. Newcomer [MVP]

Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm


Wed, 07 Apr 2004 00:09:41 GMT  
 Activating the class wizard on a derived-derived Cwnd class
To be honest i simply didnt consider to put all possible windows
messagges in a superclass....

The main difference from class to class lies in the messages that a
window is supposed to react to: for example i have one window for
offscreen rendering ( a rough substition for p-buffers for videocards
that dont have them..) and that class is not supposed to react to any
user-interface event, another class has browser functionality so it
has to deal with keyboard and mouse messages.
I simply didnt consider to put all possible messagges in a superclass
and was instead simply focused on adding a messagge map to every
class.
Ur suggestion is good and i can think of only 2 very sligth defects :
1) the message mapping code is separated from the class code
2) there can be a very sligth overhead when a message is trapped for a
window that isnt supposed to react to it ( we get an empty call).

Anyway i think that ur proposed solution is the best possible and it
will be the one i'll use.

Thx

P.S: sorry for my bad english.

Luca


Quote:
> If they have common code, why are they not subclasses of each other?
> If you have that much code in common, it strongly suggests that the
> code should be in a superclass. Note that none of this requires
> hand-editing a message map, because the subclasses inherit the
> behavior of the superclasses, including message maps. This does not
> seem inconsistent with your assertion that OOP is the way to share
> common code. I do  this quite often, and never have to hand-edit the
> message maps. Using ClassWizard is in no way inconsistent with
> multiple levels of inheritance. You shouldn't have to cut and paste
> anything (I don't).
>                    joe



> >Well, i have 9 types of openvrmlwnds that i can use in my application
> >and all of them share a lot of common code. By adding some mfc maps by
> >hand i have to write little code to add functionality to the classes.
> >If i follow ur suggestion than i have to cut and paste 5 pages of code
> >for each type of window.
> >The c++ OOP way is to share common code in base classes and not to cut
> >and paste stuff around.
> >Regarding ur carrer considerations yes i agree with u and the point of
> >view u bring is correct. If I had been working at Microsoft ( which is
> >one of my secret dreams...) i would follow  strictly the company
> >directions; anyway i work in research so i am my own production
> >manager and in my opinion the benefits i get from using more levels of
> >inheritance are higher than that i get from being able to use
> >classwizard. If i am ever going to change this code ( which in fact is
> >quite probable) i'll have to concentrate only on one file and not on 9
> >different files. Moreover if i'll be wrong i'll be the only one to pay
> >and it wont be my company, my manager or someone else.

> >P.S: I have already done what i've said, adding mfc maps is as easy as
> >cutting and pasting code but 10 rows instead of 5 pages. By the way
> >the code works fine: MFC has nothing to do with classwizard.

> >Luca


> >> Bad idea. It is a lot easier to edit a couple names than worry about
> >> all the details of creating message maps by hand, and once you've
> >> modified the class, ClassWizard will be happy to continue working with
> >> it. Why waste time? In six years of MFC programming, I've never felt
> >> that ignoring the tools gave me any benefits. Sometimes you work
> >> around them, but the workarounds are so much less effort than ignoring
> >> them that ignoring them makes no sense. (When I was in industry,
> >> another Career Limiting Move on the part of one of my people was to
> >> say "I don't need no stinkin' tools, I can do this myself" He got a
> >> VERY bad annual review, since everyone on the committee thought this
> >> was really dumb, and shortly thereafter left the company).
> >>                           joe




> >> >> This is a defect in ClassWizard; it won't go down more than one level
> >> >> in the hierarchy. Create it as a subclass of CWnd and change it by
> >> >> hand.
> >> >>                  joe

> >> >Thanks for ur suggestion.
> >> >I prefer to go on adding message maps and stuff by hand: the benefits
> >> >i get from my design are much more higher than some automatic editing.
> >> >It's awkward to do so but the MFC framework works anyway , with or
> >> >without  classwizard's help.

> >> >Regards
> >> >Luca

> >> Joseph M. Newcomer [MVP]

> >> Web: http://www3.pgh.net/~newcomer
> >> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

> Joseph M. Newcomer [MVP]

> Web: http://www3.pgh.net/~newcomer
> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm



Wed, 07 Apr 2004 17:12:34 GMT  
 Activating the class wizard on a derived-derived Cwnd class
All you put in the superclass are the methods it is supposed to
handle. For example, I have a dialog superclass that handles some
controls that appear on each property page, and in that superclass I
define the member variables for those controls and all the handlers.

In a subclass, I may also need to react to, say, a change in the
combobox that appears in each property page. So I put an OnSelEndOK
handler in my subclass, and it calls the superclass handler, then does
its thing, e.g.,

void CMySubclass::OnSelEndOKOptions()
    {
     CMySuperClass::OnSelEndOKOptions();
     ...make the changes I want to change here...
     updateControls(); // update local controls
    }

void CMySubclass::updateControls()
    {
     CMySuperclass::updateControls();
     ...enable, disable, hide, show, etc...
     }

Message maps, virtual methods, and superclasses are a real help in
code sharing. I have some classes that are eight deep.
                        joe



Quote:
>To be honest i simply didnt consider to put all possible windows
>messagges in a superclass....

>The main difference from class to class lies in the messages that a
>window is supposed to react to: for example i have one window for
>offscreen rendering ( a rough substition for p-buffers for videocards
>that dont have them..) and that class is not supposed to react to any
>user-interface event, another class has browser functionality so it
>has to deal with keyboard and mouse messages.
>I simply didnt consider to put all possible messagges in a superclass
>and was instead simply focused on adding a messagge map to every
>class.
>Ur suggestion is good and i can think of only 2 very sligth defects :
>1) the message mapping code is separated from the class code
>2) there can be a very sligth overhead when a message is trapped for a
>window that isnt supposed to react to it ( we get an empty call).

>Anyway i think that ur proposed solution is the best possible and it
>will be the one i'll use.

>Thx

>P.S: sorry for my bad english.

>Luca


>> If they have common code, why are they not subclasses of each other?
>> If you have that much code in common, it strongly suggests that the
>> code should be in a superclass. Note that none of this requires
>> hand-editing a message map, because the subclasses inherit the
>> behavior of the superclasses, including message maps. This does not
>> seem inconsistent with your assertion that OOP is the way to share
>> common code. I do  this quite often, and never have to hand-edit the
>> message maps. Using ClassWizard is in no way inconsistent with
>> multiple levels of inheritance. You shouldn't have to cut and paste
>> anything (I don't).
>>                        joe



>> >Well, i have 9 types of openvrmlwnds that i can use in my application
>> >and all of them share a lot of common code. By adding some mfc maps by
>> >hand i have to write little code to add functionality to the classes.
>> >If i follow ur suggestion than i have to cut and paste 5 pages of code
>> >for each type of window.
>> >The c++ OOP way is to share common code in base classes and not to cut
>> >and paste stuff around.
>> >Regarding ur carrer considerations yes i agree with u and the point of
>> >view u bring is correct. If I had been working at Microsoft ( which is
>> >one of my secret dreams...) i would follow  strictly the company
>> >directions; anyway i work in research so i am my own production
>> >manager and in my opinion the benefits i get from using more levels of
>> >inheritance are higher than that i get from being able to use
>> >classwizard. If i am ever going to change this code ( which in fact is
>> >quite probable) i'll have to concentrate only on one file and not on 9
>> >different files. Moreover if i'll be wrong i'll be the only one to pay
>> >and it wont be my company, my manager or someone else.

>> >P.S: I have already done what i've said, adding mfc maps is as easy as
>> >cutting and pasting code but 10 rows instead of 5 pages. By the way
>> >the code works fine: MFC has nothing to do with classwizard.

>> >Luca


>> >> Bad idea. It is a lot easier to edit a couple names than worry about
>> >> all the details of creating message maps by hand, and once you've
>> >> modified the class, ClassWizard will be happy to continue working with
>> >> it. Why waste time? In six years of MFC programming, I've never felt
>> >> that ignoring the tools gave me any benefits. Sometimes you work
>> >> around them, but the workarounds are so much less effort than ignoring
>> >> them that ignoring them makes no sense. (When I was in industry,
>> >> another Career Limiting Move on the part of one of my people was to
>> >> say "I don't need no stinkin' tools, I can do this myself" He got a
>> >> VERY bad annual review, since everyone on the committee thought this
>> >> was really dumb, and shortly thereafter left the company).
>> >>                               joe




>> >> >> This is a defect in ClassWizard; it won't go down more than one level
>> >> >> in the hierarchy. Create it as a subclass of CWnd and change it by
>> >> >> hand.
>> >> >>                      joe

>> >> >Thanks for ur suggestion.
>> >> >I prefer to go on adding message maps and stuff by hand: the benefits
>> >> >i get from my design are much more higher than some automatic editing.
>> >> >It's awkward to do so but the MFC framework works anyway , with or
>> >> >without  classwizard's help.

>> >> >Regards
>> >> >Luca

>> >> Joseph M. Newcomer [MVP]

>> >> Web: http://www3.pgh.net/~newcomer
>> >> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

>> Joseph M. Newcomer [MVP]

>> Web: http://www3.pgh.net/~newcomer
>> MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

Joseph M. Newcomer [MVP]

Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm


Thu, 08 Apr 2004 08:19:54 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Class Wizard won't let me derive a class from my class

2. New Class derived from Class which derived from CWindowImpl

3. How to Create CCtrlView derived class based on CTreeCtrl derived class

4. How to Create CCtrlView derived class based on CTreeCtrl derived class

5. Class derived from class CWnd

6. Adding a class derived from CObject via Class Wizard

7. Deriving a Class with Class Wizard

8. Class Wizard and derived classes

9. How to derive a class from CObject using the class wizard

10. Add derived classes to class wizard

11. How to add class derived from CSocket from Class Wizard

12. Deriving from my own class with Class Wizard?

 

 
Powered by phpBB® Forum Software