How to handle Event Definitions for class placed on containercontrol?

So, I’ve got a canvas subclass that is a row of custom buttons and have placed that in a container control.

It has event definitions for each button when clicked, like “ClickedLock”. And I added the event handler to the cc.

But of course, on the actual window holding the cc, (say, cc1) that does no good. Should I add event definitions to the cc itself? Sort of cascading them up?

What I’m trying to accomplish is to toggle a boolean property on another control on the same window as cc1.

I tried looking at the container control examples, but they don’t answer this that I can see. For example, the OKCancelcontainer doesn’t actually do anything interesting like interact with something else on the window, it just opens a msgbox. So, I’m kind of stumped as to the best practice for this.

Maybe I’d be better off removing the class from the container control and putting it directly on the window?

I couldn’t find information on this in the on-line documentation either or over two hours of searching the forum, but appreciate any pointers to information already out there.

cc is for using multiple times the same window items
if you only use it once, then placing the buttons directly in the window should be easier.

OK, thanks, that’s what I’ll do then.

For the sake of general learning though - can you access some other control outside the cc from a custom control in a cc?

Or is that more generally not advisable?

You could, but that is not OOP. Do you have a concrete example of what you want to achieve ?

Aha, so I’ve strayed far, I see!

The more I think about it, the less I feel I have a concrete example. I mean, I have the example above, using the button to change the boolean in that particular case. And it just seemed to me after watching the webinar on container controls that the buttons fit well into one. But trying to extrapolate into something “concrete but reusable” isn’t coming to me.

If it is not OOP, then that explains a lot. Sounds like it is not worth learning, then.

My line of thought was this:

i’m building an “Inspector panel” that will come in from the right, like in many apps, including the IDE. And the buttons should be placed at the bottom of that as they will switch the pages of the pagepanel on the cc AS WELL as toggle the boolean on the other control. So, I created a containercontrol with the other controls in need there like the pagepanel and a listbox and textarea, and put my custom buttons right under the pagepanel, but on the cc.

Then it’s very easy to get the inspector to show and hide and in one shot.

I guess it is better to have a canvas, and put the custom buttons and the cc both on it.

[quote=330935:@Dave Kondris]So, I’ve got a canvas subclass that is a row of custom buttons and have placed that in a container control.

It has event definitions for each button when clicked, like “ClickedLock”. And I added the event handler to the cc.

But of course, on the actual window holding the cc, (say, cc1) that does no good. Should I add event definitions to the cc itself? Sort of cascading them up?[/quote]

Yes

are you asking how to have (for example) a button inside a CC
and have external code respond to when the button is pressed?

Simply have the CC respond to the Button, and then have the CC forward the event as if the event belonged to the CC in the first place (see Event Definitions)

I have a CC with sliders and buttons and a listbox… but from the outside it looks like the CC IS a listbox as I have forwarded all the events and properties (via computed property) to the CC itself.

So now I have ONE custom control that acts like a conglomerate of all its internal controls

[quote=330943:@Dave S]are you asking how to have (for example) a button inside a CC
and have external code respond to when the button is pressed?

Simply have the CC respond to the Button, and then have the CC forward the event as if the event belonged to the CC in the first place (see Event Definitions)

I have a CC with sliders and buttons and a listbox… but from the outside it looks like the CC IS a listbox as I have forwarded all the events and properties (via computed property) to the CC itself.

So now I have ONE custom control that acts like a conglomerate of all its internal controls[/quote]

Yes, I think that is what I’m asking. But as pointed out above, I am not certain I’ll use this cc in more thna one place. Does one way - separating the buttons from the cc VS “conglomerating” - result in better or worse performance?

Breaking them up, introduces a canvas that is otherwise doing nothing. But without the canvas and with separate buttons, it will require more code to move both the buttons and the cc. Not that my app will really suffer from something so small, of course.

you could use a groupbox with no title instead of a canvas

To be fair, i’m beginning to believe i should not use a container control here at all…

Groupboxes I tend to avoid as they give me all kinds of borders and rounded corners which just don’t jive with my idea of aesthetics.

Container controls are nice to use even if you only use one instance on a layout
They not just for controls you want many instances of
They let you treat that one cc as one control which, logically, it is
It helps keep things “contained” so you can create that control in isolation and use it as that one control rather than having to deal with several buttons etc that are all supposed to collectively act as one control

And if you add event definitions to it and drag it onto a layout you can just handle the events right there same as if you had a button & added the action event

EDIT : and I can even give you a concrete example of where a container makes life simpler even though there’s only one instance on a layout.
On many dialogs in the IDE we have OK & Cancel buttons.
But on Windows & Linux those should be arranged one way, and on OS X another.
So we created one container control that has 3 buttons that we can moved around appropriately for OK and Cancel buttons depending on what platform the IDE is running on.
And that CC they are in has events so we know which buttons was pressed.

This way on every layout we use this control we just implement the code to handle the the buttons - and NEVER have to worry about code to swap button around because we’re on Windows, Linux or OS X.
We wrote that code once and are done with it and we can just use the CC all over and deal with the events.

This is all really interesting and useful. The window I’m dealing with right now is pretty unique to the app and I’ve gone the no container route since starting the thread. But other windows will have more things in common and so a good container control may be easier to implement in the long run.

It’s nice and even reassuring to know that it’s fair practice to use event definitions to catch the events of controls that are in the cc. Thanks everyone, for the insights.

[quote=330949:@Norman Palardy]On many dialogs in the IDE we have OK & Cancel buttons.
But on Windows & Linux those should be arranged one way, and on OS X another.
So we created one container control that has 3 buttons that we can moved around appropriately for OK and Cancel buttons depending on what platform the IDE is running on.
And that CC they are in has events so we know which buttons was pressed.

[/quote]
so you use it multiple times …

I’d still create a CC even if I only use it once - it keeps the places I use it simpler
And we do that as well in the IDE
The color picker for the code editor in preferences is a CC we use once

It helps keep your layouts from having thousands of controls that you have to manipulate as a group