Bug: Menu Handlers not working in ContainerControl subclasses

Today I ran into a rather tricky bug that been existing for years:

<https://xojo.com/issue/39143>

Does anyone know how to make this work? I mean, without moving the menu handlers to the super class?

Invert your chain
CC(virtual) -> CC(real)

you have done the inverse

I’ve read your comment on the feedback page. I do not follow your suggestion.

I need to end up with two classes: One is a container control that contains several other controls, and which provides general functionality. Then I want to subclass that container so that I can add custom functionality to it. How would I accomplish that with your suggestions, I don’t understand.

AFAIK you can’t subclass a window or a CC with UI on it.
But you can subclass a class based on window or CC class

So you can create a class based on CC (and subclass as you want) and then (at last) build a subclass with the interface (or better) create a CC and set you (sub)class as Super.

In this scenario the menu handlers work as expected.

I’ll add to your feedback your project modified to show you this

Project sent

xDev 13.2 Tips&Tricks olumn:

Tip 3: Subclassing ContainerControls and Windows Subclassing seems a simple enough concept, but sometimes it catches people out. This usually happens when you have made a nice custom control (using a ContainerControl) or a custom Window, you have spent a lot of time to get the layout just right, and you would like to subclass it. The IDE has no problem in letting you do this:

  1. add a ContainerControl to your project
  2. name it cc1
  3. modify cc1 as you wish
  4. add another ContainerControl to your project
  5. name it cc2
  6. set its Super to cc1 (so it is a subclass of cc1)
  7. modify cc2 as you wish

but it really shouldn’t. When you try to run it, then you are being greeted with an error message: “the project item cc2 cannot inherit from a window (cc1)”.

Note: a ContainerControl is a kind of Window, and the same happens when you use a Window instead of a ContainerControl.

Why do you get an error? Because both Windows and ContainerControls have a layout. You can inherit properties and methods, but you can’t inherit a layout. Or how is a Window supposed to look that is both a winMain and a winPreferences? Any object can have at most one layout. So it is very unfortunate that in step 6 the IDE lets you set cc1 (which has a layout) as the super of cc2 (which also has a layout).

P.S. From the bug report:

Steps: Add a ContainerControl to the project.
Create a subclass of that ContainerControl.

Right:

Steps: Add a class to the project, set its super to ContainerControl.
Create a subclass of that class.

RIght

Or more simply: you can create a CC sub class (so new class super as ContainerControl)
you can subclass as you want this class
you can use your (sub)class as Super of a ContainerControl object

Antonio, I checked your project. While what you did works, it is not helping me. I NEED to be able to subclass a containercontrol and then customize its behavior. In my case, the ContainerControl is a generic Grid view control with scrollbars etc, and then I subclass that control to add specific abilities to it. I can’t do that with your design proposal.

Markus, you write:

Maybe you are right, but again, that does not apply to my design. I have a subclass of a custom CC, and I use it without problems, with lots of methods, events, etc. in it. The only thing that doesn’t work is the Menuhandler.

Is that really so hard to understand that one wants to be able to subclass a custom control, no matter whether it’s based on a “normal” Control or on a ContainerControl?

[quote=182862:@Thomas Tempelmann]Feedback Case #39143
Steps:
Add a ContainerControl to the project.
Create a subclass of that ContainerControl. <– this is not possible (though it compiles)
Add this subclass as a control to a Window.
Add a new menu item to the main menu bar.
Add a menu handler to the subclass for this new menu item, adding code to show that it gets called (e.g. a “break”)
Run the program, open the menu item.
[/quote]

In other words, you cannot subclass a ContainerControl-UI class. This will not work:
– ContainerControl1 Inherits built-in ContainerControl
– Class1 Inherits ContainerControl1
– Create menu handler in Class1
– Create instance of Class1 in a window

You can subclass ContainerControl and use it as superclass for a ContainerControl-UI. This will work:
– Class1 Inherits built-in ContainerControl
– Create menu handler in Class1
– ContainerControl1 Inherits Class1
– Create instance of ContainerControl1 in a window

Eli, you’re telling me that what I’ve actually done is not possible? Weird.
I mean, just download the included project. It shows that there is a subclass from a custom containercontrol. So, it works, obviously. It works in all aspects but the menu handling. I use it in my app, and I’ve worked on this part for 5 days, so I am pretty sure that it generally works with all the ways subclassing works, usually.

If you add a ContainerControl (or a Window) to your project, it has to be the last in the inheritance chain. Layouts (ContainerControls and Windows) can not be subclassed (even if they compile), you can only subclass classes.

MyContainerControl As ContainerControl <– added with “Add Class” – no UI
MyMoreSpecializedContainerControl As MyContainerControl <– added with “Add Class” – no UI
MyLayoutContainerControl As MyMoreSpecializedContainerControl <– added with “Add ContainerControl” – this is the UI
…from hereon you cannot further subclass.

Eli, let me repeat. What I did was done in the IDE. Mind you, it was done in the old RS IDE, and I see that the new Xojo IDE (which I avoid using like the Pest, haha) has put a restriction on that. But nonetheless, I did what I said I did, and it worked, so please stop telling me that I cannot do it. I can, and apart from a non-functional menu handling, this subclass of a custom CC is working just fine, even when built with 2015r2.1.

Besides, the fact that the new IDE has disallowed what used to work puzzles me. I wonder why no one else here understands that limitation. Why is everyone in this thread just accepting this? Isn’t anyone seeing the design flaw in not being able to subclass a custom control? Sure, a CC looks quite much like a Window, and it makes sense that one cannot subclass a window, but a CC is meant to be a wrapping container for controls and should primarily be a control, and behave like one.

For instance, I can subclass a Listbox and then add custom menu handlers to this Listbox subclass. And if I couldn’t, it would totally defy the idea of views hierarchies and OO.

And in the RS IDE, I was able to do the same for a custom control I made using a CC. Which makes totally sense that that should be possible, don’t you agree?

Yet, everyone here just keeps telling me that what I do can’t be done – and no one gets the idea that my bug report is actually valid because that’s how it SHOULD work with custom controls??

I feel a bit lost here amoung people who seem to have trouble grasping the concepts that are common outside the somewhat blindfolded world that is Xojo.

It was always that way, also in RS. This is a copy of post by Norman explaining it better that I ever could:

[quote]Re: Window Subclassing
Date: 17.08.08 16:45 (Sun, 17 Aug 2008 09:45:51 -0600)
From: Norman Palardy

On 17-Aug-08, at 1:19 AM, Fotis Georgiadis wrote:

I have a window, say Window1. I create another window say Window2
and put the super property to Window1 and get an error from the
compiler "The project item window2 cannot inherit from a window
(Window1).

The aim is to inherit everything (properties, methods, objects etc)
and then add some more objects, code…
Is it possible somehow?

Ah I see what you’re trying to do
As already stated the Window you design in the IDE is not a Class,
but an actual instance of a Class and you cannot subclass an instance.
If you need common appearances then you’ll need to do something
different (perhaps a common container controls)

BUT if you create a new class that is a subclass of Window you CAN
then make new windows that are subclasses of this new class
They will inherit all the properties and methods you’ve added to your
original subclass of Window

You can inherit behavior; not appearance [/quote]