Ответ на »сообщение 396« (Cepгей Poщин)
___________________________

Там был пример конструировании списков с фильтрацией.
Задача: получить все четные числа.
Решение, например, на Python:

def getEvenNumbers(l):
  return [x for x in l if x % 2 == 0]

Конструировать список объектов и фильтровать его по значению свойства Enabled (или еще какого) ничуть не сложнее.

Но это уже проблема Delphi Language, а не подхода к решению.

Ответ на »сообщение 395« (panda)
___________________________
Там ссылка на статью, а у меня нет доступа. Может своими словами как-то...

Ответ на »сообщение 394« (Cepгей Poщин)
___________________________

В результате тревиальная конструкция
For i := 0 to ControlCount - 1 do
... на написание которой уходит секунд 15 превратится в сложную задачу.

Честно говоря, плохая конструкция ;-)
См., например, »сообщение 1878 в теме №366 на БП«

Ответ на »сообщение 393« (Geo)
___________________________
В-четвертых: допустим некто в будущем захочет перебрать все контролы на форме, после DisableCtrl это будет сделать гораздо сложнее. В большом проекте неделя будет затрачена только на поиски и определение смысла этой самой процедуры. В результате тревиальная конструкция

For i := 0 to ControlCount - 1 do
...

на написание которой уходит секунд 15 превратится в сложную задачу.
Потом, что будет если DisableCtrl вызвать несколько раз (по ошибке)? А если это происходит где-то в цыкле? А как это повлияет на последовательность перехода по tab?

Ответ на »сообщение 391« (Бел Амор)
___________________________
>>> Часть участников обсуждения считает, что при недостатке функционала стандартного компонента следует строго писать наследника, в котором этот самый функционал и добавляется.
Не знаю, кто так считает. Но только не я ;-)

Я восстал против другого. Типа, у CheckBox'а убираем Caption, рядом кладем TStaticText и т.д. По-моему, создавать видимость компонента с нестандартными свойствами путем слепления в кучу нескольких стандартных компонент -- это не есть гут. Во-первых, обработка  такого "составного компонента" ухудшается (скорость проприсовки, реакция на события и т.п.), во-вторых, зачастую остаеются мелкие "косячки", которые лично мне сильно режут глаз, в-третьих, проблемы могут возникнуть при переходе на другую тему (компьютер, версию ОС).

Так что такой прием я признаю только для одного случая: когда нужно срочно заткнуть дыру, обнаруженную за 5 минут до демонстрации программы Заказчику ;-)

Ответ на »сообщение 391« (Бел Амор)
___________________________

1. Писать наследника.
2. Делать дополнительную обработку в форме "по месту".
3. Писать отдельнолежащую процедуру.
4. Писать class helper.

Только ради одной этой фичи можно переходить на D2006 (TD). ИМХО, разумеется.

Поддержу усилиия уважаемого Geo по "поднятию темы".
При обсуждении вопроса »вопрос КС №49421« дикуссия плавно перетекла на обсуждение темы, более подходящей для этой ветки.
Попробую кратко сформулировать суть вопроса.
Часть участников обсуждения считает, что при недостатке функционала стандартного компонента следует строго писать наследника, в котором этот самый функционал и добавляется. Мол, "на то оно и ООП". Я считаю, что к решению этой задачи следует подходить более сбалансированно и кроме вышеуказанного метода вполне допустимы еще два. Итак, с одной стороны: жестко писать наследника, с другой - сбалансированное применение трех методов:

1. Писать наследника.
2. Делать дополнительную обработку в форме "по месту".
3. Писать отдельнолежащую процедуру.

Когда применять:

1. Нормальный универсальный вариант. Общий случай.
2. Если нужно добавить что-то, что требеутся только в одном единственном месте на весь проект и все сводится к паре обработчиков по паре строк. В качестве примера можно привести »вопрос КС №49421«
3. Если эта процедура позволяет реализовать что-то очень просто и очень универсально.

В качестве примера для пункта 3 приведу реальный кусок из моего модуля FormUtil
(сразу оговорюсь, что работаю с D6 и, возможно, в D2006 процедура HideScroll неактуальна):

//----------------------------------------------------------------------
// Назначение: Скрывает полосы прокрутки у TDBCtrlGrid
// Способ: Создает на месте CtrlGrid панель  с размерами,
// меньшими на размер полос прокрутки и пересаживает
// на нее CtrlGrid (назначает Parent для CtrlGrid)

procedure HideScroll(CtrlGrid: TDBCtrlGrid);
var
  Panel: TPanel;
begin
  Panel := TPanel.Create(CtrlGrid.Owner);
  Panel.Parent := CtrlGrid.Parent;
  Panel.Top := CtrlGrid.Top;
  Panel.Left := CtrlGrid.Left;
  Panel.Height := CtrlGrid.RowCount * CtrlGrid.PanelHeight;
  Panel.Width := CtrlGrid.ColCount * CtrlGrid.PanelWidth;
  Panel.TabOrder := CtrlGrid.TabOrder;
  CtrlGrid.Parent := Panel;
  CtrlGrid.Top := 0;
  CtrlGrid.Left := 0;
  Panel.TabStop := False;
end;

//----------------------------------------------------------------------
// Назначение: Делает указанный элемент запрещенным, но исключает внешние
// проявления, присущие прямому назначению Enabled=False
// Способ: Создает на месте элемента панель  с такими-же размерами,
// пересаживает на нее указанный элемент и запрещает панель

procedure DisableCtrl(Ctrl: TWinControl);
var
  Panel: TPanel;
begin
  Panel := TPanel.Create(Ctrl.Owner);
  Panel.Parent := Ctrl.Parent;
  Panel.Top := Ctrl.Top;
  Panel.Left := Ctrl.Left;
  Panel.Height := Ctrl.Height;
  Panel.Width := Ctrl.Width;
  Panel.TabOrder := Ctrl.TabOrder;
  Ctrl.Parent := Panel;
  Ctrl.Top := 0;
  Ctrl.Left := 0;
  Panel.Enabled := False;
end;

Если для HideScroll вполне применим и способ 1, т.е. создать наследника TDBCtrlGrid, то процедура DisableCtrl - гораздо более универсальный подход, т.к. сразу охватывает всех наследников TWinControl.

P.S. (задумчиво...) Переписать чтоли через with... (зевая...) можно будет убрать var...
P.P.S. ;)

Ответ на »сообщение 389« (Cepгей Poщин)
___________________________

Если отстреливать всех, кто игнорирует все предупреждения компилятора, то рикуешь остаться один со всем их немалым программным наследием, except end; и {$WARNINGS OFF}.
Ну... можно, например, найти работу, где разработанные программы в принципе не тестируются (чтобы не огорчаться). Но оно Вам надо? Если развитие культуры программирования не поддерживается (а даже наоборот) - это не повод снижать и свою культуру.

P. S. Будь на то моя воля, я бы предупреждение Return value of function ... might be undefined сделал бы ошибкой.
Ну так а я о чем толкую? ;-)
Если приходится рецезировать код, в котором стоит {$WARNINGS OFF} (или при компиляции выдаются предупреждения), я просто сразу отпинываю его обратно. Разумеется, автор кода может пойти к своему начальнику, моему начальнику и т.д. (вплоть до директора). Но почему-то так не делает :-)

Ответ на »сообщение 388« (panda)
___________________________
У меня выработалась привычка по меньшей мере с подозрением относиться к предупреждениям и подсказкам компилятора А у меня выработалась привычка дуть на холодную воду... Думаю не самя вредная.
Если отстреливать всех, кто игнорирует все предупреждения компилятора, то рикуешь остаться один со всем их немалым программным наследием, except end; и {$WARNINGS OFF}.
Кстати по быстродействию разница близка к ошибке измерения.
P. S. Будь на то моя воля, я бы предупреждение Return value of function ... might be undefined сделал бы ошибкой.

Ответ на »сообщение 384« (Max Belugin) и »сообщение 385« (Cepгей Poщин)
___________________________

Понимаете ли в чем дело. У меня выработалась привычка по меньшей мере с подозрением относиться к предупреждениям и подсказкам компилятора (и отстреливать - на работе - всех, кто пытается их игнорировать) ;-)
Исключения конечно, есть, но они могут распространяться на 1-2 строки и учитывать не все предупреждения, а только некоторые (например, Unsafe code).
Поэтому возможностей Delphi в этом плане мне хватает за глаза и за уши.