Есть объект класса TList, который содержит ссылки на кучу других объектов.

Как это все нормально сохранить в файл и так же без особых заморочек потом все это дело из файла подгрузить?

Цитата(Cheba @ 2.7.2005, 16:56)

Есть объект класса TList, который содержит ссылки на кучу других объектов. Как это все нормально сохранить в файл и так же без особых заморочек потом все это дело из файла подгрузить?

Ссылки на объекты бесполезно сохранять. Винда все равно расположит все по другому при следующем запуске.
Нужно сохранять данные объектов.
В объекте нужно сделать метод SaveToFile (SaveToStream) в котором вручную сохранять все поля.
При сохранении перебираем все объекты, сохраняем их в файл.
В объекте создаем метод LoadFromFile (LoadFromStream) в котором читаем все поля.
Создаем TList.
Открываем файл и создаем поочередно все объекты, подгружая данные.
Запихиваем объекты в TList.
Все придется делать вручную... Автоматики здесь нет никакой.

Цитата(Snowy @ 4.7.2005, 13:51)

Ссылки на объекты бесполезно сохранять. Винда все равно расположит все по другому при следующем запуске.

Это я знаю. Именно поэтому (и потому, что я ленивый) возник вопрос.

Сначала думал применить TWriter и TReader. о оказалось, чтоони тоже не выкупают как сохранять такие объекты. Да и из одного файла, наверное, не получится подгрузить таким образом много объектов. А их очень много тысяч 70. А столько файликов плодить неохота...

Цитата(Cheba @ 4.7.2005, 14:50)

Это я знаю. Именно поэтому (и потому, что я ленивый) возник вопрос.

До сих пор ничего универсального не придумано. Приходится самому...

Цитата(Cheba @ 4.7.2005, 14:50)

Да и из одного файла, наверное, не получится подгрузить таким образом много объектов. А их очень много тысяч 70. А столько файликов плодить неохота...

Откуда такие странные мысли? Очень даже получится.
Открываем файл стримом, а потом передаем указатель на этот стрим функциям сохранения или чтения. Все очень даже получится.
А плодить тысячи файлов это точно бестолковая затея.

А как бфть, если эти объекты должны занимать определенное положение в списке? При чем могуть быть и нулевые поинтеры в списке на некоторых местах. То есть этот TList может содержать в середине списка nil. И если сохранять список, то нулевые указатели, конечно же, будут пропускаться, а сами объекты не знают на каком месте в списке они находятся. При подгрузке из файла TReader'ом вряд ли удастся восстановить весь список вместе с нулевыми указателями. Или я опять ошибаюсь?

Цитата(Cheba @ 4.7.2005, 15:20)

А как бфть, если эти объекты должны занимать определенное положение в списке? При чем могуть быть и нулевые поинтеры в списке на некоторых местах. То есть этот TList может содержать в середине списка nil.

Если это так необходимо, то можно в файл сохранять пустой или левый объект, у которого в одном из полей будет прописан признак по которому при чтении можно будет определить, что это несуществующий объект. И в TList добавлять пустую запись.
Правда я не знаю зачем это может быть нужно...
Но тогда придется делать не метод объекта, а наследовать TList и в нем встраивать методы сохранения и чтения (поскольку нельзя выполнить метод от nil). Либо сделать для этого отдельные процедуры сохранения/чтения.

Унаследовался от TList. Даже работает.

Работет это так. При выходе из проги сохраняется состояние этого списка. При старте, если есть этот файлик, то объеты подгружаются из него. Вот только заметил, что если файлик битый, то приложение выдает мне ошибку и приложение не стартует. Как можно это дело предотвратить? Как проверить нормальный ли файлик? И если не нормальный, то не грузиться из него.

Битый в смысле не того вормата или какие-то данные повреждены?
Если не того формата, это можно пофиксить созданием заголовка файла.
Если заголовок не наш, то не открываем.
Если повреждены данные, то это можно вылечить путем добавления контрольной суммы к каждой записи. Если сумма не сходится, то два варианта:
1. Не грузим файл вообще.
2. Заполняем битые записи nil'ами, а пользователю кричим о повреждении данных.

...

Это сообщение отредактировал(а) Quadr0 - 14.7.2011, 22:34