Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.01.29;
Скачать: CL | DM;

Вниз

вложенные свойства-объекты   Найти похожие ветки 

 
race1 ©   (2004-01-14 16:42) [0]

как сделать свойства-объекты в свойствах-объектах, что бы изменение этих вложенных дважды свойств вызывало процедуру из моего компонента? может, есть шаблончик?

я делаю через ссылки на процедуры. т.е. при изменении какого-либо параметра во вложеннов объекте вызывается процедура из компонента, которая указывается при его создании. но при этом надо для каждого свойства создавать свой тип (tproc=procedure(avalue: sometype), ссылку на процедуру в компоненте, published св-во в дважды вложенном объекте-своействе и т.д., т.е. очень много лишнего кода.

можно ли как-нибудь данное дело оптимизировать? если понятна проблемма, конечно :))


 
Семен Сорокин ©   (2004-01-14 16:53) [1]

самую малость непонятно :) вот кодом бы сопроводить вопрос.


 
race1 ©   (2004-01-14 18:07) [2]

код:

TProcChangeProp: procedure(aprop: sometype);

toneprop = class(tpersistent)
private
fprop, fprop_, fprop___: sometype;
fchangeprop: TProcChangeProp;
public
procedure setprop(aprop: sometype);
published
property prop: sometype read fprop write setprop;
property changeprop: TProcChangeProp: write changeprop;
end;

toneprop.setprop(aprop: sometype);
begin
fprop := aprop;
fsetprop(aprop);
end;

tmycomponent = class(someclass)
private
foneprop: toneprop;
procedure changeprop(aprop: sometype);
public
constructor create;
published
property oneprop: toneprop: read oneprop write setoneprop;
end;

constructor tmycomponent.create;
begin
foneprop := toneprop.create;
foneprop.changeprop := self.changeprop;
end;

procedure tmycomponent.changeprop;
begin
DoSomething...
end;

это код для одного св-ва. если добавлять ещё св-ва, то надо для каждого св-ва добавлять 1-ну процедуру в tmycomponent, 1-ин фиелд в toneprop для ссылки на процедуру в tmycomponent, 1-ну процедуру setanotherprop. кроме того в конструкторе tmycomponent нужно указать все процедуры в tmycomponent, которые будут вызываться при изменении соответсвтующих свойст в tanotherpropу.

если я хочу иметь что-то вроде

+OneProp
someprop
someprop
someprop
+TwoProp
someprop
someprop
someprop
+ThreeProp
someprop
someprop
someprop

т.е. иного вложенных св-в, то меня ждёт геморрой :) вот этот избыточный код можно ли сократить?


 
Семен Сорокин ©   (2004-01-14 18:50) [3]

может можно использовать что-то типа:
procedure SetProp(AProp: variant; ANumProp: integer);


 
Юрий Зотов ©   (2004-01-14 18:53) [4]

> race1 © (14.01.04 16:42)
> может, есть шаблончик?

Есть. Это события. Посмотрите в коде VCL, как реализованы свойства с именами, начинающимися с "On".


 
race1 ©   (2004-01-15 13:51) [5]

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

думаю, наилучшим будет либо [3], либо иметь одну процедуру в tmycomponent, которая будет вызываться при изменении любых свойств у oneprop, twoprop и.т.д, где в аргументе будет передаваться информация о том, какое св-во мы изменили


 
Семен Сорокин ©   (2004-01-15 14:12) [6]

race1 © (15.01.04 13:51) [5]
работа с variant будет медленнее, нежели с избыточным кодом.


 
Юрий Зотов ©   (2004-01-15 14:38) [7]

> race1 © (15.01.04 13:51) [5]
> думаю, события мне не подойдут, опять же из-за избыточности
> кода.

С точки зрения ООП этот код вовсе не избыточный. С точки же зрения решения одной конкретной задачи - да, его можно считать избыточным.

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


 
race1 ©   (2004-01-15 17:07) [8]

я всё же пожертвую ООП :) я не вижу в этом ничего плохого - я наиболее для меня удобным способом решаю задачу...


 
Юрий Зотов ©   (2004-01-15 17:22) [9]

> race1 © (15.01.04 17:07) [8]

Естественно, никто и не говорит, что один способ заведомо хуже или лучше другого. Речь шла о том, что путь нужно выбрать, но уж после выбора нужно следовать ему до конца.

И если Вы выбрали путь без использования ООП - то тогда зачем вообще загонять переменные в поля объектов? Объекты - это ведь тоже лишний для Вашей задачи код.

Можно объявить их, как глобальные переменные для секции implementation, а для доступа экспортировать из модуля функции Get/Set - и в них вызывайте все, что угодно.


 
race1 ©   (2004-01-15 17:32) [10]

вот меня и пугает большое кол-во Get\Set. т.е. для каждого св-ва мне нужно (в простом варианте) одна Set в объекте-свойстве, из которой вызывается другая Set уже из "родительского" компонента, плюс указатель на эту ф-ю из родительского компонента. я решил это проще - при изменении любого фиелда в объекте-свойстве я вызываю всего одну Set родительского компонента и аргументом передаю то, какой фиелд мы изменили (TChangeField = (cfOne, cgTwo...) и, в зависимости от этого аргумента, делаю что мне нужно.

может мы просто по разному поняли данную проблему? ;)


 
ЮЮ ©   (2004-01-19 05:26) [11]

Moжет тебе помогут Array properties (indexed properties) (подробнее см.Help), напр.

TOneProperty = class(tpersistent)
private
FProp: array of TSomeType;
public
function GetProp(Idx: Integer): TSomeType;
procedure SetProp(Idx: integer; AProp: TSomeType);
published
property Prop[Idx: integer]: TSomeType read GetOrop write SetProp;
end;

Т.е. методы GetProp и SetProp - один, но в его параметрах присутстует Индекс



Страницы: 1 вся ветка

Текущий архив: 2004.01.29;
Скачать: CL | DM;

Наверх




Память: 0.49 MB
Время: 0.012 c
3-93362
WG
2003-12-30 12:13
2004.01.29
Как упорядочить записи в БД по алфавиту ?


14-93680
Teren
2004-01-02 01:51
2004.01.29
TStrings - странный клас какой-то


1-93523
Ломброзо
2004-01-18 14:48
2004.01.29
Освобождение CRITICAL_SECTION


14-93636
Soft
2004-01-08 04:01
2004.01.29
Магия или поток мыслеформ.


14-93687
SoX
2004-01-06 15:34
2004.01.29
Важные и срочные вопросы