-
Возможно ли обращатся к объектам примерно так:
for i:=1 to 100 do
button[i].visible:=false;
-
1) Создать массив из TButton
2) FindComponent (button+IntToStr(i)) (вроде так было)
-
> 1) Создать массив из TButton
> 2) FindComponent (button+IntToStr(i)) (вроде так было)
а не "button"+IntToStr(i)) ?
-
> Возможно ли обращатся к объектам примерно так:
for I := 0 to ComponentCount — 1 do
if Components[I] is TButton then
(Components[I] as TButton).Visible := False;
-
> а не "button"+IntToStr(i)) ?
Так правильней :))
-
Обращение к объектам по именни. [D7, WinXP]
Возможно ли обращатся к объектам примерно так:
for i:=1 to 100 do
button[i].visible:=false;
Это не по имени.
-
> Kolan © (31.03.08 09:24) [3]
AS приводит к повторной проверке. Она не дает ничего, кроме ненужных потерь.
-
> Семеныч (31.03.08 11:45) [6]
я ему уже говорил :) видимо подзабыл... :)
-
> Обращение к объектам по именни. [D7, WinXP]
>
> Возможно ли обращатся к объектам примерно так:
> for i:=1 to 100 do
> button[i].visible:=false;
>
> Это не по имени.
Почему собственно нет?
бутону любое имя мона задать например
for i:=1 to 100 do
knopka[i].visible:=false
-
knopka[i].visible:=false
И где здесь "по имени"?
Здесь по индексу.
-
Пример условный. мне просто было интерестно можно ли обращатся к объектам сгнерироваными именами типа
s:= некоторые вычисления.
объект(s).color := red .
-
где ты увидел сгенерированные имена?
ты увидел сгенерированные индексы массива.
-
knopka[1].name := 'имя';
knopka[1].visible := false;
knopka[1].name := 'другое_имя';
knopka[1].visible := true;
Если имя меняется, то при обращении "по имени" должен был измениться программный код. А он как был так и остался knopka[1]
-
Допустим простая игра на интуицию поле 5 на 5 (25 кнопок). пользователь тыкает одну после чего комп рандомно выбирает из этих 25 одну и меняет ее цвет.кнопки названы H1-H25.
S11click....
begin
i:=
s:='H'+inttostr(random(25));
Объектпод именем(s).color:=red;
end;
Это обращение по индексу или по имени?
-
> кнопки названы H1-H25
Имена для этой цели нафиг не нужны, достаточно организовать двумерный массив объектов-кнопок.
-
Это обращение по индексу или по имени?
Это не обращение вообще. Это желаемый псевдокод.
-
> Гость (31.03.08 14:09) [13]
по имени
-
> Имена для этой цели нафиг не нужны, достаточно организовать
> двумерный массив объектов-кнопок.
я довольнотаки недавно в программировании и много не знаю..а как создать такой масив? или хоть литературку посаветуйте а то я тока о базах в основном чтил.
-
> AS приводит к повторной проверке.
Ты по это?
TButton(Components[I])
-
> [17] Гость (31.03.08 14:30)
> как создать такой масив?
type TArrButt = array of array of TButton;
var ArrButt: TArrButt;
..................
begin
SetLength(ArrButt, 5, 5);
...
begin
ArrButt[2,3].Visible:=False;
В принципе и одномерного массива для этой задачи хватит, или я неправильно понял [14] (
> [18] Kolan © (31.03.08 14:31)
> Ты по это? TButton(Components[I])
нет смысла as использовать на пару с is... Если проверка is прошла, то прямое приведение достаточно...
-
> или я неправильно
т.е. не неправильно, а недопонял)
-
> Если проверка is прошла, то прямое приведение достаточно
Шас лень рыться в справке по as
Я всегда делаю так, но уже не помню точно почему это хорошо :).
Но вот первое попавшееся из Controls.pas:
function TControlActionLink.IsPopupMenuLinked: Boolean;
begin
Result := (Action is TCustomControlAction) and
(FClient.PopupMenu = (Action as TCustomControlAction).PopupMenu);
end;
-
Здесь это оправдано страховкой от отключения сокращенных вычислений булевых выражений и в пользу лаконичности кода. Тогда как в
If (obj is TSomeClass) Then TSomeClass(obj)
выглядит куда лаконичней и работает куда оптимизированей
-
> Kolan © (31.03.08 15:12) [21]
> > Если проверка is прошла, то прямое приведение достаточно…
>
> Шас лень рыться в справке по as… Я всегда делаю так, но
> уже не помню точно почему это хорошо :).
>
> Но вот первое попавшееся из Controls.pas:
Это из серии "В огороде бузина, а в Киеве дядька".
PS. Твоё домашнее задание, узнать почему приведённый тобой кусок и близко не подходит к тому высказыванию, которое ты пытаешься опровергнуть.
-
> Я всегда делаю так, но уже не помню точно почему это хорошо
потому что по-другому не умеешь
-
> Плохиш © (31.03.08 15:25) [23]
>
> > Kolan © (31.03.08 15:12) [21]
> > > Если проверка is прошла, то прямое приведение достаточно…
> >
> > Шас лень рыться в справке по as… Я всегда делаю так, но
>
> > уже не помню точно почему это хорошо :).
> >
> > Но вот первое попавшееся из Controls.pas:
>
> Это из серии "В огороде бузина, а в Киеве дядька".
>
> PS. Твоё домашнее задание, узнать почему приведённый тобой
> кусок и близко не подходит к тому высказыванию, которое
> ты пытаешься опровергнуть.
Лучше объяснить, чем отличается приведение class(Object) от (Object as class), чем менторством заниматься.
class(Object) - прямое приведение типа. обращение к объекту происходит как к объекту класса class
(Object as class) - в этом случае приведение происходит после проверки, является ли объект класса class, его наследником или nil.
В случае отрицательной проверки поднимается исключение.
-
> Гость
Только перед этим:
> ArrButt[2,3].Visible:=False;
но после этого:
> SetLength(ArrButt, 5, 5);
(в принципе можно использовать и статический массив, тогда это(SetLength) не нужно будет)
- нужно еще и занести объекты в массив. т.е. нечто так: ArrButt[0,0]:=button1; и т.д.
-
> {RASkov} © (31.03.08 16:48) [26]
> - нужно еще и занести объекты в массив. т.е. нечто так:
Снова здарова ;) Есть уже такой - Controls.
Hint: за валидностью элементов оного списка уже следят.
Как, собс-но, и за Screen.Forms
--
Regards, LVT.
-
> [27] Leonid Troyanovsky © (31.03.08 17:51)
> Снова здарова ;)
Привет:)
> Есть уже такой - Controls.
Есть-то оно есть, и ни я и никто его не отменял... просто Сергей М. предложил как вариант... а я вот тут взялся на свою голову разжовывать :)
Причем вариант относительно не плох, так как есть возможность сгруппировать объекты на общем родителе...
Можно конечно же их групировку организовать Тэгами там всякими, или еще как, но массив(или список) тоже не плохо, имхо.
> Как, собс-но, и за Screen.Forms
Кстати, это хоть из другой оперы, но более подходит в той "опере" :)
Опять же, если только при единичном существовании формы.)
Можно конечно и считать кол-во нужных форм в общем списке.... в общем это уже не по этой теме... сорри..)
-
> потому что по-другому не умеешь
Конечно, я не умею вместо
(Components[I] as TButton).Visible
написать
TButton(Components[I]).Visible
это для меня слишком.
По сабжу, я бы сделал потомка кнопки, с двумя полями XY и создавал бы его (все равно динамически кнопки генерить).
XY заполнялись бы при создании.
При клике на такой кнопке, извлеч её «координаты» проще простого.