Page 1 of 1
Где предлагается хранить настройки плагина?
Posted: 04 Jun 2006, 4:38 Sun
by Skaurus
А то в ридми этой инфы нету, в директории программы ничего похожего нет, в реестре нет.
То есть я могу создать xml-файл рядом с плагином и там все хранить, но наверняка же есть какое-то унифицированное место?
А то ить разброд и шатание получается
В общем, сабж и заранее спасибо.
Posted: 07 Jun 2006, 3:42 Wed
by SCHMaster
Согласен на все 100%.
Но... Есть два варианта слету.
1 - Я использую путь "...Application Data\Download Master\lists"(myIDmInterface.DoAction('GetListDir',''))
2 - Можно усторить как в плагинах к ТС. Там при ицициализации дается имя INI файла. Нужно только оригинально озаглавить секции
. И если плагин ненавороченный, то вполне хватает и этого. Хотя лично я делаю всегда свои INI-шники, дабы избежать путанницы.
Авторы, что скажете? Может стоит устроить что-то типа папки PluginSettings myIDmInterface.DoAction('GetPluginSettingsDir','')?
Posted: 07 Jun 2006, 15:17 Wed
by spleenJack
ИМХО, вполне нормально хранить настройки рядом с плагином (я так делаю). Ну или в Application Data\Download Master
Posted: 08 Jun 2006, 0:29 Thu
by Skaurus
А я xml рядом с плагином положил. Зачем далеко ходить
Но поиск компонента для работы с xml и обучение работе с ним стоило где-то двух-трех вечеров мытарств.
Я вот чего предлагаю. Добавить в АПИ функцию сохранения настроек плагина, с тремя параметрами - имя плагина (это можно и из myPluginName брать), имя опции, значение. Еще лучше 4 - имя плагина, имя опции, атрибут, значение - чтобы можно было получить структуру как у строки:
<Wrap enabled="yes" value="80"/>
Одна опция, с ней связано два атрибута - enabled и value, и 2 значения, соотв.
Вот. А куда эта функция АПИ будет писать настройки, это уж глубоко пофигу
Ну и симметричная функция получения этих значений.
Posted: 24 Dec 2008, 11:04 Wed
by 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;
А где и как хранить все эти данные, пусть ДМ соображает
Posted: 24 Dec 2008, 19:41 Wed
by Korney San
ZETZET wrote:Удобнее было бы добавить в интерфейс плагина пару методов, которые ДМ и будет вызывать для каждого плагина.
А если нужно считать/записать какой-то параметр "в середине" работы?
ПМСМ вызывать должен всё-таки плагин.
ZETZET wrote:А где и как хранить все эти данные, пусть ДМ соображает
Это точно. Хотя обычно ini возле плагина всё-таки лучше.
Posted: 24 Dec 2008, 21:35 Wed
by ZETZET
Code: Select all
А если нужно считать/записать какой-то параметр "в середине" работы?
- ну это редкий и частный случай, тобишь трабл самого плагина(можно добавить механизм оповещения ДМ об желании конкретного плагина пере\сохранить свои данные). А иначе в плагинах надо писать один и тот же в принципе код в плане сохранения данных. А ДМ может хранить данные в структурном файле (StgCreateDocFile(), StgOpenStorage()) в разных секциях... Ну в общем это моя имха, мне такой механизм сохранения кажется наиболее удобным.
пс. А что такое ПМСМ?
Posted: 24 Dec 2008, 23:16 Wed
by Korney San
ZETZET wrote:... А иначе в плагинах надо писать один и тот же в принципе код в плане сохранения данных. ...
А то ж! Из-за этой мудотени я разработал целую "универсальную систему настроек".
Теперь вместо задания горы переменных и тупого перечисления ReadString, ReadInteger и прочего я пишу десяток вызовов определения и один вызов сохранения.
ZETZET wrote:пс. А что такое ПМСМ?
IMHO = In My Humble Opinion = По Моему Скромному Мнению = ПМСМ
Таки мы русские