if I subclass, must I un-subclass before destroying?

if I subclass, must I un-subclass before destroying?

Post by John Gra » Sun, 10 Apr 1994 10:14:30



When I subclass a control in a dialog box, I'm always careful to un-subclass
the control again before closing the dialog box (i.e. at EndDialog).

In Petzold's HEAD.C example (page 263-267), he subclasses a listbox, but
never restores the old proc before processing WM_DESTROY.

Is this:
  (a) perfectly ok
  (b) sloppy, but ok
  (c) dangerous/wrong
  (d) other

My guess is (b). Comments?
--

Airborne Geophysics
Geological Survey of Canada, Ottawa

 
 
 

if I subclass, must I un-subclass before destroying?

Post by R.A. Hein » Sun, 10 Apr 1994 22:24:32



>When I subclass a control in a dialog box, I'm always careful to un-subclass
>the control again before closing the dialog box (i.e. at EndDialog).

>In Petzold's HEAD.C example (page 263-267), he subclasses a listbox, but
>never restores the old proc before processing WM_DESTROY.

>Is this:
>  (a) perfectly ok
>  (b) sloppy, but ok
>  (c) dangerous/wrong
>  (d) other

>My guess is (b). Comments?
>--

>Airborne Geophysics
>Geological Survey of Canada, Ottawa

It seems to me that there's no reason to restore the old window proc before
destroying the window.  The proc address is stored in the individual
window's data area, so once the window is destroyed, the address goes with
it.  I suppose one exception is if the subclassed window proc interferes
with processing the WM_DESTROY message; in that case it might cause a
problem.

Besides, would Petzold steer us wrong?

--Ray Heindl

 
 
 

if I subclass, must I un-subclass before destroying?

Post by Matt Arno » Mon, 11 Apr 1994 11:09:13



>When I subclass a control in a dialog box, I'm always careful to un-subclass
>the control again before closing the dialog box (i.e. at EndDialog).
>In Petzold's HEAD.C example (page 263-267), he subclasses a listbox, but
>never restores the old proc before processing WM_DESTROY.
>Is this:
>  (a) perfectly ok
>  (b) sloppy, but ok
>  (c) dangerous/wrong
>  (d) other
>My guess is (b). Comments?

I'd say it's (a).  Why?  What need can you think of to un-subclass it?
Your sub-class procedure should be passing all unwanted messages on to
the previous window procdure, not really interfering with the destruction
of the control.  And, after the control has been destroyed, your sub-class
procedure will not get called anymore.  There's no danger in leaving the
control sub-classed all the way to the end.  Windows doesn't care that a
control doesn't have it's original window procedure when it comes time
to destroy it.  It's just a matter of the control responding correctly
to messages sent to it.

Matt

 
 
 

1. subclassing and wm_notify msgs from subclassed window

My goal is to "wrap" a common control and provide my own functionality
that augments/changes that of the common control. After reading about
subclassing extensively, it is clear that with the Get/SetWindowLong
functions you can easily handle ONE DIRECTION of message flow; namely,
the flow of messages INTO the control (i.e. you catch messages on the
way in and either handle them, forward them on to the underlying
control window proc, or both).

But what about the messages coming OUT of the "wrapped" control (like
WM_NOTIFY messages). WM_NOTIFY messages are sent to the parent window,
but I sure would like my "subclass" window procedure to see them, and
then be able to handle them or pass them "up" to the parent myself; i.e.
flow of messages the other way.

This is really a very useful idea. For example, I would like to
have a treeview control that displays a certain image for an "expanded"
tree as "default" behavior -- by that I mean that the writer of an app
using my treeview just has to create it as a child to one of his windows,
but doesn't have to worry about handling the WM_NOTIFY message that
contains the TVM_EXPANDED message -- I would like my custom control to
catch the WM_NOTIFY that is on its way back to the parent. That way, I
can do the image changing and THEN forward that message to the parent
so he can do what he wants in addition to the image changing...

I think that this behavior (full wrapping of a control) can be done
by creating a "container" window that is the parent of the subclassed
control, correct? Is this the right way to do it? It seems like it might
be a pain -- how do I make sure that the container never gets
in the way; i.e. that it is always the same size, position, as
the child, etc? If this is the way to do it, can someone give me
very general direction?

I was hoping that it could be done without having to explicitly
create another window just to be a container and "upward message
catcher" for the wrapped control -- it seemed like subclassing
might get me there, but the subclassed window talks directly back
to the parent instead of to my new window proc. Is there a way
to make subclassing work?

Thanks,
Steve T.

2. Windows 98 doesn't detect Yamaha 4260 !!

3. Ajout d'un bouton dans une Wnd d'un autre process

4. Activesync leaves files unsynced

5. Conseil pour un bon bouquin de C++ pour un novice

6. operator ","??

7. Painting a subclassed window

8. Hook/Subclass the Print Spooler

9. Subclassing a window in another application?

10. SubClassing Command button > Can't paint on it when WM_PAINT

11. Subclassing Desktop Window in W95

12. Subclassing the desktop?