Trying to understand what Subclassing is

[Pedro Ramirez]

I´m confused about subclassing. After I searched for an explanation
on what subclassing is, I concluded that subclassing is what we know as
callback functions or procedures: The callback function receives the
messages sent from the current window, processes certain messages and
all other messages not dealt with within the callback procedure are
passed to the OS own internal procedures.

Am I right? If I´m not can anyone suggest where can I find information
on the subject?

I´ve have seen some examples in the forum but I don´t quite grasp
the true meaning of subclassing.

------------------

[Josef Kirschbaum]

Originally posted by Pedro Ramirez:
Am I right? If I´m not can anyone suggest where can I find information
on the subject?

Pedro,

your conclusion sounds right to me. Microsoft offers a quite good explanation as well:

"If a control does almost everything you want but you need a few more features you can change or add features to the original control by subclassing it. A subclass can have all the features of an existing class, as well as any additional features you want to give it.

Subclassing is a technique that allows an application to intercept and process messages sent or posted to a particular window before the window has a chance to process them.

To make a new control it is best to start with one of the Windows common controls and extend it to fit a particular need. To extend a control, create a control and replace its existing window procedure with a new one. The new procedure intercepts the control's messages and either acts on them or passes them to the original procedure for default processing."

You will find more information in MSDN like details for Subclassing Controls. There is a search field -- just type in "subclassing" and you will get a lot more information from Microsoft.

------------------
Additional forums for German speaking PowerBASIC user
http://www.kirschbaum-software.biz/u...ubbthreads.php
We are looking forward to meet you there!
Josef Kirschbaum - [email protected]

[Chris Boss]

Subclassing 101:

Every window has its own class (ie. edit, static, etc.). A Class
is a specific type of window with specific features. The edit class
allows typing in text. The button class actually is multiple controls,
such as a button, checkbox, optionbutton or frame.

Dialogs are a unique window class predefined by windows. Controls
are also predefined by windows. You can also create your own
custom window class as well, as is done with SDK style coding
(non-ddt).

Every window class at some point must be registered with windows.
When a class is registered one parameter passed is the address
to the window procedure for the class. The predefined window
classes all have their own window procedure which exist within
the operating system DLL's. When your applications must send
messages to a predefined window class, windows will send it to
the window procedure in the OS DLL's for that class.

Every window procedure looks like this:

FUNCTION WindowProc(BYVAL hWnd AS LONG, BYVAL Msg AS LONG, BYVAL wParam AS LONG, BYVAL lParam AS LONG) AS LONG
    SELECT CASE Msg
        ' define all custom message processing below
        CASE %WM_CREATE
        CASE %WM_DESTROY
        CASE ELSE
    END SELECT
FUNCTION=DefWindowProc(hWnd,Msg,wParam,lParam)
END FUNCTION

By default window messages are processed by the DefWindowProc
function. This function processes all messages in a default
way. The window procedure may also include processing of any
message to customize how the class will look and act. Also
the window procedure will likely have custom messages
(%WM_USER + SomeNumber) that handle custom features of the
window class. For example the edit control has custom messages
which start with the prefix %EM_ .

When you, the programmer, create (register) your own window class,
you have access to the window procedure for that class in your
application. The problem with the predefined window classes
(ie. controls, dialogs), is that you don't have direct access
to the window procedure for those classes. The code for their
window procedures exists in the operating system DLL's and not
in your application.

This is where subclassing comes in !

Every window has the ability to have its internal window
procedure address to be changed. When a window (ie. control) is
created, it stores the address to the original window procedure
for the class in its data structure (instance data). Windows
allows you to change the address to another address so the
window uses a different window procedure. The problem with this
is that if you change the window procedure address from the original
you lose all the original's features.

Subclassing is a way of rerouting messages to a window procedure.

When you use the GetWindowLong function with the %GWL_WNDPROC flag,
you get the original window procedure address for the original
window class the window is based on. Now you have the original
window procedure address.

By using the SetWindowLong function you can change the window
procedure address for the specific window to another one, in this
case a custom one written by you. SetWindowLong also returns
the previous value so you don't have to use GetWindowLong to
get the original value.

Lastly, windows has an interesting function called CallWindowProc
which allows you to send messages to the original window procedure
by passing its address.

Now, let's subclass a window:

FUNCTION SubClassWindow(BYVAL hWnd&, BYVAL NewAddress&) AS LONG
    FUNCTION=SetWindowLong(hWnd&, %GWL_WNDPROC, NewAddress&)
END FUNCTION
'
GLOBAL gOrigAddress&
'
SUB StartSubClass(BYVAL hWnd&)
    gOrigAddress&=SubClassWindow(hWnd&, CODEPTR(MyWindowProc))
END SUB
'
FUNCTION MyWindowProc(BYVAL hWnd AS LONG, BYVAL Msg AS LONG, BYVAL wParam AS LONG, BYVAL lParam AS LONG) AS LONG
    SELECT CASE Msg
        ' define all custom message processing below
        CASE %WM_CREATE
        CASE %WM_DESTROY
        CASE ELSE
    END SELECT
    FUNCTION=CallWindowProc(gOrigAddress&,hWnd,Msg,wParam,lParam)
END FUNCTION

By saving the original window procedure address for the windows
original class, you can now send all unprocessed messages in
your custom subclass window procedure to the original window
prcoedure so the window has the attributes of the original
class. You can also preprocess any messages you before the
original window does so as to add new features.




------------------
Chris Boss
Computer Workshop
Developer of "EZGUI"
http://ezgui.com

[Pedro Ramirez]

Josef: Thanks for pointing me to where I can find more info. It sure
will be helpful when getting deep into subclassing stuff.

Chris: What a superb explanation. I understand now what subclassing is!.
That´s better than looking through books. Thanks a LOT for
all the explaining.

THANK YOU GUYS!


------------------


[This message has been edited by Pedro Ramirez (edited March 12, 2004).]

[Fred Buffington]

Great explanation Chris.

Since I've just gotten my feet wet in subclassing and for the
moment am only using it for dialog subclassing, I had thought of
it in this way.

That the subclassing window controls things like scrolling,
enlarging/reducing size of the window whereas the dialog callback still
controls the individual controls like textboxes, buttons,etc. that
are defined within the dialog.


I see now that it's much much more than that.



------------------
Client Writeup for the CPA

[Frank W. Kelley]

Chris is too modest to mention that his EZGUI 3.0 has optional subclassing
of controls built in. This is a very powerful feature that allows those of
us who are API-challenged to have most of the dirty work attended to by
EZGUI. The programmer must still process the messages, however.

Maybe Chris will fix that in EZGUI 4.0?

------------------

[BOB MECHLER]

Chris, I've got to say your explanation is going to help me use
more than a modified copy of Lance's example. Very good
explanation!

Bob Mechler

------------------

[Edwin Knoppert]

Imo, subclassing is the worst of all variants.

Beter is to use superclassing since it will have one main pointer.
Iow, the superclass is not part of any hooking to reach your goal.
(While it looks this way..)

Imagne multiple hooks on the same control, while releasing the 1st from 2 hooks.
A superclassed control does not need to restore on destroy to org. windowproc since this is a global variable.


------------------
http://www.hellobasic.com
Freeware and commercial tools for PowerBASIC
PBSoft - Netherlands

[Chris Boss]

Just a comment about Edwins comment:

Edwin is absolutely correct ! Superclassing is far better
than subclassing !

Superclassing requires a few more steps.

You must get the original wndclass structure for an existing window
class by using the GetClassInfo (or GetClassInfoEx) function.

You must get the original class window procedure address from
this info and store it. You then change the class name (to your
own custom class name), the window procedure address to your
own custom window procedure class, modify the extra window bytes
value (increase it for any custom data storage) and the register
the new window class. Now you have a new window class which points
to your suprclass window procedure. The window procedure looks
much similiar to the subclass window procedure above. Any messages
not processed must be passed to the original window procedure using
the CallWindowProc function.

Subclassing requires that you must subclass each and every control
that you want subclassed. Superclassing doesn't require any
special coding for each and every control. You simply create the
controls (using the new class name) just like the original controls
would have been (ie. instead of CONTROL ADD "edit" it would be CONTROL ADD "myedit"
if the superclass name is myedit). You just create the new class
control and thats it. It is automatically superclassed.

If you need multiple controls of a particular class that all need
to be subclassed, the superclassing is far more efficient. If you
only need one control subclassed, then subclassing is more likely
better (slightly less code).

Now it should be noted that both subclassing and superclassing
will slow down a control slightly, since two window procedures
will be called for many messages (the subclass window procedure
and the original window procedure unprocessed messages are passed
to). With todays fast computers, this is likely not going to
effect the speed the control responds by much.

------------------
Chris Boss
Computer Workshop
Developer of "EZGUI"
http://ezgui.com

[This message has been edited by Chris Boss (edited March 13, 2004).]

[Borje Hagsten]

> Imo, subclassing is the worst of all variants.

It's one variant. Why worst, if all I want to do is to trap a message
in a single control? Whatever means least and cleanest code with the
same result is best, IMHO..


------------------
http://www.tolkenxp.com/pb
Download: incLean, PBcodec, custom controls and code, etc.
Borje Hagsten - [email protected]

[Steve Hutchesson]

Pedro,

To get the swing of what subclassing is about, you need to understand
something very basic about how Windows works. For EVERY Windows
there is a message handling procedure and it works by the operating
system sending the message for that window to its message handler.

With a Window created by CreateWindowEx(), you use a "WndProc"
style of procedure, with minor variations for a dialog you use a
"DialogProc" style of procedure.

When you create a control, it already has a message handling procedure
for it as the class for the control is predefined but you don't
have access at it unless you write specific code to do so.

When you write a subclass procedure, you are INTERCEPTING the messages
being sent to the controls message handler and processing the ones
you need to first before they are passed to the original message
handling procedure.

It sounds messy but in fact its simple as long as you keep in mind
that EVERY window has a message handler.

Regards,

hutch at movsd dot com

------------------

[Pedro Ramirez]

Steve,
You just wrapped it all up in an easy-to-understand-how-it-works way.
Together with Chris´s explanation makes a fine chapter for subclassing.

I think your explanation was the one thing missing (at least for me) to truly
get an unsderstanding of subclassing. I now can conclude that subclassing gives
a more precise control on the inner workings of windows and controls making it
possible to avoid "programming tricks" to achieve certain responses.

The material you and Chris posted are the starting point to study, tinker with and
comprehend subclassing.

Thanks

By the way, I didn´t know about that superclassing stuff. It really seems worth
getting to know it.


------------------

[Steve Hutchesson]

Pedro,

The "buzz" terminology is less use than understanding what is
going on with each window. As long as you understand the message
handling procedure for each window, you write code in it to do
what you like and don't lose any sleep over the terminology of
the variations.

Regards,

hutch at movsd dot com

------------------