How Do I Create Subclasses for All Base Classes?

General
#1

Continuing the conversation from
https://forum.xojo.com/39688-oop-and-gui-design/0

From my experience with other OOL it is generally a best practice to NOT use base classes directly, but to create your own subclasses for all base classes.
Is that recommended for Xojo as well?

If so, what is the most efficient method to create all of these subclasses?

I am very new to Xojo, so I apologize if this has been asked/answered already. I did do a Google search and a Google site search of the Forum, and a search of the Xojo documentation, but did NOT find an answer to this. A lot of other OOD: Classes info, but not how to subclass all base classes.

TIA for your suggestions and guidance.

#2

Create new class and assign support class.
Some clients do that for all the controls to adjust the visual appearance.

#3

[quote=491580:@Jim Underwood]Is that recommended for Xojo as well?

[/quote]

In Xojo from what I have seen most people do not not unless they need to modify default control behavior/appearance reusably.

  • Karen
#4

Thanks, Christian. That is what I want to do, but I’m looking for an automated way to subclass all base classes, rather than having to manually create a new subclass for each one.

Any ideas?

#5

There is none built in.

-karen

#6

Thanks, Karen. Yes, that is the primary reason to subclass. For example, I may want to use a different font size and font face for all of the relevant controls.

#7

you can read about IDE scripting to create a script for that.Or just do it manually.

#8

Not unless you need to customize it
And there are things that will give you grief
I’d suggest only subclassing when you need to do it and not as a general rule

#9

OK, that sounds like a plan. I’d be surprised if someone had not already done this, and I’d expect subclassing is a very common use case. I’ll do some research on IDE scripting.

#10

Of course you can just set those in the set in the property inspector individually.

Alternatively just subclass window and write a method that automatically sets them when the window opens … that is a heck of a lot easier !

You can iterate over the controls and use IsA to determine control type

-Karen

#11

Well, I don’t know about “easier”. :wink:
I’d rather spend my time writing a script rather than having to set the properties each and every time I add a control to a window.

#12

Note that properties are not virtual so you’ll have some interesting days ahead if you do this :slight_smile:

#13

Thanks, Norman. Can you give me some examples? I’ve never experienced problems with subclassing, at least to only a few levels?
Does Xojo have a problem with subclassing?

I appreciate the caution, but could you please be specific?

#14

[quote=491593:@Jim Underwood]Well, I don’t know about “easier”. :wink:
I’d rather spend my time writing a script rather than having to set the properties each and every time I add a control to a window.[/quote]

I think subclassing window and in the open event iterating over the controls in a generic way to set your defaults is easier than writing a xojo script! You would not be setting them manually that way either and you only need to create one subclass.

-Karen

#15

No … I think he me meant because properties are not virtual… you can only shadow properties, which can cause issues if you want to change the behaviors they affect.
-karen

#16

It has “gotcha’s” that if you dont know about them they will bite you
And, because of some of these and how you have to deal with them you can accidentally introduce the fragile base class problem

Super. wont work so you cannot write
Super. = someValue
in your subclass

I have blog posts about it on my blog and how you have to work around this
https://www.great-white-software.com/blog/2019/05/28/why-shadowing-should-be-avoided/
https://www.great-white-software.com/blog/2019/06/17/follow-up-on-why-shadowing-should-be-avoided/

Note that the “right” way to do shadowing introduces the fragile base class problem as now your subclass MUST know its super since properties are not virtual

#17

[quote=491580:@Jim Underwood]From my experience with other OOL it is generally a best practice to NOT use base classes directly, but to create your own subclasses for all base classes.
Is that recommended for Xojo as well?[/quote]
No. It is not. You should only subclass when you find a real need. Xojo classes are fully functional out of the box.

#18

It isn’t a question of whether the base classes are fully functional, or not – I’m sure they are.
It is a question of ease of global customization later on, after the app is fully developed, and even deployed.

For example, how you guys handle this: Many clients want and expect the ability to change certain UI features like font face and font size, across the entire app. So how would you provide this without using subclasses?

For that matter, the base classes for Labels, TextFields, TextAreas, etc do not have a property shown in the IDE for font face.
How would you provide a consistent font across the entire app if you did not want to use the “system” font?

Thanks.

#19

[quote=491658:@Jim Underwood]For that matter, the base classes for Labels, TextFields, TextAreas, etc do not have a property shown in the IDE for font face.
[/quote]

Yes they do.

-Karen

#20

It would be easier to follow Karen’s suggestion and subclass Window and put code in it to set the attributes of all the controls on the window. That said, there are several controls that I have subclassed to add additional functionality. But not all controls need it. I put them in an external module so I can share them between projects. I have code in my window subclass to set typeface and size, and to dynamically resize all the controls to achieve an “elastic” feel to the window.