Today, I'm going to start to delve into a new RB 2005 feature -- ContainerControls. Before I continue, I would like to note that the ContainerControl is a Pro-only feature. However, you can still play along even if you don't have RB2005 Pro -- your apps will be built as a demo though.
Let's start off with a bit of a (recent) history lesson so that you can understand the background of the feature.
A ContainerControl is really a cross between a Canvas and a Window. It's like a Canvas in that it's a single control that can be used to do any number of things. But it's like a Window in that you can visually lay it out, and it can contain any number of child controls on it.
Under the hood, a ContainerControl is essentially a special hybrid just like I described above. So you'll notice a lot of similarities between it and a Canvas or Window, which may make it easier to work with.
So what does one use this new feature for, exactly? Well, anything they want to -- just like with a regular window. However, even better than a regular window, a ContainerControl can be reused across multiple windows. Essentially, it's just a container that houses any number of controls. So you can use it to do things like create an EditField/UpDownArrows control where the EditField is "combined" with the UpDownArrows and you can define a bunch of specific behaviors about it.
Another neat thing you can do is abstract cross-platform UI concepts into a ContainerControl. For example, you can make an OK/Cancel button group that automatically arranges itself properly depending on the platform you're running on. This way, whenever you need an OK and Cancel button, you can drag a single ContainerControl out and not have to worry about the UI design since it's taken care of for you automatically.
This sort of thing lets you design a UI component one time and use it any place you'd like. Heck, you could even encrypt the item and sell it if you'd like to (however, because it's a pro-only feature of RB, your end-users would need Pro as well). It's a very powerful new feature in the product.
We use ContainerControls all over the place in RB 2005. In fact, every editor you see in the product is a ContainerControl -- and many of them have ContainerControls embedded within them! It's certainly a feature we couldn't live without.
Next time, we'll get into how to design our OK/Cancel button group and see a bit more hands-on information about this neat new feature.
>> This sort of thing lets you design a UI component one time and use it any place you’d like. Heck, you could even encrypt the item and sell it if you’d like to (however, because it’s a pro-only feature of RB, your end-users would need Pro as well). It’s a very powerful new feature in the product.
OK, this answers a question that I have been trying to get an answer to for a while.
This severely limits the market of resellable ContainerControls; almost to the point that it may not be worth it since those that have the Pro version typically have the experience to create the control in the first place.
Now I don't mind that ContainerControls are a Pro-Only feature as long as there is some way to allow them to be compiled in Standard. For example: if the class is encrypted with a Pro license. Or if at some point when REALbasic can compile Plugins, maybe we can precompile the ContainerControl so it can be used in Standard.
They're buggy. For example:
- place a container control on the window
- in the window's open event put:
for i as integer = 0 to controlCount - 1
if control( i ) isa ContainerControl then msgbox "woot, we do have one"
next
It won't msgbox, since at runtime it's an EmbeddedWindowControl. So try this instead in the window's open event:
for i as integer = 0 to controlCount - 1
if control( i ) isa EmbeddedWindowControl then msgbox "woot, we do have one"
next
And be flooded with linker errors when you run it. It does work though. However, for container controls embedded at runtime, it won't. The container controls simply won't show (provided you check * isa EmbeddedWindowControl anywhere).
Messy.
-- SirG3
@Phil -- you hit the nail on the head; making plugins within REALbasic. Once you have that ability, then the controls market opens up a lot more.
@SirG3 -- feedback id?
Not sure if it is the feedback id that SirG3 is referring to, but here is the one that I entered into the system:
http://www.realsoftware.com/feedback/viewreport.php?reportid=vmfnvyve
http://realsoftware.com/feedback/viewreport.php?reportid=adhbcjkq
-- SirG3
Please fix more container control bugs. :^( ::cries::
Please report more with good sample projects that demonstrate the issues.
We use these things *all over the place* -- I'd say we're easily the biggest ContainerControl consumer out of the entire customer base. And we aren't running into any issues with them (we were -- but we fixed them all). That doesn't mean the issues don't exist -- but it does mean that it's certainly possible to use the feature.
In general is REAL Software using ContainerControls with the EmbedWithin method or by dragging the ContainerControls onto the Window Editor in the IDE?
Also, I am wondering if some of the issues (like bleed-though) are because of differences between the REALbasic 2005 IDE and the special in-house version of REALbasic.
To be honest, I am finding that I have more feature requests than bugs in regards to ContainerControls. Some issues like IsA (my report) are understandable and will be improved in the future as the feature matures.
This is totally killing a contract job of mine and holding back a feature in the client's app.
http://www.realsoftware.com/feedback/viewreport.php?reportid=ngpggatv
@Phil -- we use both methods. For things like ok/cancel button groups, they're dragged onto the window. Same with many elements within the editors. The editors themselves are made in code however.
The bleed-through issue would be an IDE one if it happens at design time. If it's at runtime, it's a runtime bug.
@Seth -- you aren't kidding, that's a pretty complex set of circumstances. If I get the chance, I'll look into the issue.
I have been having more and more problems with getting the ContainerControls to behave correctly after being dragged onto a GroupBox. Looking at the debugger, the ContainerControl has Nil set for the Parent.
I am going to spend some time figuring this out more and write up a report.
Be sure to check the control order so that the GroupBox is lower in the control order than the ContainerControl.
The preferences dialog uses ContainerControls inside of group boxes (the font pickers, for example) -- so I've seen it work. Those are dragged onto the window, not done in code.
Normally I do not pay too much attension to the control order except when it comes to controls on top of Parent controls. Thankfully the IDE makes it easy to tell if the control order is correct since selecting the ContainerControl on the GroupBox will show the GroupBox correctly highlighted in Red.
Like I said there is more involved that I need to research, but it seems like any modification to the ContainerControl (even in the code editor) has a *chance* of separating the ContainerControl from its Parent. I have found that dragging the control slightly, releasing it and then positioning it back again will sometimes correct the problem (until the next time it breaks again). There is no way to verify that the reposition has fixed the issue within the IDE, only by compiling can you check if it has reunited with its Parent.
@Aaron: THHHAAAAAAAAANNNNNKKKK YYYYYYOOOOOOUUUUU!!!!!!!!!!!!!
I dare say that if you fix this bug many others may be fixed as well and peace will rain down upon the earth!!! :^)