Same code different Superclass

Suppose I have a custom class that is just that… 100% custom code… based on OBJECT…

and then there is Xojo’s built in GRAPHICS class.

BOTH classes have the exact same methods and properties…

Is there a way I can write a method (overloaded if necessary) that can tell my app which class to use?
I have thousands of lines of code where I pass “G as graphics” now… but I want to be able to use “G” or “myObj”.

One idea I had… and its a kludge to say the least. Is to subclass MY class on GRAPHICS… then overide everything…

This way the app that uses it will see either a graphics from a CANVAS, or the graphics from myOBJ… but internally myOBJ will ignore its graphics object… but this is not really the solution I’d like best.


This sounds like a job for an Interface.

can you elaborate?

I’d like to post a URL to the documentation where Interfaces are defined, but I’m not finding anything online. OK, found it offline : “UserGuide-Fundamentals.pdf” pager 145 : Chapter 5 / Interfaces.

Thanks… to be honest… none of that made a lick of sense to me… and while I could figure how to make an interface to the CLASS that I created… there is no way I could see to create an interface for GRAPHICS…

Particularly since neither GRAPHICS or myObj have a direct visual component… GRAPHICS is a property of PICTURE and/or CANVAS while myOBJ is a non-visual file handler.

and even then… I do not see how that helps…

I have a method today that is for example : FOOBAR(g as graphics)

I do not want to rewrite what is in FOOBAR… I want to create an overload : FOOBAR(myObj as myclass)

Unfortunately, the Graphics class cannot be subclassed - which would make your plans much easier. There’s a FR in Feedback for it, couple of years old and among my top 5 cases (written by Christian Schmitz). I fear this will never see the light of the world.

Not at my computer so I cannot post a Feedback number but feel free to sign on.

1+ for Michael. This sounds like a job for an interface. An interface is a generic method to make 2 not-similar things behave the same. Think of a house. You define a “things that open” interface and give this to all objects that can open. Door, window, cat flap whatever. The objects themselves have the knowledge about how they implement the open. That’s why the interface only defines empty methods.

Read “Head first design patterns” if what I wrote doesn’t make sense to you (had to do this myself before the OO stuff stopped sounding mysterious to me).

What I want to do cannot be done… Interfaces won’t help… for two reasons

  1. GRAPHICS cannot be subclassed… and it seems you have to make an interface for both (all) classes involved.
  2. I need to make this transparent … I don’t want users to have to rewrite all of their existing code to use this class

Hmm, not being able to subclass a Graphics class does pose a problem.

You want it to be “transparent” but I suspect that’s not going to be possible. What compromises can you make?

Another approach : don’t think of this is an “IS A” relationship, but perhaps a “HAS A” relationship:

  • create two classes
  • one is your fancy class
  • the other is an object which holds a Graphics object in a property

Then you could give both of them the same Class Interface and treat them the same (or almost the same).