DrKnS wrote: ↑Wed 07 Nov, 2018 13:31
Т.к. это заведомо неподдерживаемый сценарий, обречённый на неудачу, я не вижу проблемы в том, что автор этого сценария подождёт 5 секунд.
Тут конечно, имел в виду другие сценарии: если двух повторов оказалось недостаточно, то уже есть основания заподозрить, что что-то не по назначению используется (даже если с третьей попытки и получилось бы).
На мой взгляд такое поведение только даёт лишнюю возможность допустить ошибку в названии подключа.
В добавок, оно неконсистентно: при работе с базами плагинов возвращается ошибка:
local Guid = win.Uuid"4EBBEFC8-2084-4B7F-94C0-692CE136894D"
local F = far.Flags
local settings = far.CreateSettings(Guid,F.PSL_ROAMING)
local subkey = settings:OpenSubkey(F.FSSF_ROOT,"abracadabra")
settings:Free()
far.Show(subkey)
Far 3 & SettingsControl
Posted: Wed 07 Nov, 2018 14:42
by DrKnS
В контексте настроек фара SCTL_OPENSUBKEY сам по себе не имеет смысла - это такой трюк для доступа к истории диалогов.
Надо бы отразить это в документации.
Far 3 & SettingsControl
Posted: Wed 07 Nov, 2018 14:57
by John Doe
DrKnS wrote: ↑Wed 07 Nov, 2018 14:42
В контексте настроек фара SCTL_OPENSUBKEY сам по себе не имеет смысла - это такой трюк для доступа к истории диалогов.
Надо бы отразить это в документации.
Есть такой тикет.
Но даже так, мне кажется приведённые выше аргументы всё равно уместны
Far 3 & SettingsControl
Posted: Wed 07 Nov, 2018 15:08
by DrKnS
Читайте в этом случае SCTL_OPENSUBKEY как SCTL_REGISTER_NEW_FARSETTINGS_SUBFOLDER и когнитивный диссонанс возникать не будет.
Far 3 & SettingsControl
Posted: Thu 08 Nov, 2018 09:03
by John Doe
DrKnS wrote: ↑Wed 07 Nov, 2018 15:08
Читайте в этом случае SCTL_OPENSUBKEY как SCTL_REGISTER_NEW_FARSETTINGS_SUBFOLDER и когнитивный диссонанс возникать не будет.
Пользователь будет читать то, что сказано в Энциклопедии.
Если напишите там "SCTL_REGISTER_NEW_FARSETTINGS_SUBFOLDER", значит это и прочитает.
В качестве документации пока что один changelog с примером, в котором в качестве корня для получения историй диалогов выступает 0.
Семь лет уже прошло с этого нововведения, не пора ли снять с него статус "экспериментального", и использовать выделенную константу с говорящим именем, вместо 0?
Far 3 & SettingsControl
Posted: Fri 09 Nov, 2018 12:38
by zg
John Doe wrote: ↑Fri 09 Nov, 2018 12:25Семь лет уже прошло с этого нововведения, не пора ли
в посте с таким тоном как минимум должна присутствовать ссылка на пулреквест. где она?
John Doe wrote: ↑Fri 09 Nov, 2018 12:25и использовать выделенную константу с говорящим именем, вместо 0?
так есть FSSF_ROOT.
Far 3 & SettingsControl
Posted: Fri 09 Nov, 2018 13:06
by John Doe
zg wrote: ↑Fri 09 Nov, 2018 12:38так есть FSSF_ROOT.
В коде сейчас просто 0, и использования FSSF_ROOT как раз хотелось бы избежать, чтобы не создавалось впечатление, будто истории диалогов "находятся" в корне настроек фара.
Для меня это выглядит несколько неестественно, и в тикете я предлагаю добавить отдельную константу FSSF_DIALOGS_HISTORY_ROOT (которая численно может оставаться и 0).
Far 3 & SettingsControl
Posted: Fri 09 Nov, 2018 13:47
by zg
John Doe wrote: ↑Fri 09 Nov, 2018 13:06В коде сейчас просто 0
John Doe wrote: ↑Fri 09 Nov, 2018 13:06и использования FSSF_ROOT как раз хотелось бы избежать, чтобы не создавалось впечатление, будто истории диалогов "находятся" в корне настроек фара.
John Doe wrote: ↑Fri 09 Nov, 2018 13:06и использования FSSF_ROOT как раз хотелось бы избежать, чтобы не создавалось впечатление, будто истории диалогов "находятся" в корне настроек фара.
что плохого в таком впечатлении?
Вы мне когда-то присылали пример чтения из истории. И в этом примере действительно неожиданным было (а)использование Settings и (б) имя константы FSSF_ROOT. Как-то понятия "история" и "settings" (установки, настройки) на интуитивном уровне не коррелируют. Посему поддерживаю введение отдельной константы для истории.
Far 3 & SettingsControl
Posted: Sat 15 Dec, 2018 15:22
by Shmuel
DrKnS wrote: ↑Wed 07 Nov, 2018 13:31
В текущей имплементации этот хендлер ждёт 500 мс и пробует снова, и так 10 раз, потом сдаётся и показывает диалог.
С моей точки зрения такой таймаут вполне уместен при работе с файловой системой.
Большая просьба уменьшить таймаут до нуля, то есть выдавать диалог запроса немедленно. Реакция человека не мгновенная, нажмёт Retry через секунду и, глядишь, всё в порядке.
После закрытия диалога можно войти в цикл: { таймаут 500 миллисекунд - диалог }.
Реально раздражает 5-секундное ожидание.
Если уменьшить таймаут до нуля, диалог будет показываться на каждый чих, особенно в ситуации "запускаем или завершаем несколько экземпляров почти одновременно".
Реакция человека не мгновенная, нажмёт Retry через секунду и, глядишь, всё в порядке.
Если возможно продолжить через секунду - код сам продолжит через секунду без всяких нажатий. Реакция человека не мгновенная, эту секунду он может и не заметить, а вот непонятный страшный красный диалог заметит точно.
Реально раздражает 5-секундное ожидание
Чтобы что-то реально раздражало, это что-то должно 1) происходить многократно; 2) быть неизбежным.
Если вашему сценарию не помогает аж 5-секундный таймаут, то, как мы уже обсудили на предыдущей странице, ему уже, скорее всего, никакой Retry не поможет, т.к. это баг.
Можно узнать, зачем вы держите у себя код, который не работает? Возможно, стоит просто избавиться от него? Не будет ни ожиданий, ни диалогов.
Far 3 & SettingsControl
Posted: Sat 15 Dec, 2018 18:35
by Shmuel
DrKnS wrote: ↑Sat 15 Dec, 2018 18:14
Можно узнать, зачем вы держите у себя код, который не работает?
А что неправильного делает этот код, который не работает?
Far 3 & SettingsControl
Posted: Sat 15 Dec, 2018 18:51
by DrKnS
Shmuel wrote: ↑Sat 15 Dec, 2018 18:35А что неправильного делает этот код, который не работает?
Вы его не показываете, поэтому сложно что-то утверждать.
Исходя из схожести симптомов со случаем, описанным ранее John Doe - возможно, пытается открыть уже эксклюзивно кем-то (в т.ч. собой) открытую базу. Или я не прав и всё совсем иначе?