Darius Blaszijk wrote:
On Thu, 2005-09-29 at 14:56, Marc Weustink wrote:
Thats why you usually create a func/proc for it.
IMO it can be perfecly added as local form method and no need to add it
in an inc.
I myself are not in favor of repeatedly occurring functions or
procedures in a project (or several projects),
Neither am I.
that extend functionality of classes.
I dounbt that it extents
I believe that the power of OOP is that you can inherit this
functionality from more basic classes.
I still see no real use. It may be the power of oop to extend things,
but it has to have value for most cases. We are not waiting for a one
size fits all component with functionaliti one seldom uses or which is
almost similar to an existing function.
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).
Now, like you say, I could add a method to the form and extend the forms
functionality, but I believe that it has nothing to do with the form.
It's in fact extending the functionality of the groupbox.
You need this functionality because of the desigh of your form, so
putting a function there is also valid.
By definition the resource strings used in the list are know to the code,
That you are using resource strings has nothing to do with this
functionality. It is just a side effect.
so searching by name is improving readability and making the code more robust.
And slows it also down.
EditorOptionsGroupBox.CheckedByName[dlgUseSyntaxHighlight]
will always be more clear than
EditorOptionsGroupBox.CheckedByName[13]
EditorOptionsGroupBox.Checked[USES_SYNTAX_HIGHLIGH]
is also perfectly clear.
and inserting an item in the groupbox will not require to renumber all
other checkboxes.
That is the disadvantage of using a checkboxgroup. 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 ?
Marc
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
