Кто ж знает как оно может проявиться в других.
Наверно стоит тоже на мантис.
С точки зрения "правил игры", т.е. документации, вроде ничего не нарушено - я не помню, чтобы она гарантировала невызов экспортируемых функций плагина Фаром во время вызова SetStartupInfoW. Я в LuaFAR-плагинах основывался на "невызове", и до 3968 неприятностей с этим не было. Сейчас сделал "защиту", но, возможно, это то, что должно было быть с самого начала. Так что репортить вроде как нечего, т.к. с точки зрения документации ничего не нарушено.
SetStartupInfoW вызывается синхронно. т.е. если не вызывать фарапи внутри SetStartupInfoW, то никакой другой экспорт не дёрнется. если вызывать, то может дёрнуться. так что нужно смотреть, что конкретно вызывается и тогда уже решать, баг это или нет.
вообще, количество хаков на квадратный символ в manager.cpp превышает все мыслимые нормы, поэтому я сейчас переписываю оконный менеджер. ввиду сильной завязанности фара в целом на внутренности старого менеджера, происходит это не так быстро, как хотелось бы, но надежда пока есть. так что если это всё не критично, лучше подождать.
zg wrote:SetStartupInfoW вызывается синхронно. т.е. если не вызывать фарапи внутри SetStartupInfoW, то никакой другой экспорт не дёрнется. если вызывать, то может дёрнуться. так что нужно смотреть, что конкретно вызывается и тогда уже решать, баг это или нет.
Там вызывается Message, а Фар вызывает ProcessEditorEventW.
╔═════════════════════════ Error ═════════════════════════╗
║ Failed to set value "true" for parameter "SavePosition" ║
╟─────────────────────────────────────────────────────────╢
║ { OK } ║
╚═════════════════════════════════════════════════════════╝
Но что насчёт ошибки о которой говорится в диалоге lf4ed?
Подозреваю ситуацию когда вьювер оказывается закрыт тоже надо учесть?
Или это надо сделать не в плагине, а в пакете context?
John Doe wrote:Но что насчёт ошибки о которой говорится в диалоге lf4ed?
Подозреваю ситуацию когда вьювер оказывается закрыт тоже надо учесть?
Или это надо сделать не в плагине, а в пакете context?
Ошибку выдаёт context, значит там и надо начинать разбираться. А падение происходит и без context'а. Разбираться имеет смысл после починки падения.
В VE_READ lf4ed выдаёт на экран предупреждение о неверном шорткате, и получает управление обратно только после закрытия сообщения.
А за это время другой плагин успевает закрыть вьювер, но lf4ed не в курсе (не обработал VE_CLOSE?) поэтому продолжает как ни в чём ни бывало, и все дальнейщие функции работающие со вьювером возвращают nil.
В результате возникает ошибка, которую и отображает lf4ed. Вот тут стоит разобраться, как не попасть в такую ситуацию.
А то, что после закрытия сообщения фар падает, это другой вопрос, и с предыдущим не связан.
Эта версия абсолютно не соответствует тому, что происходит на самом деле.
P.S. Но вызов плагином в цикле обработчиков событий пакетов действительно не учитывает того, что вьювер или редактор могут быть в процессе закрыты (даже одним из тех же обработчиков). Это надо будет исправить в плагине.
╔═════════════════════════ Error [used: 516 KB] ══════════════════════════╗
║ ►[J1]:...ile\Plugins\lf4ed\scripts\context\scripts\detectType.lua:361: ║
║ attempt to index a nil value ║
║ stack traceback: ║
║ ►[J2]:...ile\Plugins\lf4ed\scripts\context\scripts\detectType.lua:361: ║
║ in function 'detViewerType' ║
║ ►[J3]:...ile\Plugins\lf4ed\scripts\context\scripts\handleType.lua:147: ║
║ in function '__index' ║
║ ►[J4]:...ile\Plugins\lf4ed\scripts\context\scripts\handleType.lua:171: ║
║ in function 'reloadViewerConfig' ║
║ ►[J5]:...ile\Plugins\lf4ed\scripts\context\scripts\handleType.lua:245: ║
║ in function 'viewerEvent' ║
║ ►[J6]:...\Far3\Profile\Plugins\lf4ed\scripts\context\resident.lua:40: ║
║ in function 'f' ║
║ [?]:[string "<boot"]:334: in function <[string "<boot"]:332> ║
╟─────────────────────────────────────────────────────────────────────────╢
║ { OK } [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] ║
╚═════════════════════════════════════════════════════════════════════════╝
После закрытия фар падает.
1. Какая версия LuaFAR context? В версии на GitHub в detectType.lua 361-я строка пустая.
2. В LuaFAR context считается, что первым приходит событие EE_READ/VE_READ, а для других задействованных событий считается, что приходит корректный id редактора/просмотрщика (см. handleType.lua, обработчики editorEvent и viewerEvent).