Summary: | 1Cv77: Не реагирует на ESC (Escape) при выполнении отчёта | ||
---|---|---|---|
Product: | WINE@Etersoft | Reporter: | Vitaly Lipatov <lav> |
Component: | Окна / фокус / перерисовка | Assignee: | Илья Шпигорь <shpigor> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | minor | ||
Priority: | P5 | CC: | aae, aka_down, baraka, kondratyuk, sergling, shpigor, vostok |
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: | |||
Заявки RT: | Связано с: | ||
Дата напоминания: | |||
Bug Depends on: | 3114 | ||
Bug Blocks: | 760, 2401, 3305, 3589 |
Description
Vitaly Lipatov
2006-11-19 18:16:30 MSK
В Windows работает. Не устанавливается какой-то перехватчик? При выполнении отчёта Отчеты->Стандартные бухгалтерски->Отчёт по проводкам (формируется долго),если в текущей версии нажать на Esc, то вылетит стандартный MessageBox (работает правильно) и при ответе на вопрос о остановке, соответсвенно останавливает выполнение. *** Bug 830 has been marked as a duplicate of this bug. *** Возможно есть какая-то зависимость, почему у одних останавливается, а у других - нет? возможно есть зависимость, простой алгоритм тест.ert Пока 1=1 Цикл КонецЦикла; Если потерять фокус приложения, к примеру перейти на открытый рядом в wine 1с:Конфигуратор, то вернуть фокус назад уже не получается, соответственно esc просто не доходит до нужного приложения. В 1.0.8 все та же ситуация: если переключить фокус на другое приложение, а потом вернуться в 1С, esc перестает работать, а поскольку пользователи постоянно переключаются при длительных отчетах на другие приложения, невозможность остановить обработку отчета довольно неприятна. Да. Действительно проблема имеет место быть. Предпосылка - 1с использует один поток, т.е. и интерфейс реализуется и вычисления производятся в одном потоке. Способ воспроизведения - во время выполнения отчёта нажать esc (появится запрос об отмене) -> нажать "отмена" (фокус уже ушёл), и, естественно второй раз отмена не нажать. Главное один раз потерять фокус и уже пока не выполнится отчёт фокус в главное окно не вернётся и отменить действие не возможно. То есть проблема в том, что фокус больше не возвращается в то подокно, которое реагирует на нажатие Esc? Фокус, с виду, возвращается в то же самое подокно из которого вызвана обработка (wine@etersoft 1.0.8 от 15.12.07). Если запустить бесконечный цикл из модального окна можно заметить различия поведения wine и windows: Вызваем бесконечный цикл из модального окна в wine - модальное подокно активно и может быть перемещено мышкой (1С на esc второй раз после отмены или после потери фокуса не реагирует), в Windows это подокно перемещать невозможно (1С на esc реагирует всегда). То что под Linux модальные окна можно перемещать в таких условиях - это фишка оконных менеджеров (т.к. под KDE понятие "модальное окно" отсутствует напрочь, то там возможен даже такой эффект: Создаём два модальных окна и можем между ними переключаться, по идеалогии Windows такое поведение не возможно). Нашел способ заставить 1С увидить ESC После потери фокуса, когда ESC уже не нажимается, нужно зажать ESC и не отпуская клавишу, мышью активизировать 1С в панели задач. Работает в Ubuntu 7.04 (XFCE-4) wine@etersoft.sql 1.0.8 Актуально? Актуально. В 1.0.9 поведение 1С при нажатии ESC не изменилось. Не получилось воспроизвести на текущей сборке. Проверял в бутылке 1c77/1c7727. Приложение 1С корректно получает фокус и Esc отрабатывает. (In reply to comment #15) > Не получилось воспроизвести на текущей > сборке. > > Проверял в бутылке 1c77/1c7727. Приложение 1С > корректно получает фокус и Esc отрабатывает. > Подтверждаю, на сборке eter41\16 ошибка не воспроизвелась. Подтверждаю, на 1.0.9-40/17 Ubuntu 7.04, 8.04 Gnome, Xfce4 не воспроизводится. В 1.0.10.19/13 ошибка с ESC опять возникла (ubuntu 7.04, Xfce4). На этот раз ESC даже в первый раз не срабатывает. Как и раньше, помогает переключение на другое приложение и активация 1С в панели задач с зажатым ESC, при работе в рутлес-режиме NXClient`а прервать отчет вообще никак невозможно. Да, ошибка вернулась, переоткрываю. Появилась из-за патча на #3114. Выложил группу патчей. Это немного другое решение баги #3114. В качестве критерия остановки извлечения сообщений WM_SYSKEYDOWN из очереди сообщеий используется разность текущего времени и времени создания последнего не popup окна. В этом случае сама бага #3114 корректно решается, т.к. очередь блокируется - разность времени меньше установленного интервала. Бага #3827 решается, т.к. текущее время назначается только для popup окна, иначе время создания последнего окна не изменяется (разность времени заведомо больше установленного интервала - очередь не блокируется). Бага #396 решается,т.к. в момент нажатия кнопки формирования отчета - последнее окно создалось достаточно давно. Принято. eter21 |