On Thu, 29 Sep 2005 23:46:14 +0200
Marc Weustink <[EMAIL PROTECTED]> wrote:

> Mattias Gaertner wrote:
>[...]
> Spacing like http://www.dommelstein.nl/scrap/checkbox_spacing.png
> 
> If you would like to get the checks at a grid distance, you have to 
> tweak the heigth of the box.

Exactly. Do you want a TCheckGroup without auto fill?

 
> >>[...]
> >>>and inserting an item in the groupbox will not require to renumber all
> >>>other checkboxes.
> >>
> >>That is the disadvantage of using a checkboxgroup.
> > 
> > 
> > .. because it's missing the above function.
> 
> Indeed.
> What I argue is not about that function anymore, but what functions to 
> add and when. Are we going to add some random utility funtion to some 
> random controls ?
> That is my point.
> Another useful property would be the ability to enable/disable a 
> checkbox. Or to put it in a unknown/treestate.
> 
> While continuing to compare it to a dataset, maybe for this kind of 
> compound controls, something like TCheckboxGroup.Checkbox[AIndex]
> or (indeed) TCheckboxGroup.CheckboxByCaption would be handy.

Indeed.


> >>But that counts for 
> >>all controls where items are accessed through an index.
> >>
> >>Which brings me to the following. Why not for other controls like:
> >>RadioGroup -> ItemIndex
> >>ListBox -> Selected item
> >>CHeckedListBox -> Selected/Checked item
> >>Listview -> Selected/checked item
> >>Treeview -> selected node
> >>Toolbar -> button
> >>Grid.Captions -> caption
> >>.
> >>.
> >>etc....
> >>
> >>
> >>Hmmm... now thinking on it....
> >>if you compare this to datasets, on a dataset you can make its items 
> >>(=fields) persistent. WOuldn't that be an idea to add that to (some) of 
> >>the controls I mentioned above ?
> > 
> > 
> > I think, such functions are slow, but often needed anyway.
> 
> The reason I thought of it is the continuos trouble I have with for 
> instance grid.columns or statusbar.panels
> You only can access them by index. Having them as classfields makes life 
> easier. Like a dataset, those items doesn't have to be persistent by 
> default. We can for instance introduce a
>    property PersistentItems: Boolean default False;
> 
> Then it wont affect default behaviour, but only if the developer realy 
> wants them tor that specific control.

Sounds great. 


Mattias

_________________________________________________________________
     To unsubscribe: mail [EMAIL PROTECTED] with
                "unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Reply via email to