Multiple base classes design

Interfaces.

Your Object could be an Interface

public interface IObject
{
   //Methods and Variables
}

I wouldn't have any functionality in the object myself, I'd have that higher up in the chain and have only the Object be a 'Contract' ... or a promise that an Object will have these fields / variables.

Hard to say anything else without code. you're going to need either interfaces, or redesign classes.

Personally I have something like this:

- IRenderable interface : contains Draw(), Update(), and Init() functions (i also use this in many other places, so its not as useless as it seems :P)

- GUIComponent - base class of ALL GUI stuff (implements IRenderable)

Then I have

- GUIContainer : (like a Panel, inherits GUIComponent)

- GUIControl : (anything control inherits from this, handles clicking logic, inherits from GUIComponent)

Then I hasve classes like:

- Panel : GUIContainer

- Button : GUIComponent

- Image : GUIComponent

etc. etc.

I cannot make Group an extension on Object, because the Window is a Group and not an Object (this is the only Group which isn't an Object). And the window has to inherit from Group because every Object has a pointer to its parent which can be either a GroupObject or the Window (so a Group pointer).

I just re-read this: why not make Group an interface?

public interface IGroup<T>
{
    T Parent {get; set;}
}

(may or may not be able to use the magic T)

Hello Texus.

After a short look in your TGUI code, I think the problem is the Window class.

First: the naming is confusing. In a GUI I expect a window to be a widget. In your case Window is a renderer and should act like a root for your widgets as well. (Thats why it inherits from Group but not from Object)

My idea: I would get rid of the Group class and put all its code into GroupObject. Then let window contain a GroupObject named root. (or inherit a RootObject or Desktop etc. from GroupObject)