>>Now I got myself so confused that I can't figure out why I need to subclass the framework!
>
>Isn't this fun?
>

LOL! It's work to me now :-) Wow, that was a quick response! Do you live here? :-)

>You might want to subclass if you need to add functionality of your own or override certain framework behavior.
>
>For example, you might want all the textboxes in all your apps to use timesroman instead of arial.
>
>In this case you would subclass the framework's textbox classes and create your own.
>
>That's the traditional reason for subclassing the framework.

Gotcha now!

>
>If you're subclassing objects that are already part of a complex hierarchy (forms, for instance), you will need to do some thinking before going ahead with the change.

There's that thinking thing again <g>

>
>Another option is to modify the framework classes, but you MUST document these changes in a separate document or you will loose them with the next version of the framework.
>
>Alex

Yup. Read that in the Dev Guide.

One thing I am trying to understand right now, is why I would want to subclass to create a third level for the clients. The explanation in the guide mentions that this would come in handy if a client wants different fonts, etc...

Qstart will create a new project in a new directory. Therefore, wouldn't I just change my "W" classes (the 2nd level) and recreate the application/exe and send it off to the client??

Still a little new to OOP, but getting there.

-paul