Morning

Anybody stumbled across this requirement before? Essentially, a custom component that needs a dynamically variable number of child elements. Not too sure how to achieve this. Imagine a TBasicPanelControl descendant that needs to dynamically create child elements based on circumstances.

Regards
Mark

Mark Brooks wrote:

> child elements

Elements, or components/controls? The latter is easy. Mind it is easier if you just use a form if you are doing it at the high level.

If you are at the elements level, then I suspect you'd want to create the various elements and have "template" elements that you can use the designer for, and then replicate them appropriately at run time.

--

Matthew Jones

"Matthew Jones" wrote:

>>Elements, or components/controls? The latter is easy. Mind it is easier if you just use a form if you are doing it at the >>high level.

Yup, I've done the child component / control thing many times. This time I'm talking about a dynamic number of TElements i.e. defined within a corresponding interface and created within the component's overridden CreateInterfaceElements method.

Mark,

<< Anybody stumbled across this requirement before? Essentially, a custom component that needs a dynamically variable number of child elements. Not too sure how to achieve this. Imagine a TBasicPanelControl descendant that needs to dynamically create child elements based on circumstances. >>

Does it really need that, though ?  In terms of layout, making an element invisible effectively removes it from usage, so you *can* create elements and just make them invisible.

Could you possibly elaborate on what you're trying to accomplish ?  I can give you some pointers on how to accomplish what you want.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>>Does it really need that, though ?  In terms of layout, making an element invisible effectively removes it from usage, >>so you *can* create elements and just make them invisible.
>>
>>Could you possibly elaborate on what you're trying to accomplish ?  I can give you some pointers on how to >>accomplish what you want.

Hi Tim

I started doing this with visibility per your suggestion, specifically for a "star rating" control, where MaxStars was the number of elements available and NumStars was the number visible (if you get me). But what happens when a user comes along and says they want a "star rating" control that goes up to 20? The number of elements and the visibility management is getting a bit of a "pain". Make sense?

In another, more complex, component, I model a participant who can have a number of "forms" completed on their behalf. This number is variable. I'm currently using visibility for this too, but can see a time when it might get awkward.

Screenshots for both attached

Mark

And the other attachment .................

As an aside, it's actually variable duplication of a single element if that makes a difference

Mark,

<< I started doing this with visibility per your suggestion, specifically for a "star rating" control, where MaxStars was the number of elements available and NumStars was the number visible (if you get me). But what happens when a user comes along and says they want a "star rating" control that goes up to 20? The number of elements and the visibility management is getting a bit of a "pain". Make sense? >>

Sure, absolutely, but only if you are directly referring to each element by name (each element is a variable contained within your control class.  If you look at controls in EWB such as the TListControl class (WebLists), you will see that any time this type of duplication requirement comes up, EWB's code stops treating the value as a sub-element and starts treating it as a separate TControl descendant class.  In the case of the TListControl, it's the TListItem class.  The reason for this is two-fold:

1) The issue that you describe.

You don't want to start needing to manage arrays of elements in your control when EWB already does all of this for you.  Every control (TControl instance) is, out of the box, capable of managing/iterating over any controls that are contained within its client element.  And, all of this functionality is very easy to use, provided that you ensure that you don't mix and match TControl-descendant class types within the instances that are in the client element.  There are easy ways to do this, though.  For example, in the TListItem class, this is enforced with the InitializeProperties method:

procedure TListItem.InitializeProperties;
begin
  inherited InitializeProperties;
  CheckOwnerClass(TListControl);  <<<<<<<  Make sure that we're being created by a TListControl !!!
....

There is also functionality in EWB to ensure that a client class instance is only parented to a particular element in a parent control, etc.

2) Event dispatching.

You don't need to manage event dispatching for TControl descendant class instances, and you can easily forward dispatched events on to the parent TControl class instance.  This is *not* true for element instances.

I'll see if I can put together a rating control to illustrate the above principles.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>> I'll see if I can put together a rating control to illustrate the above principles.

Tim, that would be fantastic, even just a bare-bones framework. Once I get my head around the various things that need addressing I'll be off and running. So many components to make! Cheers.