Far 3 & SettingsControl
Far 3 & SettingsControl
Может я чего-то не понимаю, но....
Вызов SettingsControl с командной SCTL_ENUM не выдает ни одной записи - хотя в базе они есть.
Вызов SettingsControl с командной SCTL_DELETE для удаления ветки (код брал из PluginSettings.hpp) ничего не удаляет, хотя возвращает TRUE.
Это еще не реализовано или я туплю? Есть где-нибудь живой пример?
Вызов SettingsControl с командной SCTL_ENUM не выдает ни одной записи - хотя в базе они есть.
Вызов SettingsControl с командной SCTL_DELETE для удаления ветки (код брал из PluginSettings.hpp) ничего не удаляет, хотя возвращает TRUE.
Это еще не реализовано или я туплю? Есть где-нибудь живой пример?
Re: Far 3 & SettingsControl
Слишком много кода будет - у меня свои обёртки
Примерно так:
По поводу SCTL_DELETE - оно работает если я создал раздел (через SCTL_CREATESUBKEY) и тут же удалил, но стоит перезапустить Фар - ничего не удаляется. Какой-нибудь стандартный плагин работает с подключами?
Примерно так:
Могу расписать полностью, но уже не сегодня Хотел DiskMenuEditor до нового года добить - споткнулся в настройках.SettingsControl(SCTL_CREATE) //< получил HANDLE
SettingsControl(HANDLE, 0 /*root*/, SCTL_ENUM) //< передал обнулённую структуру FarSettingsEnum, получил её же (всё 0)
По поводу SCTL_DELETE - оно работает если я создал раздел (через SCTL_CREATESUBKEY) и тут же удалил, но стоит перезапустить Фар - ничего не удаляется. Какой-нибудь стандартный плагин работает с подключами?
Re: Far 3 & SettingsControl
По идее старая ветка "group" должна удалиться, новая создаться - вместо этого они плодятся.
А вот так уже работает:
Code: Select all
void update_settings(const PluginStartupInfo* psi, const GUID* guid)
{
HANDLE handle = INVALID_HANDLE_VALUE;
FarSettingsCreate settings = { sizeof(FarSettingsCreate), *guid, handle };
assert(psi->SettingsControl(INVALID_HANDLE_VALUE, SCTL_CREATE, 0, &settings));
handle = settings.Handle;
FarSettingsValue sub = { 0, L"group" };
int group_id = psi->SettingsControl(handle, SCTL_OPENSUBKEY, 0, &sub);
FarSettingsValue val_del = { group_id, NULL };
assert(psi->SettingsControl(handle, SCTL_DELETE, 0, &val_del));
FarSettingsValue sub_new = { 0, L"group" };
assert(psi->SettingsControl(handle, SCTL_CREATESUBKEY, 0, &sub_new));
psi->SettingsControl(handle, SCTL_FREE, 0, NULL);
}
Code: Select all
void update_settings(const PluginStartupInfo* psi, const GUID* guid)
{
HANDLE handle = INVALID_HANDLE_VALUE;
FarSettingsCreate settings = { sizeof(FarSettingsCreate), *guid, handle };
assert(psi->SettingsControl(INVALID_HANDLE_VALUE, SCTL_CREATE, 0, &settings));
handle = settings.Handle;
FarSettingsValue sub = { 0, L"group" };
int group_id = psi->SettingsControl(handle, SCTL_OPENSUBKEY, 0, &sub);
FarSettingsValue val_del = { group_id, NULL };
assert(psi->SettingsControl(handle, SCTL_DELETE, 0, &val_del));
///////////////////////////////////////////////
//Переоткроем настройки
psi->SettingsControl(handle, SCTL_FREE, 0, NULL);
FarSettingsCreate settings2 = { sizeof(FarSettingsCreate), *guid, handle };
assert(psi->SettingsControl(INVALID_HANDLE_VALUE, SCTL_CREATE, 0, &settings2));
handle = settings2.Handle;
//////////////////////////////////////////////
FarSettingsValue sub_new = { 0, L"group" };
assert(psi->SettingsControl(handle, SCTL_CREATESUBKEY, 0, &sub_new));
psi->SettingsControl(handle, SCTL_FREE, 0, NULL);
}
- John Doe
- Бюрократ
- Posts: 13807
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 73 times
- Been thanked: 426 times
- Contact:
Far 3 & SettingsControl
Столкнулся с проблемой при работе нескольких экземпляров фара.
Если плагин в одном из экземпляров фара сделал SCTL_CREATE, то другие уже ничего записать в базу не могут, даже после того как первый сделает SCTL_FREE.
Причём SettingsControl отрабатывает как ни в чём не бывало, не возвращая ошибок.
Для воспроизведения важно чтобы второй экземпляр выполнил SCTL_CREATE до того, как первый сделает SCTL_FREE.
Если плагин в одном из экземпляров фара сделал SCTL_CREATE, то другие уже ничего записать в базу не могут, даже после того как первый сделает SCTL_FREE.
Причём SettingsControl отрабатывает как ни в чём не бывало, не возвращая ошибок.
Для воспроизведения важно чтобы второй экземпляр выполнил SCTL_CREATE до того, как первый сделает SCTL_FREE.
- John Doe
- Бюрократ
- Posts: 13807
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 73 times
- Been thanked: 426 times
- Contact:
Far 3 & SettingsControl
Всё то же самое можно воспроизвести в одном экземпляре.
Наблюдения:
Повторное (вложенное) создание настроек вызывает видимую задержку.
Похоже что в этом случае в памяти создаётся некая пустая база, не связанная с реальной.
После закрытия этих повторных настроек в реальную базу (db файл) ничего не пишется.
http://bugs.farmanager.com/view.php?id=2940
Code: Select all
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 файл) ничего не пишется.
http://bugs.farmanager.com/view.php?id=2940
- John Doe
- Бюрократ
- Posts: 13807
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 73 times
- Been thanked: 426 times
- Contact:
Far 3 & SettingsControl
Полагаю не ошибаетесь, но в данном случае этого не происходит: после
S2:Free()
я ведь для того и переоткрываю базу в третий раз, чтобы убедиться что ничего не записалось.- John Doe
- Бюрократ
- Posts: 13807
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 73 times
- Been thanked: 426 times
- Contact:
Far 3 & SettingsControl
И возвращаясь к проблемах SCTL_DELETE (именно с этого тема началась в 2011).
- В Энциклопедии сказано:
SCTL_DELETE Удалить подключ или значение.
В реальности подключ нельзя удалить просто указав его имя.
В changelog есть пояснение:
http://bugs.farmanager.com/view.php?id=2939 - В энциклопедии сказано: Функция при неудаче вернёт FALSE.
В реальности функция возвращает TRUE всегда, даже в случае если указанного элемента не существует.
В том числе, если попытаться удалить подключ по его имени: он конечно не удалится, но функция всё равно вернёт TRUE
http://bugs.farmanager.com/view.php?id=2938
- John Doe
- Бюрократ
- Posts: 13807
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 73 times
- Been thanked: 426 times
- Contact:
Far 3 & SettingsControl
Code: Select all
drkns 06.11.2018 20:35:22 +0000 - build 5304
1. Переделана работа с SQLite: теперь при неудаче вместо возврата false или кодов ошибок (которые мы почти нигде не проверяли)
бросаются исключения. Они пока что перехватываются при открытии db (из-за всего сопутствующего этому процессу шаманства)
и создании экземпляра настроек плагина (по понятным причинам), т.е. SCTL_CREATE, как и обещано, вернет FALSE в случае неудачи.
Это должно заодно починить 0002940: SCTL_CREATE: проблемы при создании более одного экземпляра настроек.
В остальном коде эти возможные исключения (пока) никак не обрабатываются, так что если у вас что пойдет не так - вы об этом узнаете.
SQLITE_BUSY обрабатывается отдельно - после 5-секундного таймаута будет возможность повторить либо прервать операцию.
Иными словами - изменения весьма экспериментальные, возможно всякое.
- John Doe
- Бюрократ
- Posts: 13807
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 73 times
- Been thanked: 426 times
- Contact:
Far 3 & SettingsControl
Code: Select all
Это должно заодно починить 0002940: SCTL_CREATE: проблемы при создании более одного экземпляра настроек.
Code: Select all
╔═════════════════════════════════ Error ══════════════════════════════════╗
║ C:\Apps\Far3\Profile\PluginsData\4EBBEFC8-2084-4B7F-94C0-692CE136894D.db ║
║ Database is busy ║
╟──────────────────────────────────────────────────────────────────────────╢
║ { Retry } [ Abort ] ║
╚══════════════════════════════════════════════════════════════════════════╝
В принципе, всё хорошо. Но предлагаю уменьшить таймаут.
- John Doe
- Бюрократ
- Posts: 13807
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 73 times
- Been thanked: 426 times
- Contact:
Far 3 & SettingsControl
Сказано:
Предлагаю возвращать ошибку (либо скорректировать документацию, если в пользу текущего поведения есть аргументы).
Update:
https://bugs.farmanager.com/view.php?id=3672
В реальности успешно открывается и несуществующий ключ.https://api.farmanager.com/ru/service_functions/settingscontrol.html#SCTL_OPENSUBKEY wrote:SCTL_OPENSUBKEY Открыть существующий ключ настроек.
Предлагаю возвращать ошибку (либо скорректировать документацию, если в пользу текущего поведения есть аргументы).
Update:
https://bugs.farmanager.com/view.php?id=3672
Last edited by John Doe on Fri 09 Nov, 2018 10:09, edited 1 time in total.
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Far 3 & SettingsControl
Этот диалог - busy handler, его основное предназначение - разрешение конфликтов при записи (из разных процессов).
В текущей имплементации этот хендлер ждёт 500 мс и пробует снова, и так 10 раз, потом сдаётся и показывает диалог.
С моей точки зрения такой таймаут вполне уместен при работе с файловой системой.
В реальных сценариях конкурентной записи, скорее всего, будет достаточно одного-двух повторов и задержка вряд ли будет более секунды.
Ваш случай - это исключение, повторы там ничего не дадут по определению.
Т.к. это заведомо неподдерживаемый сценарий, обречённый на неудачу, я не вижу проблемы в том, что автор этого сценария подождёт 5 секунд.