View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003703 | Far Manager | General | public | 2019-03-15 11:53 | 2021-06-26 15:49 |
Reporter | JohnDoe | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Platform | x86 | OS | Windows | OS Version | XP SP3 |
Product Version | 3.0 | ||||
Fixed in Version | 3.0 | ||||
Summary | 0003703: Colorer: невидимый диалог при ошибке создания лога | ||||
Description | Если при открытии редактора вместе с ворнингом FarColorer выводится и какое-либо сообщение (другим плагином), то наблюдается странное поведение: ворнинг может стать невидимым (вероятно затирается перерисовкой редактора или RestoreScreen). | ||||
Steps To Reproduce | 1. Создать макрос, выводящий сообщение при открытии редактора.
2. В настройках Colorer задать путь лога в несуществующей папке 3. Перезапустить фар Far.exe /p%FARHOME%\Plugins\ 4. Открыть редактор:
Поверх этого сообщения будет также выведенное макросом:
5. После нажатия Enter - Message закрывается, а диалог FarColorer "пропадает" с экрана, но не закрывается (а курсорными клавишами можно проявить { OK } в невидимом диалоге). 6. Ещё один Enter закрывает диалог, при этом можно наблюдать на экране странную последовательность проявления разных окон, позволяющую заподозрить эффекты Save/RestoreScreen. | ||||
Tags | No tags attached. | ||||
Build | 5583 | ||||
|
Это не ошибка Colorer. вероятно ошибка Lua. колорер не делает Save/RestoreScreen при данных вызовах. скорее Lua это делает, и т.к. его окно выше, при нажатии enter обрабатывает нажатие и восстанавливает старый экран |
|
Lua совершенно точно ничего такого не делает. И проблема вопроизводится только с Колорер. > колорер не делает Save/RestoreScreen при данных вызовах. Я и не предполагал, что он делает это при ЭТИХ вызовах. Такое поведение типично при выводе прогресса с помощью Message (без кнопок). При этом плагин должен самостоятельно обновить экран, и именно эта функцию я подозреваю в некорректном использовании RestoreScreen. https://github.com/colorer/FarColorer/search?q=restorescreen&unscoped_q=restorescreen Рекомендуемое исправление: вместо восстанавления сохранённого экрана - обновлять. |
|
я не помню как было на текущей версии плагина, сколько там Save/RestoreScreen. проверяю на новой , и тут такая же ошибка. и Save/RestoreScreen используется только в одном месте - в диалоге настроек. (остальные удалены по заветам отцов) что получаем. 1. происходит ошибка открытия файла. 2. на это событие вызывается Info.Message(&MainGuid, &ErrorMessage, FMSG_WARNING, L"exception", &exceptionMessage[0], std::size(exceptionMessage), 1); 3. в это время управление возвращается к фару, который в начале рисует мой message, а потом обрабатывает другие собывтия - в частности от макроса рисует поверх моего своё сообщение. 4. и тут мы ждем реакцию пользователя. как только он нажимает ок на диалоге из макроса , происходит зачистка экрана. а функция из пункта 2 еще не вернула управление, ждет ответа. 5. и только после попвток нажать ok на невидимом окне управление возвращается и плагин работает дальше вывод - пока не вижу ошибки колорера |
|
Внутреннюю логику понять иногда сложно, я вот просто вижу в файле 5 вызовов Restore. Проще всего проверить тупо закомментировав их... |
|
не понял последнюю фразу. сделать сборку плагина где нет этих вызовов для теста ? в ближайшие дни, а может сегодня, выйдет новая версия плагина, там не будет этих вызовов. |
|
реализовано в 1.3.0 - убраны все save/Restore . но эффект сохраняется, поскольку дело в lua |
|
В 1.3.1 при указании несуществующей папки для лога - не выдаётся никаких ошибок. |
|
потому как логер создает эту папку. но если указать, например, не существующий диск, где создание не возможно - будет ошибка |
|
> потому как логер создает эту папку У меня похоже лог вообще не создаётся при детализации INFO |
|
То, что окошко LuaMacro выводится поверх окошка колорера, мне не очень понятно. Event это не макрос, который может что-то вывести поверх. При выводе первого модального диалога на экран, полагаю, что Фар не вызывает редакторные события других плагинов вплоть до закрытия этого диалога. |
|
Сейчас сделал опыт: в двух плагинах (LuaMacro и LF4Editor) поставил вывод Message по событию EE_READ. Результат: второй диалог выводится только после закрытия первого. |
|
Воспроизвёл: |
|
5583. > При выводе первого модального диалога на экран, полагаю, что Фар не вызывает редакторные события других плагинов вплоть до закрытия этого диалога. вызывает. |
|
> вызывает. Может в 5583 и вызывает (может он там и кино показывает), а в 5580 - не вызывает. |
|
> Может в 5583 и вызывает (может он там и кино показывает), а в 5580 - не вызывает. а что так грубо? я вам что-то плохое сделал? я не знаю, что вы имеете ввиду под редакторными событиями других плагинов, но вот простой макрос + airbrush: MenuItem { description='test'; menu='Plugins'; area='Dialog'; guid='CCFF5933-05E0-44F3-A148-6CB44E62F0AD'; text='test'; action = function(OpenFrom,Item) Plugin.SyncCall('9860393A-918D-450F-A3EA-84186F21B0A2',0,-1,'208B30EE-E89E-4050-BADF-299B80D02FFE') end; } если вызвать его из диалога поиска, то раскраска сменится, т.е. ee_redraw в airbrush пришёл, при этом диалог поиска всё так же на экране. |
|
@zg, написал я вам длинный ответ но движок его не принял, сказал нажать back у браузера, после чего ответ исчез. Повторять его времени нет, но насчёт грубости вы не правы, намерения вас как-либо обидеть не было и нет. |
|
> я не знаю, что вы имеете ввиду под редакторными событиями других плагинов Вероятно только то, что EE_READ обрабатывается синхронно: управление следующему обработчику передаётся после получения управления от предыдущего. |
|
> Вероятно только то, что EE_READ обрабатывается синхронно: управление следующему обработчику передаётся после получения управления от предыдущего. да. но в исходном сообщение говорилось о событиях в общем, а в общем есть ee_redraw и он может быть вложенным и т.д. и фраза про модальный диалог сбивает с толку, потому что показ модального диалога в ee_read не влияет на порядок исполнения обработчиков ee_read никак. |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-03-15 11:53 | JohnDoe | New Issue | |
2019-03-16 07:20 | JohnDoe | Steps to Reproduce Updated | |
2020-04-01 19:46 | sonar | Note Added: 0016766 | |
2020-04-03 14:38 | JohnDoe | Note Added: 0016772 | |
2020-04-03 14:40 | JohnDoe | Note Edited: 0016772 | |
2020-04-03 14:44 | JohnDoe | Note Edited: 0016772 | |
2020-04-03 15:38 | sonar | Note Added: 0016773 | |
2020-04-03 15:39 | sonar | Note Edited: 0016773 | |
2020-04-03 15:40 | sonar | Note Edited: 0016773 | |
2020-04-03 21:20 | JohnDoe | Note Added: 0016774 | |
2020-04-04 14:57 | sonar | Note Added: 0016775 | |
2020-04-10 05:52 | sonar | Note Added: 0016782 | |
2020-04-12 09:26 | JohnDoe | Note Added: 0016788 | |
2020-04-12 09:39 | sonar | Note Added: 0016789 | |
2020-04-12 10:18 | JohnDoe | Note Added: 0016790 | |
2020-04-12 10:20 | JohnDoe | Note Edited: 0016790 | |
2020-04-12 11:15 | shmuel | Note Added: 0016791 | |
2020-04-12 11:42 | shmuel | Note Added: 0016792 | |
2020-04-12 12:26 | JohnDoe | Note Added: 0016793 | |
2020-04-12 12:28 | zg | Note Added: 0016794 | |
2020-04-12 12:31 | shmuel | Note Added: 0016795 | |
2020-04-12 13:29 | zg | Note Added: 0016796 | |
2020-04-12 14:12 | shmuel | Note Added: 0016797 | |
2020-04-12 14:47 | JohnDoe | Note Added: 0016798 | |
2020-04-12 17:40 | zg | Note Added: 0016800 | |
2020-04-13 09:29 | JohnDoe | Project | Plugins => Far Manager |
2020-04-13 09:29 | JohnDoe | Category | Colorer => General |
2020-04-13 09:31 | JohnDoe | Status | new => resolved |
2021-06-26 15:49 | JohnDoe | Status | resolved => closed |
2021-06-26 15:49 | JohnDoe | Resolution | open => fixed |
2021-06-26 15:49 | JohnDoe | Fixed in Version | => 3.0 |
2021-06-26 15:49 | JohnDoe | Build | => 5583 |