Комрады, хотел уточнить. Проперть в OnDestroy юнита-хозяина по-прежнему доступна? И

еще уточнение: finalization юнита наступает раньше или позже OnDestroy?

И такая есть? Весело у вас там в лазаре... А зачем она нужна? Была бы это multi-event, подписка, я бы понял. А так...

При чём здесь Лазарь? Я пока на дельфях сижу 😊 Не так что насчёт моего вопроса?

До Inherited можно делать что желаешь, если вопрос был про класс

Проперти юнита не так

А финализейшн? Читал когда-то, но подзабылось...

Стикер

Ещё раз, в Дельфи НЕТ пропертей у юнитов и твой вопрос просто не имеет смысла

Деструктор виртуален

finalization юнита происходит после уничтожения Application

Ого, это мощный хрустальный шар! Точнее, после "end." :)

У девушки взял попользоваться, она ТЗ пишет со слов клиентов

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

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

Там где этот синглтон уничтожается.

т.е. в ондейстрой между фри и инхерайтед?

Можно тут. А можно там где вызывается Settings.Free

Стикер

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

вот Петер мне так и ответил https://t.me/Delphi_Lazarus/323666

Стикер

Оккама против :)

Стикер

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

Стикер

🤐

Стикер

вот эту возможность я и преследую, спрашивая то, в чем я не уверен :)

нет, ты ждешь удаления объекта. Я говорю -= не жди, делай в живом объекте. Мы разные 😊

каг? Пересоздать объект с новыми путями и перезалить туда содержимое текущего?

повторяю: "добавить в синглетон метод "перемести свой файл в другое место" - и пусть твой объект САМ поправит все свои внутренние пути

покажи примером, как? тело метода. Хотя бы схематично

type TMyMemIniFile = class(TMemIniFile) public procedure Rename(const newFileName: TFileName); reintroduce; end; { TMyMemIniFile } procedure TMyMemIniFile.Rename(const newFileName: TFileName); var oldFile: TFileName; begin if AnsiSameText( ExpandFileName(Self.FileName), ExpandFileName(newFileName)) then Exit; // raise error??? oldFile := Self.FileName; try inherited Rename(newFileName, False); UpdateFile; except inherited Rename(oldFile, False); raise; end; SysUtils.DeleteFile(oldFile); end;

1. закрыть текущий файл и освободить объект MemIni 2. переместить файл в новое место 3. открыть перемещённый файл, создав новый MemIni 4. ??? 5. Profit!

не нужно ничего уничтожать, эти объекты не держат файл открытым! но с tinifile другие сложности, там не полный путь к файлу по особым правилам считается. Там вообще путь к файлу может быть пустой строкой

Вот как раз я и спрашивал, в каком месте удобнее сделать п.п. 1 и 2 Щас Димин метод попробую

Стикер

ни в каком! открой исходники TMEmIniFile наконец, они крохотные. Вот я например их сейчас открывал особенно tmeminifile.loadvalues и tmeminifile.updatefile

Когда-нибудь я с этого буду начинать писать программы. А пока проще спросить здесь 😊

У тебя класс сохранялка держит файл чтоли в локе? Впрочем пофиг, даже если держит, при переназначении пути говоришь сохранялке чтобы он отцепился от текущего и свалил все свои данные по новому пути, после чего старый файл просто грохай. Если она такого не умеет, тогда грохаешь сохранялку, создаешь с новым путем, сохраняешь чо надо, грохаешь старый. Все делается в сеттере.

Не держит, сохранялке поменять путь надо. Дима показал, как.

Блин, у TMemIniFile есть штатный метод Remane, а я наследовался от TCustomIniFile, где это еще не реализовано. Кабы раньше знать 😊

Use the source, Luke

Да ну тебя :) Эту фразу можно всегда писать первой в любом ответе Я тупо взял примеры из справки дельфей, там зачем-то указан предок TMemIniFile

Понятно зачем. Чтобы избежать tight coupling. Консьюмеру должно быть все равно, кого ему дали. Даже если treginifile

Сколько времени ты протрахал на переписывание справки и переписывание с чатегом? Я на запуск дельфы, открытие inifiles и поиск процедур с названиями типа renamе, и потом написанием плюс-минус готового кода потратил 10 минут. Вот и думай, точно ли ты съэкономил время... Так что да, UTSL

Дим, есть вещи, которые для меня новые. Естессно, я всех нюансов не знаю. Я боюсь представить, сколько у тебя времени ушло на то, чтобы получить тот багаж знаний, который есть сейчас :)))

Видишь ли, у меня знаний было ноль. Точнее было знание, что ты хочешь использовать tmeminifile. Всё! Остальное - опыт ковыряния в чужом коде, и быстрого поиска. В гугле, в стековерфлоу, в исходниках, в стандартах, иногда в доках. Дано, док хочет перетащить tmeminifile на другое место, с сохранением данных, и вероятно удалением старого файла. В доки можно не смотреть, хотелка экзотическая, там такого 95% не будет. Что надо? 1. Понять, как именно твой выбранный класс сохраняет данные. 2. Понять, как он вообще знает, куда сохранять. 2.1. ...А для этого понять как он созраняет. Ведь чтобы сохранять он должен узнать куда. 3. Проверить, а вдруг велосипед уже готовый есть Открываем твой избранный класс и идём по списку. Ого, есть готовый rename... ...а нет, он не готовый, он теряет свои данные. А нет, не обязательно теряет. Ок, запомнили в блокнотик, надо вызывать rename(..., false) Так, как же он пишет?... ...ладно,тут я заранее знал про updatefile, потлму что когда-то попадал на не совместимость win98 и winnt. Но если бы не знал - я в просто прочитал код деструктора и нашёл бы его, +1 минута. Всё, больше не нужно ни-чё-го. Садимся и пишем процедурку, которая это все делает

Дим, ну и зануда же ты 😅