Где предлагается хранить настройки плагина?

[Skaurus]

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

В общем, сабж и заранее спасибо.

[SCHMaster]

Согласен на все 100%.
Но... Есть два варианта слету.
1 - Я использую путь "...Application Data\Download Master\lists"(myIDmInterface.DoAction('GetListDir',''))
2 - Можно усторить как в плагинах к ТС. Там при ицициализации дается имя INI файла. Нужно только оригинально озаглавить секции . И если плагин ненавороченный, то вполне хватает и этого. Хотя лично я делаю всегда свои INI-шники, дабы избежать путанницы.
Авторы, что скажете? Может стоит устроить что-то типа папки PluginSettings myIDmInterface.DoAction('GetPluginSettingsDir','')?

[spleenJack]

ИМХО, вполне нормально хранить настройки рядом с плагином (я так делаю). Ну или в Application Data\Download Master

[Skaurus]

А я xml рядом с плагином положил. Зачем далеко ходить Но поиск компонента для работы с xml и обучение работе с ним стоило где-то двух-трех вечеров мытарств.
Я вот чего предлагаю. Добавить в АПИ функцию сохранения настроек плагина, с тремя параметрами - имя плагина (это можно и из myPluginName брать), имя опции, значение. Еще лучше 4 - имя плагина, имя опции, атрибут, значение - чтобы можно было получить структуру как у строки:
<Wrap enabled="yes" value="80"/>
Одна опция, с ней связано два атрибута - enabled и value, и 2 значения, соотв.

Вот. А куда эта функция АПИ будет писать настройки, это уж глубоко пофигу
Ну и симметричная функция получения этих значений.

[ZETZET]

Удобнее было бы добавить в интерфейс плагина пару методов, которые ДМ и будет вызывать для каждого плагина.
Что-то навроде такого:

Code: Select all

procedure TMyPluginWriteData(Writer: TWriter);
begin
    // здесь плагин сохраняет свои данные. остальной механизм сохранения плагин не интересует
  Writer.WriteString(FStringField);
  Writer.WriteInteger(FIntField);
  Writer.Write(FRect, SizeOf(FRect));
end;

procedure TMyPluginReadData(Reader: TReader);
begin
    // здесь плагин читает свои данные. остальной механизм сохранения плагин не интересует
  FStringField := Reader.ReadString;
  FIntField := Reader.ReadInteger;
  Reader.Read(FRect, SizeOf(FRect));
end;

А где и как хранить все эти данные, пусть ДМ соображает

[Korney San]

Удобнее было бы добавить в интерфейс плагина пару методов, которые ДМ и будет вызывать для каждого плагина.

А если нужно считать/записать какой-то параметр "в середине" работы?
ПМСМ вызывать должен всё-таки плагин.

А где и как хранить все эти данные, пусть ДМ соображает

Это точно. Хотя обычно ini возле плагина всё-таки лучше.

[ZETZET]

Code: Select all

А если нужно считать/записать какой-то параметр "в середине" работы?

- ну это редкий и частный случай, тобишь трабл самого плагина(можно добавить механизм оповещения ДМ об желании конкретного плагина пере\сохранить свои данные). А иначе в плагинах надо писать один и тот же в принципе код в плане сохранения данных. А ДМ может хранить данные в структурном файле (StgCreateDocFile(), StgOpenStorage()) в разных секциях... Ну в общем это моя имха, мне такой механизм сохранения кажется наиболее удобным.

пс. А что такое ПМСМ?

[Korney San]

... А иначе в плагинах надо писать один и тот же в принципе код в плане сохранения данных. ...

А то ж! Из-за этой мудотени я разработал целую "универсальную систему настроек". Теперь вместо задания горы переменных и тупого перечисления ReadString, ReadInteger и прочего я пишу десяток вызовов определения и один вызов сохранения.

пс. А что такое ПМСМ?

IMHO = In My Humble Opinion = По Моему Скромному Мнению = ПМСМ
Таки мы русские