Получить все объекты на форме

← →
v_a_belousov (2010-10-12 23:39) [0]

Здравствуйте! Поискал в интернете, но так и не нашел каким образом можно получить все объекты имеющиеся на форме. То есть что то вроде...

for i:=0 to Form.ControlCount-1 do
begin
Control := Form.Control[i];
end;

Это я понимаю... Но вот что если на форме есть PageControl, на котором есть вкладки, в которых есть элементы? Каким образом тогда в общем виде должна выглядеть обработка?

Ведь не могу же я в цикле точно написать что-то вроде

Control := Form.Control[i].Control[i].Control[i].Control[i]; так как не знаю точно сколько и чего есть на форме... подскажите пожалуйста каким образом можно узнать что имеется на форме?

← →
Плохиш © (2010-10-12 23:43) [1]

Есть такое понятие - рекурсия.

← →
Плохиш © (2010-10-12 23:44) [2]

Хотя, после

> for i:=0 to Form.ControlCount-1 do
>

дальше можно не продолжать.

← →
v_a_belousov (2010-10-12 23:48) [3]

> Хотя, после
>
> > for i:=0 to Form.ControlCount-1 do
> >
>
> дальше можно не продолжать.

То есть?

> Есть такое понятие - рекурсия.

Да спасибо!

← →
KilkennyCat © (2010-10-12 23:52) [4]

неоднозначное решение. не все контролы создаются в момент.

← →
v_a_belousov (2010-10-12 23:54) [5]

> неоднозначное решение. не все контролы создаются в момент.

Например?

← →
KilkennyCat © (2010-10-13 00:16) [6]

Например, динамическая страница PageControlа, имплэйсэдитор, чекбокс в каом-нить виртуалтривью... да мильен примеров.

← →
Германн © (2010-10-13 01:55) [7]

> KilkennyCat © (12.10.10 23:52) [4]
>
> неоднозначное решение.

Непонятная задача, точнее будет сказать.

← →
v_a_belousov (2010-10-13 02:39) [8]

Задача получить все объекты на форме. Пока сделал вот так...

procedure GetObjects(Form: TCustomForm);
var i, i1, num: integer;
begin
//
if not Recurs then
begin
//
CC := 0;
for i:=0 to Form.ComponentCount-1 do
begin
//
num := Length(Components);
//
SetLength(Components, num+1);
SetLength(RComponents, num+1);
//
Components[num] := Form.Components[i];
RComponents[num] := Form.Components[i];
end;
//
CC:=Form.ComponentCount;
ComponentsCount:=0;
//
Recurs := true;
ShowMessage("Recurs"+inttostr(Length(Components))+" "+inttostr(Length(RComponents)));
end;
//
if CC<>0 then
begin
//
for i:=0 to Length(RComponents)-1 do
begin
//
for i1:=0 to RComponents[i].ComponentCount-1 do
begin
//
num := Length(Components);
//
SetLength(Components, num+1);
//
Components[num] := RComponents[i].Components[i1];
// ShowMessage("i "+inttostr(i)+"i1 "+inttostr(i1)+inttostr(Length(Components))
// +" "+inttostr(Length(RComponents)));
end;
end;
//
RComponents := nil;
//
ShowMessage("CC "+inttostr(ComponentsCount)+"LG "+inttostr(Length(Components)));
ComponentsCount := Length(Components)-CC;
CC := CC + ComponentsCount;
//
SetLength(RComponents, ComponentsCount);
ShowMessage("CC "+inttostr(ComponentsCount)+"LG "+inttostr(Length(Components)));
//
for i:=0 to Length(RComponents)-1 do
begin
//
RComponents[i] := Components[i+ComponentsCount];
// ShowMessage("RC " + inttostr(Length(RComponents)));
end;
// ShowMessage("CC "+inttostr(ComponentsCount));
//
if ComponentsCount=0 then CC:=0;
GetObjects(Form);
end;

Дальше буду поправлять...

← →
v_a_belousov (2010-10-13 02:40) [9]

Если нужно делать по другому подскажите пожалуйста как.

← →
Германн © (2010-10-13 03:17) [10]

> v_a_belousov (13.10.10 02:39) [8]
>
> Задача получить все объекты на форме. Пока сделал вот так.

Как учебное задание я ещё могу эту задачу принять. Но только после ряда уточнений.
" Получить все объекты".
Что есть объекты в данном вопросе (про задачу молчу).
Сначала искали контролы, потом стали искать компоненты.
Что дальше искать будем?

← →
v_a_belousov (2010-10-13 03:47) [11]

> Что есть объекты в данном вопросе (про задачу молчу).
> Сначала искали контролы, потом стали искать компоненты.
> Что дальше искать будем?

Нужно получить все объекты на форме(контролы, компоненты). Затем получить их свойства к примеру имя. Также у объектов есть события к примеру у кнопки OnClick. И эти события также необходимо получать.

← →
Игорь Шевченко © (2010-10-13 10:09) [12]

v_a_belousov (13.10.10 03:47) [11]

Скажи, зачем. Нам будет проще понять

← →
Плохиш © (2010-10-13 10:41) [13]

> v_a_belousov (13.10.10 02:39) [8]

Этот дерьмокод через пару секунд поднимет исключение переполнения стека.

← →
Dennis I. Komarov © (2010-10-13 10:59) [14]

> Этот дерьмокод через пару секунд поднимет исключение переполнения
> стека.

Даже прочитал его? %)

← →
Плохиш © (2010-10-13 11:01) [15]

> Dennis I. Komarov © (13.10.10 10:59) [14]

Поиск на слово exit сделал :-P

← →
v_a_belousov (2010-10-13 12:45) [16]

> Этот дерьмокод через пару секунд поднимет исключение переполнения
> стека.

Это часть кода одна из процедур... Исключения не вызывает. Все компоненты сохраняются в файл. ShowMessages - это я дописывал для себя так как функция вызывающая эту процедуру сидит в dll, как и сама эта процедура.

← →
v_a_belousov (2010-10-13 12:55) [17]

> Скажи, зачем. Нам будет проще понять

Затем чтобы получив в параметре моей функции форму TCustomForm взять из нее все объекты то есть построить список всех объектов формы с их событиями. И использовать их в другом месте. Вот пример:

есть форма с двумя кнопками и одним текстовым полем(TEdit) . Заранее мне неизвестно что есть на форме, то есть сначала мне нужно определить что на форме присутствует.

затем должен построиться список что то вроде

Form.Button1
Form.Button2
Form.Edit1

Причем у Button1 и т.д. все свойства должны быть сохранены. В том числе и обработчики их событий.

Все это дело сохраняется в файл.

После с помощью функции из dll загрузки объектов из файла я могу использовать эти элементы в других местах.

← →
Сергей М. © (2010-10-13 12:57) [18]

> v_a_belousov

"На форме" - понятие растяжимое.
Одно дело когда форма рассматривается как владелец неких компонентов (не обязательно контролов) , и совсем другое когда она рассматривается как родительский оконный контрол для неких других (дочерних, не обязательно оконных) контролов.
Соответственно и решения разные.

← →
v_a_belousov (2010-10-13 13:06) [19]

> Сергей М.

рассматривается как родительский оконный контрол для неких других контролов, которые в свою очередь тоже могут являться родителями контролов... и т.д.

← →
Сергей М. © (2010-10-13 13:08) [20]

> v_a_belousov (13.10.10 13:06) [19]

Тогда ComponentCount и Components[] идут лесом.
Вместо них следует пользовать ControlCount и Controls[] соответственно.

← →
v_a_belousov (2010-10-13 13:09) [21]

> родительский оконный контрол для неких других контролов,
> которые в свою очередь тоже могут являться родителями контролов.
> .. и т.д.

вот только как это может быть не могу понять. То есть у TControl ведь нет свойства Controls или Child но тем не менее на примере Form -> PageControl -> TabSheet -> Button каждый из них является Control"ом

← →
v_a_belousov (2010-10-13 13:11) [22]

> Сергей М.

Да но как? Может я запутался уже конечно совсем. Но у Controls[i] нет свойства Controls....

← →
Сергей М. © (2010-10-13 13:14) [23]

> у TControl ведь нет свойства Controls

За то есть у TWinControl.
Родительским контролом может быть только контрол, имеющий собственное окно.
А дочерние контролы свое собственное окно иметь не обязаны, хотя и могут, посему они могут быть как наследниками TWinControl, так и TControl. Но родителями доч.контролов могут быть только контролы-наследники TWinControl.
Форма - не исключение из этого правила, она тоже TWinControl

← →
v_a_belousov (2010-10-13 13:31) [24]

> Сергей М.

Спасибо большое)

← →
Юрий Зотов © (2010-10-13 14:59) [25]

> v_a_belousov (13.10.10 12:55) [17]

Намного проще сохранить в файл саму форму вместе со всей ее начинкой, всеми свойствами и событиями. Делается буквально в одну строчку - см. WriteComponent и ReadComponent.

← →
Юрий Зотов © (2010-10-13 15:03) [26]

> > v_a_belousov (13.10.10 12:55) [17]

Только кажется мне, что Вы неверным путем идете. Какова КОНЕЧНАЯ цель всего этого? Отсюда же ведь и плясать надо.

Только не надо отвечать "чтобы использовать в других местах", это Вы уже говорили. Ответьте - КАК ИМЕННО Вы собираетесь это использовать?

← →
DiamondShark © (2010-10-13 15:20) [27]

> КАК ИМЕННО Вы собираетесь это использовать?

Человек скиносвистелки делает:
http://delphimaster.net/view/2-1286809709/

← →
v_a_belousov (2010-10-13 17:23) [28]

> Человек скиносвистелки делает:

Не скиносвистелки а пытаюсь сделать свои собственные. А форму обрабатывать надо так как уже есть программа но внедрение в неё готовых вариантов не очень подходит...

> WriteComponent и ReadComponent

Знаю такое, но не подходит

> Какова КОНЕЧНАЯ цель всего этого?

После обработки формы, добавить все её объекты в список ComboBox к примеру. Этот ComboBox будет лежать на форме в моем редакторе скинов. В редакторе я создам объект для скина и назначу ему обработчики событий такие же как у выбранного элемента из ComboBox. Вот примерно такова конечная цель

> назначу ему обработчики событий такие же как у выбранного
> элемента из ComboBox.

Флаг Вам в руки :)

← →
v_a_belousov (2010-10-13 18:03) [30]

> > назначу ему обработчики событий такие же как у выбранного
> > элемента из ComboBox.
>
> Флаг Вам в руки :)

А что разве нельзя так сделать? Я могу ошибаться конечно, но по моему сделать такое возможно. Правда может вы не так восприняли фразу "назначу ему обработчики событий такие же как у выбранного элемента из ComboBox"... это же не в прямом смысле...

не рано?

← →
v_a_belousov (2010-10-13 18:42) [32]

> не рано?

почему рано? учиться и развиваться то нужно.

надо наследоваться от нужных компонент, и прописывать им нормальные события, а не пользовательские (батонокидательские) методы подменять...
в общем в типе, а не обьектах.

> почему рано?
сделай пару своих, нормальных компонент. почитай про ООП, и устройстве VCL. потом может время и придет.
а то ты вроде чукчи в анекдоте "что вижу то пою".

> Не скиносвистелки а пытаюсь сделать свои собственные. А
> форму обрабатывать надо так как уже есть программа но внедрение
> в неё готовых вариантов не очень подходит...

Это делается не так.

Пишется библиотека абстрактных элементов интерфейса. Это невизуальные компоненты, которые реализуют весь инвариант интерфеса. Из этих абстрактных компонентов строится объектная модель абстрактного интерфейса. Если написать кошерный дизайнер для IDE, то всё это будет красиво и мышкой. Весь прикладной код взаимодействует только с абстрактной моделью.

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

← →
v_a_belousov (2010-10-13 19:55) [35]

> надо наследоваться от нужных компонент, и прописывать им
> нормальные события, а не пользовательские (батонокидательские)
> методы подменять...
> в общем в типе, а не обьектах.

Для начала я хочу сделать чтобы в общем виде работало как мне нужно. Пусть это будет коряво, но чтобы работало. Что собственно сейчас у меня и вырисовывается. А дальше я уже буду больше изучать про то как все это сделать правильно и походу получения знаний превращать "корявое" в прямое.

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

Спасибо.

← →
v_a_belousov (2010-10-14 19:41) [36]

При проверке контрола на форме

...
if Form1.Controls[i] is TWinControl then действия;
...

Контрол определяется. При передачи формы в функцию

function SaveControls(Form: TCustomForm; FName: string): boolean;

при обращении Form.Controls[i] is TWinControl никогда не равно true

Подскажите что не правильно?

> v_a_belousov (14.10.10 19:41) [36]
> При передачи формы в функцию
> function SaveControls(Form: TCustomForm; FName: string): boolean;
> при обращении Form.Controls[i] is TWinControl никогда не равно true
Подскажите что не правильно?

Неправильна сама архитектура. DLL и EXE компилируются раздельно, поэтому класс TWinControl в EXE и класс TWinControl в DLL - это два РАЗНЫХ класса. Соответственно, is в DLL выдает false.

Варианты решения:
1. Использовать интерфейсную модель.
2. Компилировать EXE и DLL с run-time пакетами.
3. Использовать BPL вместо DLL.

> v_a_belousov (13.10.10 19:55) [35]
> Для начала я хочу сделать чтобы в общем виде работало как
> мне нужно. Пусть это будет коряво, но чтобы работало. Что
> собственно сейчас у меня и вырисовывается. А дальше я уже
> буду больше изучать про то как все это сделать правильно
> и походу получения знаний превращать "корявое" в прямое.

Такой подход возможен, но ОЧЕНЬ непродуктивен. Вы потеряете огромную кучу времени - сначала на создание неверного решения, а потом на ПОЛНОЕ его переписывание. Потому что его действительно придется просто выбросить и написать совершенно другой код, ничего общего с прежним не имеющий В ПРИНЦИПЕ.

Почему бы не пойти иным, нормальным путем? Сначала изучить, как решается Ваша задача, а уж потом писать код и в процессе учиться?

← →
v_a_belousov (2010-10-14 21:07) [39]

> Варианты решения:
> 1. Использовать интерфейсную модель.
> 2. Компилировать EXE и DLL с run-time пакетами.
> 3. Использовать BPL вместо DLL.

Спасибо, помогло.

> Почему бы не пойти иным, нормальным путем? Сначала изучить,
> как решается Ваша задача, а уж потом писать код и в процессе
> учиться?

Да получается что я делаю двойную работу, но и в этом есть свои плюсы... Во первых так как программа которую надо оформить уже существует, то пользователю не важно каким образом у меня это оформление будет сделано, а вот мне пересоздавать весь проект целиком сейчас не вариант так что это плюс. Во вторых библиотеку которую я сейчас делаю можно будет применять к любому проекту что тоже плюс. Перейти от этого корявого решения к правильному будет не так сложно(переписывать все целиком не придется) это я вроде бы предусмотрел. И к третьей версии программы я думаю все будет сделано уже так как нужно.

> а вот мне пересоздавать весь проект целиком сейчас не вариант так что это плюс.
вообще то при нормальном подходе изменений в проекте пришлось бы делать меньше... (в идеале вообще бы не пришлось)
ну для примера, есть грид стандартный, "убогого дизайна", меняешь его на "крутой и красивый" ExГрид, сколько изменений в проекте? фактически только тип переменной/обьекту поменяли и в юзес дополнительный модуль прописали.

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

ну вот смотри, делаешь ты скины компонентам, ищешь их в цикле/рекурсией, подменяешь пользовательские методы(само собой сохраняешь и перевызываешь то что пользователь/прикладник уже туда внес), а надо то описать один тип/класс и все, циклы/поиски становятся не нужны, т.к. по типу обьект создается тот, что нужен, и сразу "на местах", обработчики подменять/пользовательские сохранять не нужно т.к. не будут пересекаться, и т.д. у тебя код поменяется КООРДИНАЛЬНО. и то что ты сейчас делаешь после тебе придется "выковыривать", до практически исходного, нынешнего состояния. т.е. своим кривым методом ты не делаешь что то, ты это ломаешь.

представь, что этот ExГрид из первого абзаца написал ты, и сравни с тем что ты наваял сейчас для того же самого в программе своим методом. что проще использовать в дальнейшем в любом проекте? и что проще развивать?
по моему очевидно.

p.s. лучше день потерять, потом за пять минут долететь... чем неделю пешком. (первая часть © из мультика "крылья ноги хвост")

Получить все объекты на форме Найти похожие ветки