как изменить общее свойство разнотипных контролов

← →
Дмитрий (2016-02-12 18:09) [0]

Перебираю в цикле контролы, чтобы установить свойство ReadOnly
Однако
(Controls[i] as TCustomEdit)... не видит свойства ReadOnly

Как лучше установить ReadOnly для разнотипных полей?
В наличии
TDBEdit,TDBMemo,TDBDateEdit - общий предок TCustomEdit
TDBLookupComboBox - ...

← →
KilkennyCat © (2016-02-12 18:26) [1]

дописать этим контролам отлов сообщения. генерировать енто сообщение. пущай сами ловят и устанавливаются.

← →
Дмитрий (2016-02-12 18:38) [2]

можно ли поподробней?

← →
Юрий Зотов © (2016-02-12 19:19) [3]

Через RTTI.

← →
Юрий Зотов © (2016-02-12 23:45) [4]

В том же цикле:
if GetPropInfo(Controls[i].ClassInfo, "ReadOnly") <> nil then SetPropValue(Controls[i], "ReadOnly", true);

← →
Юрий Зотов © (2016-02-12 23:49) [5]

И больше ничего не надо, никаких предков и никаких сообщений. Только в uses добавить TypInfo.

← →
Германн © (2016-02-13 01:36) [6]

> Юрий Зотов © (12.02.16 23:49) [5]
>
> И больше ничего не надо, никаких предков и никаких сообщений.
> Только в uses добавить TypInfo.

В Д7?

← →
Leonid Troyanovsky © (2016-02-13 10:10) [7]

> Дмитрий (12.02.16 18:09)

> (Controls[i] as TCustomEdit)... не видит свойства ReadOnly

Есть простой способ - объявить
type TMyHackEdit = class(TCustomEdit) public property ReadOnly; end;
или просто:
type TMySimpleHackEdit = class(TCustomEdit);
Тогда
if Controls[i] is TCustomEdit then TMySimpleHackEdit (Controls[i]) := False;

> Как лучше установить ReadOnly для разнотипных полей?

Универсальный способ показал ЮЗ.

Вполне жизнеспособны варианты с размещением полей
на панели или груп-боксе с управлением их Enabled or Visible.

Более гибкие схемы могут задействовать TAction

Но, в любом случае группирование контролов облегчает жизнь.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2016-02-13 10:13) [8]

> Германн © (13.02.16 01:36) [6]

> В Д7?

Буквально - D5+.
Принципиально - D2+, IMHO.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2016-02-13 10:16) [9]

> Leonid Troyanovsky © (13.02.16 10:10) [7]

> Тогда if Controls[i] is TCustomEdit then TMySimpleHackEdit
> (Controls[i]) := False;

if Controls[i] is TCustomEdit then TMySimpleHackEdit (Controls[i]).ReadOnly := False;
Sorry.

--
Regards, LVT.

← →
Юрий Зотов © (2016-02-13 11:39) [10]

> Германн © (13.02.16 01:36) [6]

Можно и в D7.

← →
Юрий Зотов © (2016-02-13 11:42) [11]

Почему я рекомендую RTTI ?

1. Самый компактный способ.

2. Универсальность. Можно менять состав контролов как угодно - код при этом не меняется.

← →
Германн © (2016-02-14 01:28) [12]

> Leonid Troyanovsky © (13.02.16 10:13) [8]

← →
Германн © (2016-02-14 01:33) [13]

> Юрий Зотов © (13.02.16 11:39) [10]
>
> > Германн © (13.02.16 01:36) [6]
>
> Можно и в D7.

Не знал. Буду теперь "программистом" чуть-чуть более гдубокого профиля. :)
До сих пор я знал только способ "
> или просто
".

← →
Дмитрий (2016-02-15 17:55) [14]

Спасибо, метод
Юрий Зотов © (12.02.16 23:45) [4] if GetPropInfo(Controls[i].ClassInfo, "ReadOnly") <> nil then SetPropValue(Controls[i], "ReadOnly", true);

замечательно работает.
Споткнулся на двух (одном) моментах:
Элементы меню и контролы, расположенные на панелях - внезапно отсутствуют в списке контролов формы.
)
Похоже, трудоемкость будет одинаковая, что присвоить все контролы в циклах, что вручную.

← →
Дмитрий (2016-02-15 20:02) [15]

Перешел от списка контролов к списку компонентов
for i:=0 to ComponentCount -1 do begin if Pos(Components[i].ClassName, "TButton,TBitBtn,TMenuitem")>0 then // <== begin if GetPropInfo(Components[i].ClassInfo, "Enabled") <> nil then SetPropValue(Components[i], "Enabled", false); end else if GetPropInfo(Components[i].ClassInfo, "ReadOnly") <> nil then SetPropValue(Components[i], "ReadOnly", true); end;

Какие существуют "изящные" проверки со множеством вместо
if Pos(Components[i].ClassName, "TButton,TBitBtn,TMenuitem")>0 then

← →
Игорь Шевченко © (2016-02-15 21:43) [16]

> внезапно отсутствуют в списке контролов формы.

Они внезапно присутствуют в списке компонентов формы.

← →
Юрий Зотов © (2016-02-15 22:17) [17]

> Дмитрий (15.02.16 17:55) [14]

> Элементы меню и контролы, расположенные на панелях - внезапно
> отсутствуют в списке контролов формы.

Ничего внезапного. Меню - это вообще не контрол. А те контролы, которые лежат на панели - они входят в список Controls своего родительского контрола. То есть панели, а не формы.

Но все компоненты (и контролы, и неконтролы) входят в список Components своего Owner"а. То есть, формы - если они накладывались на форму в design-time.

> Похоже, трудоемкость будет одинаковая, что присвоить
> все контролы в циклах, что вручную.

Вы бы описали изначальную задачу, простыми русскими словами. Обычно после этого находится самое простое и самое правильное решение.

> Какие существуют "изящные" проверки

Самое "изящное" - это выбросить вообще все проверки класса. Дело в том, что при этом способе никакие проверки класса вообще не нужны. Это универсальный способ, он работает для любых объектов. Переведите код на русский язык - что получится?
Если некий_объект имеет свойство Enabled, // А класс объекта безразличен то установить ему это свойство в true
for i:=0 to ComponentCount - 1 do if GetPropInfo(Components[i].ClassInfo, "Enabled") <> nil then SetPropValue(Components[i], "Enabled", false) else // Кстати, это else тоже можно убрать if GetPropInfo(Components[i].ClassInfo, "ReadOnly") <> nil then SetPropValue(Components[i], "ReadOnly", true); // Работу можно немного ускорить, если Components[i].ClassInfo // вычислять только один раз и запоминать в переменной.

← →
Дмитрий (2016-02-16 16:07) [18]

> Вы бы описали изначальную задачу, простыми русскими словами. Обычно после этого находится самое простое и самое правильное решение.

Одну форму могут открывать юзеры с разными полномочиями.
Соответственно категории активирую свои элементы.

> Самое "изящное" - это выбросить вообще все проверки класса. Дело в том, что при этом способе никакие проверки класса вообще не нужны. Это универсальный способ, он работает для любых объектов.

Проверяю здесь тип для того, чтобы Едиты не становились "серыми".
if Pos(Components[i].ClassName, "TButton,TBitBtn,TMenuitem")>0 then

> Дмитрий (16.02.16 16:07) [18]

Плохая проверка. Завтра, к примеру, появляется какой-нибудь TButtonEdit - и этот Edit станет серым.

Используйте свойство Tag. Ноль - не делать серым, единица - делать.

← →
Дмитрий (2016-02-16 17:21) [20]

Про тэг уже думал.
Т.к. это требует вручную перебрать все контролы для установки тэга, вариант отложил.

> Плохая проверка. Завтра, к примеру, появляется какой-нибудь TButtonEdit - и этот Edit станет серым.

Он не станет серым, он станет РидОнли, если его не внести в строку.
Меня смущает Pos и текстовые сравнения внутри цикла.
Хочется что-то вроде Components[i].Name in [Name1, ..., NameN]
При отсутствии вариантов, возможно внесу в теги категорию доступа, тогда
if Components[i].Tag in [Cat1, ..., CatN] then ... //либо case Components[i].Tag of Cat1, ..., CatN :

← →
DenisZ (2016-02-21 23:43) [21]

Удалено модератором

http://www.delphimaster.ru/articles/comparray.html#e - мож тут че поможет?

Удалено модератором

как изменить общее свойство разнотипных контролов Найти похожие ветки