Mattias Gaertner wrote:
On Thu, 29 Sep 2005 20:40:42 +0200
Marc Weustink <[EMAIL PROTECTED]> wrote:
Darius Blaszijk wrote:
[...]
But back to the basic question, what is the need: Why index by name ?
CheckBoxGroup's like RadioGroup's show their "components" based on a
number of items, that come from a resource (trough IDE) or from code. An
application that has internationalization typically will add the items
from code, namely add all resource strings of the items. So how can you
tell if a checkbox is set or not?? Well IMHO you can only do that by
checking the position of the items in the stringlist and then check the
checked property on that position.
Not by name. If you choose to use a checkboxgroup, then you have decided
to use it based on indexes.
That in your case it contains translated strings, doesn't matter. It is
no a reason to add this functionality.
If you don't have a fixed number of items, and you want to access the
individual items by "function", then your decision to use a
checkboxgroup is wrong.
You can have exactly the functionality that you want with a GroupBox and
individual checkboxes (which is mostly better since you can use fixed
horizontal spacing).
What spacing do you mean?
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.
[...]
so searching by name is improving readability and making the code more
robust.
And slows it also down.
True. But hardly noticable. TCheckGroup has seldom more than 20 items.
EditorOptionsGroupBox.CheckedByName[dlgUseSyntaxHighlight]
will always be more clear than
EditorOptionsGroupBox.CheckedByName[13]
EditorOptionsGroupBox.Checked[USES_SYNTAX_HIGHLIGH]
is also perfectly clear.
But requires some new constants.
Indeed, but the statement was about readability.
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.
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.
Marc
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
