Может я чего-то не понимаю, но....
Вызов SettingsControl с командной SCTL_ENUM не выдает ни одной записи - хотя в базе они есть.
Вызов SettingsControl с командной SCTL_DELETE для удаления ветки (код брал из PluginSettings.hpp) ничего не удаляет, хотя возвращает TRUE.
Это еще не реализовано или я туплю? Есть где-нибудь живой пример?
Re: Far 3 & SettingsControl
Posted: Wed 28 Dec, 2011 15:50
by t-rex
Приведи полный код.
Re: Far 3 & SettingsControl
Posted: Wed 28 Dec, 2011 16:02
by artemsen
Слишком много кода будет - у меня свои обёртки
Примерно так:
SettingsControl(SCTL_CREATE) //< получил HANDLE
SettingsControl(HANDLE, 0 /*root*/, SCTL_ENUM) //< передал обнулённую структуру FarSettingsEnum, получил её же (всё 0)
Могу расписать полностью, но уже не сегодня Хотел DiskMenuEditor до нового года добить - споткнулся в настройках.
По поводу SCTL_DELETE - оно работает если я создал раздел (через SCTL_CREATESUBKEY) и тут же удалил, но стоит перезапустить Фар - ничего не удаляется. Какой-нибудь стандартный плагин работает с подключами?
Re: Far 3 & SettingsControl
Posted: Wed 28 Dec, 2011 17:26
by t-rex
пока не покажешь весь свой код, говорить не о чём.
Re: Far 3 & SettingsControl
Posted: Thu 29 Dec, 2011 08:00
by artemsen
По идее старая ветка "group" должна удалиться, новая создаться - вместо этого они плодятся.
Столкнулся с проблемой при работе нескольких экземпляров фара.
Если плагин в одном из экземпляров фара сделал SCTL_CREATE, то другие уже ничего записать в базу не могут, даже после того как первый сделает SCTL_FREE.
Причём SettingsControl отрабатывает как ни в чём не бывало, не возвращая ошибок.
Для воспроизведения важно чтобы второй экземпляр выполнил SCTL_CREATE до того, как первый сделает SCTL_FREE.
Far 3 & SettingsControl
Posted: Thu 12 Feb, 2015 20:47
by John Doe
Всё то же самое можно воспроизвести в одном экземпляре.
local F = far.Flags
local Guid = win.Uuid"4EBBEFC8-2084-4B7F-94C0-692CE136894D"
far.FreeSettings()
local S1 = far.CreateSettings(Guid,F.PSL_ROAMING)
local S2 = far.CreateSettings(Guid,F.PSL_ROAMING)
--S1:Set(F.FSSF_ROOT, "test1", F.FST_STRING, "aaa")
S1:Free()
local Value1 = S2:Get(F.FSSF_ROOT, "test1", F.FST_STRING)
S2:Set(F.FSSF_ROOT, "test1", F.FST_STRING, "bbb")
local Value2 = S2:Get(F.FSSF_ROOT, "test1", F.FST_STRING)
S2:Free()
local S3 = far.CreateSettings(Guid,F.PSL_ROAMING)
local Value3 = S3:Get(F.FSSF_ROOT, "test1", F.FST_STRING)
S3:Free()
far.Show(Value1,Value2,Value3)
Наблюдения:
Повторное (вложенное) создание настроек вызывает видимую задержку.
Похоже что в этом случае в памяти создаётся некая пустая база, не связанная с реальной.
После закрытия этих повторных настроек в реальную базу (db файл) ничего не пишется.
Могу ошибаться, но вроде бы реальная запись в базу происходит только при вызове SCTL_FREE.
Far 3 & SettingsControl
Posted: Thu 12 Feb, 2015 21:08
by John Doe
Полагаю не ошибаетесь, но в данном случае этого не происходит: после S2:Free() я ведь для того и переоткрываю базу в третий раз, чтобы убедиться что ничего не записалось.
Far 3 & SettingsControl
Posted: Thu 12 Feb, 2015 23:05
by John Doe
И возвращаясь к проблемах SCTL_DELETE (именно с этого тема началась в 2011).
В Энциклопедии сказано: SCTL_DELETE Удалить подключ или значение.
В реальности подключ нельзя удалить просто указав его имя.
В changelog есть пояснение:
t-rex 26.04.2011 00:40:52 +0200 - build 1997
1. Небольшое изменения в API настроек плагинов.
Для SCTL_DELETE если FarSettingsValue.Value==NULL то удаляется ключ FarSettingsValue.Root.
В обратном случае удалется только Value (даже если есть ключ с таким именем).
В энциклопедии сказано: Функция при неудаче вернёт FALSE.
В реальности функция возвращает TRUE всегда, даже в случае если указанного элемента не существует.
В том числе, если попытаться удалить подключ по его имени: он конечно не удалится, но функция всё равно вернёт TRUE http://bugs.farmanager.com/view.php?id=2938
drkns 06.11.2018 20:35:22 +0000 - build 5304
1. Переделана работа с SQLite: теперь при неудаче вместо возврата false или кодов ошибок (которые мы почти нигде не проверяли)
бросаются исключения. Они пока что перехватываются при открытии db (из-за всего сопутствующего этому процессу шаманства)
и создании экземпляра настроек плагина (по понятным причинам), т.е. SCTL_CREATE, как и обещано, вернет FALSE в случае неудачи.
Это должно заодно починить 0002940: SCTL_CREATE: проблемы при создании более одного экземпляра настроек.
В остальном коде эти возможные исключения (пока) никак не обрабатываются, так что если у вас что пойдет не так - вы об этом узнаете.
SQLITE_BUSY обрабатывается отдельно - после 5-секундного таймаута будет возможность повторить либо прервать операцию.
Иными словами - изменения весьма экспериментальные, возможно всякое.
local F = far.Flags
local settings = far.CreateSettings("far")
local history = settings:OpenSubkey(F.FSSF_ROOT,"SearchText1")
local items = settings:Enum(history,-1)
settings:Free()
far.Show(history,items.Count)
John Doe wrote: ↑Wed 07 Nov, 2018 10:11предлагаю уменьшить таймаут
Этот диалог - busy handler, его основное предназначение - разрешение конфликтов при записи (из разных процессов).
В текущей имплементации этот хендлер ждёт 500 мс и пробует снова, и так 10 раз, потом сдаётся и показывает диалог.
С моей точки зрения такой таймаут вполне уместен при работе с файловой системой.
В реальных сценариях конкурентной записи, скорее всего, будет достаточно одного-двух повторов и задержка вряд ли будет более секунды.
Ваш случай - это исключение, повторы там ничего не дадут по определению.
Т.к. это заведомо неподдерживаемый сценарий, обречённый на неудачу, я не вижу проблемы в том, что автор этого сценария подождёт 5 секунд.
Far 3 & SettingsControl
Posted: Wed 07 Nov, 2018 13:44
by zg
John Doe wrote: ↑Wed 07 Nov, 2018 11:25если в пользу текущего поведения есть аргументы.