Глянула в сторону TMemIniFile. Когда вы делаете UpdateFile? Не могу

сообразить, потому как TIniFile у нас просто создается, по надобности из него читается, пишется, но сам он нигде не уничтожается

Я делаю при закрытии приложения, т.к. у меня в этом TMemIniFile настройки интерфейса, типа размер, положение окон, состояние чекбоксов и т.п. Проблема с обычным TIniFile на Delphi7 в том что он крайне медленно работает. За каждым параметром лазит в файл отдельно, предположительно открывая и закрывая файл. Но, если программа завершилась нештатно, то настройки в файл не сбросятся, останутся с прошлой сессии. Если запустить несколько экземпляров программы работающих с одним ini - то кто последний закроется, соответственно запишет этот файл - того и тапки.

Ну можно в onIdle приложения, если флаг Modified установлен у meminifile сохранять например

А я обычно после закрытия очередной модальной формы

Тоже можно, только непонятно зачем. :)

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

Не понял. Я при закрытии формы записываю в MemIni ее параметры, но на диск зачем записывать? У меня формы очень часто открываются/закрываются, зачем диск дергать? Закончим работу - запишем в файл, а до этого лежит в оперативке и туда же пишем/читаем, быстро. Насколько я понимаю, TMemIniFile при создании читает файл с диска, а по UpdateFile записывает себя на диск. По сути, файл - это средство обмена данными, а то что интерфейс/методы при работе с TMemIniFile такие же как и у TIniFile - это просто так совпало :)

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

А, вот в чем дело. Я немного попутал, я про jsontool говорил - там в пределах формы создаётся глобальный объект, хранящий настройки формы. TMemIniFile для меня новая штука, потом поизучаю

У меня сейчас ini-файл с настройками приложения имеет размер 92КБайт, при работе через TIniFile тормоза были очень заметными, после перехода на TMemIniFile вопрос с тормозами отпал.

Я на главной форме создаю глобальный объект INI - и все формы с ним работают. Один раз при старте программы он зачитывается из файла, один раз при закрытии программы записывается в файл. По большому счету, при таком подходе несущественно чего там внутри - ini или json.

А если программа внезапно упадёт, все настройки ранее закрытых форм всё?

а если она упадет во время сохранения, и тогда вообще хана))

Да, я только что про это тут писал. :) Настройки всё - только из последней сессии. А из предыдущей - как были в файле так и прочитаются. Файл же целиком пишется/ читается, а не по одному параметру, как TIniFile

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

Это не наш метод © 😊

600кб ) И это все в памяти держать? ))

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

Если эти 600кб - в одном экземпляре, а не на каждое окошко, то не вижу никаких проблем в этом размере.

Отсутствие глобального объекта для всей программы и необходимости взаимодействовать с ним из всех форм с тянущимися зависимостями в uses

А с объектом Database ты что, не так же взаимодействуешь? У меня Ini лежит на той же форме что и Database, поэтому в uses в 99,99% форм оно и так есть.

Это другое 😊

Двойных стандартов никто не отменял? :)

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

Честно говоря, я щас навскидку не вспомню, почему я решил сделать так, как описал. Вспомню - напишу

Я могу предположить, что компонент который сует настройки формы в json, не умеет этот json шарить с другими компонентами. Просто так написали, в расчете на одну форму.

Они читают/пишут все тот же один файл с конфигом. А, вспомнил. Есть форма с конфигурацией настроек приложения. Как только ты меняешь настройки приложения, изменения пишутся в файл. После закрытия этой формы, ниже лежащие/вновь открываемые формы сразу читают изменённые глобальные настройки из конфигурационного файла. Это касается тем и i18n

Если это одна и та же запущенная программа - то что мешает ей читать из своей памяти класса TMemIni/etc а не из файла? Зачем программа сама с собой через файл общается? Форма конфигурации пишет не в файл а в буфер в памяти, и все оттуда его и читают и туда пишут. Буфер один раз считывается из файла при старте, и один раз сбрасывается на диск, по окончании работы программы. Зачем чаще? Единственный аргумент сброса файла на диск - это если его читает кто-то еще. Но ты это не озвучил, или я не понял.

Э... У нас в кишлаке часто свет вырубают... нече?

А вам кроме ini-файла на компе больше сохранять нечего? ИБП не рассматривается?

Ок, вспомню все подробности - скажу 😊