Вообще сама мысль скрипт vs xml/jsn на дурку не тянет?

Тянет, конечно. Но у тебя же многие вещи на скриптах

Как юзер ZCADа могу сказать что тянет. Но насколько понимаю, человек не будет заниматься ручным редактированием этого всего в блокноте. Поэтому, надо делать так как проще и менее затратно для тебя

.ini 😜

Это не модно 😁

модный ini называется toml

Кстати, под дельфи есть какой-нибудь ини-парсер, чтоб руками не кодить?

Я понимаю, конечно, что нынче принято простые задачи решать сложными методами. Но не понимаю, зачем.

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

TStringList

они кроссплатформу пишут, в лине нет инишек

В файл нельзя текст писать?

ты готов писать весь обвес для инишек на базе стринглиста? типа автоматическое создание секции, замена существующего значения и т.п. :)

Делай так, как удобнее тебе. В эти текстовые файлы, кроме тебя все равно ни кто не полезет

хха :) Нам даже православные XML корежат т.к. думают что это текстовые :))))))))))

Заметь, в исходной задаче вообще ничего про секции. Достаточно хранилища в виде Key-Value. StringList - справится.

В самом лазаре есть всяческие TIniPropertyStorage, TXML...., но там возможности для кастомизации очень ограничены/сложны. Ну или мне так показалось

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

Формат неважен, ты прав, но как-то хочется по фен-шую

Ага, в базу данных записать.

XML

Ага, сначала в XML - потом в базу данных. Или в облако.

Тоже хорошая мысль, но в лазаре придется библиотеки с собой таскать, даже если sqlite использовать. Текст надёжнее

Ну, случаи всякие бывают, я для своего проекта писал хранилище свойств с экспортом/импортом в бинарный формат. Когда до конфигов дошло - просто его использовал. И редактор визуальный есть, и мультиплатформа, и никаких лишних компонентов не понадобилось. Но это просто вариант.

Да вот как-то не хочется на каждый случай велосипед писать. Я на лазаре это использовал https://www.getlazarus.org/json Помнится, автор писал, что он специально свел зависимости к минимуму, в дельфях вроде тоже можно использовать. Надо будет попробовать

Есть 2 подхода. 1) Статика. типа INI/XML/JSON/YAML/etc, в СУБД хранят. 2) Активный конфиг, на скрипте. Идея основана на том, что скрипт имеет доступ к данным/переменным/объектной модели приложения. Так делала еще Netscape, ну я там впервые увидел 😊. Mozilla унаследовала. Игры так "почти все" такие. Много кто так делает.

Серьезно? TIniFile

@eddoceddoc https://github.com/genericptr/fpTOML

Ну да, а что такого? В легаси проекте был компонент, сохраняющий настройки в реестре. Выпилил его нафиг вместе с другими "лишними" компонентами. Теперь настройки надо где-то хранить. Ищу оптимальный способ. "Ручное" управление оставил, как надёжный, но крайний случай

Я в свое время для хранения настроек форм делал связку с абстрактным хранилищем. То есть можно было хранить в любом хранилище вида key-value. Хранилища были реализованы ini, реестр, база.

Возьму на заметку 👍🏻👌🏻

Так в Лазарусе в программах реализовано хранение настроек. Можно выбрать реализацию JSON, XML, INI

Хотя немного другое конечно, как я понял, если в базе хранит также

Если про меня речь - я про дельфи спрашивал

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

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

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

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