-
Собственно задача стоит в том чтобы сохранить свойство в dfm неким альтенативным образом.
Есть некий classА и classB входящий в classА.
Я хочу чтобы classB сохранялся иначе чем он сохраняется IDE по умолчанию.
Через DefineProperty это реально. Но нужно отменить стандартное сохранение. Для этого можно написать:
property x:TClassB .... stored False;
Можно ли то же самое сделать изнутри ClassB чтобы ClassA не нужно было править?
-
Не публиковать ClassB свойства или для всех ClassB свойств запретить сохраниение
-
Публиковать нужно.
>или для всех ClassB свойств запретить сохраниение
O!!!! Это идея :)))
-
А может есть ещё пути? А то ведь это во всех наследниках ClassB придётся поля таким же образом писать :(
Может есть альтернативные пути подменить стандартныую процедуру сохранения?
-
А что трудно в наследнике написать stored False ???
Честно говоря - непонятный велосипед
-
Если наследник пишу не я то это уже некое правило которое должно быть описано толково и мало того ещё и должно быть прочитано. Ведь пропустят же. Да и сам через годик забуду... Т.е. хотелось бы чтобы хитрости реализации пользователям были неведомы.
-
Если наследник пишу я и вижу что моё свойство не сохраняется - долго рву волосы и забрасываю форумы вопросами
-
Я же написал в что свойство будет сохраняться неким альтернативным образом. Т.е. я хочу подменить стандартное созранение. А не убрать его на 100%
-
Хотелось бы узнать как и для чего всё это нужно, может решение вовсе не здесь
-
да вот хочу заметить у коллекции родное сохранение на своё. Чтобы при создании элемента можно было задать класс отличный от того что по умолчанию.
-
У вас ошибка в ДНК. Не нужно менять поведение коллекций. Вам нужен список разных классов ? Так сохраняйте эти классы ? Уйдите от коллекций, они не для этого предназначены. Коллекции - список однотипных элементов. TCollection от TList ничем не отличаются.
-
Сдалась вам моя ДНК?
Я не получаю результат я изучаю среду.
Коллекции отлично хранят разнотивные элементы. Мало того созданные элементы отлично сохраняются и отображаются в инспекторе и дереве объектов!!!! Единственной проблемой является то что они при создании действиетельно создаются все одиноковыми. Если подправить вычитывание из dfm то я получу то что мне нужно минимальной кровью.
Вот я спрашиваю можноли как то порулить тем как коллекция создаётся из dfm?
-
Если подправить сохранение коллекций то это приведет к сохранению обычных вложенных компонентов. Напишите, в каком виде вы видите сохранение ваших компонентов
-
Вид может быть каким угодно. Главное что добавиться всего один параметр описывающий имя класса. Это можно сделать через DefineProperties.
При чтении важно чтобы я мог влиять на создаваемый объект путём создания объекта ранее сохранённого типа.
Ну например так в зависимости какое кусок кода замещать:
Columns = <
item
ClassType = TClassA
MaxWidth = 10
MinWidth = 34
end
item
ClassType = TClassB
MaxWidth = 36
end
item
ClassType = TClassC
MinWidth = 456
end>
Или так
Columns = <
item : TClassA
MaxWidth = 10
MinWidth = 34
end
item : TClassB
MaxWidth = 36
end
item : TClassC
MinWidth = 456
end>
-
Вид №1
Реализуется обычным вложенным классом, тип которого задаётся (если хотите) свойством элемента коллекции.
Вид № 2
Если выкинуть Columns - ничем не отличается от списка вложенных компонент аля TAction или TFields
-
Вариант №1 если я правильно понял будет содержать в каждой item по 2 класса. Сама Item и вновь соданный класс? А напрямую никак?
Вариант №2 TAction и TField наследуются от TComponent и там нету примера того как подменить стандартное сохранение. :(
-
Вариант 1.
Всё правильно, в зависимости от свойства ClassType создаётся/пересоздаётся внутренний класс. Напрямую никак - потому что коллекция - список однотипных элементов.
Вариант 2.
Ничего подменять не надо, всё и так уже готово. Сохраняется и тип элемента и его внутренние свойства, причём у каждого могут быть свои
object ActionList1: TActionList
Left = 336
Top = 96
object EditCut1: TEditCut
Caption = 'Cu&t'
end
object EditCopy1: TEditCopy
Caption = '&Copy'
end
object EditPaste1: TEditPaste
Caption = '&Paste'
end
end
-
>в зависимости от свойства ClassType создаётся/пересоздаётся внутренний класс
Можно тут поподробнее? Как я могу пересоздать сам себя? Ведь при присваивании некого свойства я должен буду пересоздать сам себя. Как это возможно?
>Ничего подменять не надо, всё и так уже готово.
Я про то что Если Item не унаследована от TComponent то фокус не пройдёт и сохраняться так как TAction и TField не будет.
-
2. А вам принципиально наследование TPersistent ? TComponent никак не подходит ?
1. Не нужно пересоздавать самого себя
TBaseSubClass = class(TPersistent);
TFirstSubClass = class(TBaseSubClass);
TSecondSubClass = class(TBaseSubClass);
TMyItem = class(TCollectionItem)
published
property MyClassType: TMyClassType read fMyClassType write SetMyClassType;
property SubClass: TBaseSubClass read fSubClass write SetSubClass;
end;
procedure SetMyClassType(Value: TMyClassType );
var Old: TBaseSubClass ;
begin
if fMySubClass = Value then Exit;
Old := fSubClass;
try
case Value of
FirstValue: fSubClass := TFirstSubClass.Create;
SecondValue: fSubClass := TSecondSubClass.Create;
end;
fMySubClass := Value;
Old.Free;
except
fSubClass := Old;
end;
end;
-
>2. А вам принципиально наследование TPersistent ? TComponent никак не подходит ?
нет принципиально конечно. Но возникают проблемы:
1. Малой кровью и легкой правкой коллекция я не отделаюсь.
2. TComponent содержит массу лишнего
>1. Не нужно пересоздавать самого себя
Про создать поле с нужным классом это понятно но это лишний уровень в дереве объектов что совсем некрасиво :(((
-
Вам не нужна коллекция, у вас разнотипные элементы
-
Это я уже слышал. Я побуду упрямым. Я хочу сделать по своему. Есть идеи кка? Я не хочу обсуждать альтернативные варианты.
-
> Я не хочу обсуждать альтернативные варианты.
проктологу расскажешь...
-
Хорошо. У вас есть некий список, элементы которого вы хотите сохранить в ресурс собственным способом, отличным от стандартного. DefineProperties вам в помощь.
-
>DefineProperties вам в помощь.
Это будет вариант 1 из [13] но нужно ещё как то пересоздать item
-
Если честно, то мне так и не ясно - зачем так уродовать коллекции. Вы хотите перестроить структуру (что бы создавались разнотипные Item-ы), вы хотите перестроить серриализацию.
А ради чего всё это ? Ради TCollectionEditor ???
-
Ради того чтобы не писать свою коллекцию которая в паре деталей отличается от родной. Т.е. само собой можно взять исходник от коллекции творчески его допилить подправив пару мест но как то это не красиво смотриться :( Тащить гору дублирующего кода вместо того чтобы подправить пару мест.
-
> Тащить гору дублирующего кода
Может вам лучше в сторону KOL посмотреть ???
-
>Может вам лучше в сторону KOL посмотреть ???
Меня не размер кода волнует а скорее некая условная красота кода. По которой исправленные 2-3 функции это красиво. Содранный целиком класс не очень.
Я как тот страус - лучше день потерять потом за 5 минут долететь (с) Мультик
Кстати возникла проблема :( Свойства которые сохраняет DefineProperty сохраняются в конце списка свойст а не в начале :(((
-
И в чём же здесь проблема ? Какая разница что и где сохраняется ?
-
> Ради того чтобы не писать свою коллекцию которая в паре деталей отличается от родной.
TList - тоже коллекция, и хранить можно что угодно, а сохраняете всё равно по своему. Чем не устраивает ???
-
>Какая разница что и где сохраняется ?
Если тип сохранён первым то при вычитывании есть возможность создать нужный класс и дальше он будет заполнен автоматом. Если же запись о типе класса последняя то поля отсутствующие в предке выдадут ошибку :(
>TList - тоже коллекция, и хранить можно что угодно, а сохраняете всё равно по своему. Чем не устраивает ???
Тем что для того чтобы с ней начать играться нужно написать как минимум сохранение и редактор. А с коллекцией я могу потихоньку копаться и править по кусочку а не целиком.
Есть новые 
Нет новых [134427 +34][b:0][p:0.002]