Subclassing ContainerControl

General
1

I have several ‘pages’ that have been implemented using ContainerControl. That is, a variety of other controls have been put onto a ContainerControl, and these are put on a window which shows/hides them as needed.

The resize event of the page calls a layout method that arranges the various controls that are contained.

Setting either page.Width or page.Height triggers a resize event. Since both are usually set at the same time, there will be two layout calls when there only needs to be one.

In order to eliminate the redundant call to the layout method, I tried subclassing ContainerControl, so that I could add a property to all of these pages. Also this seemed a good way to set DoubleBuffer etc as is best practice for Windows.

So I inserted a class, then changed its superclass to ContainerControl (typing “ContainerControl” into the textbox in the inspector). The icon in the contents list changed to a ContainerControl icon, BUT there was no window shown. I named this class PageCtl. I then set the superclass of all of my pages to PageCtl.

Xojo was quite happy about this, did not complain. The redraw problem was fixed. The only problem was, the background was not being drawn for the pages.

Then I tried something different. I dragged a ContainerControl from the Library into the contents. Added the required property etc, and renamed that to PageCtl. Now the code would not compile, reporting that it could not subclass a window.

This of course makes no sense at all. In both cases, the superclass says ContainerControl, but the behaviour is different.

I think the answer for me will be to use a Canvas as a container…but this is a bug. Also it begs the question, if the superclass was not ContainerControl, then what was it?

This is on OSX El Capitan with 2016r3.

2

This is the right way to do it.

What do you mean? I tried it out and don’t see a problem.

3

As Will wrote your first case is the proper way to do it. There is no bug here.

You do not provide enough info: for example what is the compiler error for this case:

Also – at least for me – it’s for example difficult to guess what “dragging into the contents” could mean. The project navigator? The window content area?

4

  1. From the Library, drag a ContainerControl to Contents. You will see, in the middle of the screen, a grey square.
    Click on Inspector. You will see that the Super field is ContainerControl.

  2. From the Insert menu, select Class. A class icon appears in Contents. Change the Super field to ContainerControl. The icon changes to a ContainerControl icon, but there is no grey square in the middle of the screen.

In both cases, Super is ContainerControl, but in one case you have a window, in the other you don’t.

The error I get when using the method 1 (having named the new class PageCtl). is:

“The project item [pagename] can not inherit from a window (PageCtl)”

BTW…if you scroll the treeview on the left to the top, you will see it is labelled “Contents”

5

As Eli and Will have mentioned, this is by design. A Window (and, but extension, ContainerControl) is a special beast so it is treated differently in many ways. You can create a super for its events, to add methods and properties, and the like, but not for purposes of design. Hence, adding an Object and changing its super works as a superclass to other ContainerControls, but dragging a ContainerControl from the Library does not.

6

Known issue
<https://xojo.com/issue/26522>
Its been present for > 10 years

And you cannot inherit UI anyway

7

I see.

Its like the Window is an optional property of the ContainerControl?

Is this a documented feature? I don’t see anything about it here:
http://developer.xojo.com/containercontrol

8

Container Control is an embedded window.

http://documentation.xojo.com/index.php/window

9

Aye.

Is there an image somewhere of the object model?

10

[quote=307418:@Norman Palardy]Known issue
<https://xojo.com/issue/26522>
Its been present for > 10 years
[/quote]
Must be time to get it on it then :wink:

11

The only place it doesn’t work as expected is “add class change super to Window or ContainerControl” (maybe one of the other layout types like web dialog webview iosview) And I know exactly why
But if I fix that it makes a host of other problems appear like trying to inherit layout

The reality is there should not be inheritable layout and a “fix” would actually have to make sure you dont try to add layout to the super and then to a subclass. And its easy to imagine ways that people might try to subvert this “checking” like layout window1 and window2 and AFTER the layout is done then make window2 a subclass of window1, etc.

What there exists right now already does this without any “check”

So its not clear that a "fix"exists doesnt introduce a pile of other issues

Geoffs status message is far from the reason this is the way it is