Bug 3114

Summary: Сброс буфера клавиатуры при работе в 1С 7.7
Product: WINE@Etersoft Reporter: Николай <sunnet>
Component: Стандартные диалогиAssignee: Константин Кондратюк <kondratyuk>
Status: CLOSED FIXED QA Contact:
Severity: major    
Priority: P4 CC: baraka, kondratyuk, lav, night, prof.alex1975, sunnet, vitperov, vostok
Version: 1.0.9   
Target Milestone: ---   
Hardware: PC   
OS: ALT Linux   
Whiteboard:
Заявки RT: Связано с:
Дата напоминания:
Bug Depends on: 5157    
Bug Blocks: 42, 396, 760, 3827, 5101, 7635    

Description Николай 2008-12-12 14:35:29 MSK
Во время набивания накладной, например, когда вводишь новую строку в табличную часть, то справочник товаров (было порядка 28 000 позиций, урезал до ~9000 позиций - изменений, имхо, нет) появляется с ооооочень коротким, но притормаживанием. Т.е. оператор нажимает ins и сразу (пауза - время, необходимое для переноса пальца с ins на другую клавишу фактически) начинает набирать код, а первая буква проглатывается, т.к. справочник еще не открылся.
Задержка достаточно короткая (бувально вот на ввод одной буквы), но имеется. Даже локально.
Под виндой такой проблемы нет.

На данный момент имеем:
сервер: обычный писюк на AMD athlon x2-3600/1 Gb RAM.
ОСь: ALT linux desktop personal 4.1
wine@etersoft network 1.0.9 от 27.11
1С: 1с 7.7.21, база - dbf

В целом - весьма критично. Пока думаю предложить вместо того, чтобы вводить код сразу - давить пару раз стрелку вниз/вверх. Но это не серьезно... :(
Comment 1 Николай 2008-12-12 15:02:03 MSK
ЗЫ Используется KDE. Другие DE еще не пробовал.
Comment 2 Николай 2009-01-04 12:57:13 MSK
Хочу поменять описание ошибки.
Как я понимаю, проблем в том, что под виндой при вызове справочника товаров(например) буфер клавиатуры не сбрасывается, т.е. появляется окно справочника и все нажатые до этого клавиши обрабатываются. Под линуксом клавиши начинают обрабатываться только с момента появления окна со справочником товаров.

PS Сейчас в качестве терминального сервера под линуксом используется Core2QUAD 9400/2048 Gb. Проблема наблюдается и в терминальном режиме, и в локальном. Пробовал за это время: KDE3.5, GNOME, E17, KDE4.1.3 xfce, blacbox. Кажись ни в чем не ошибся;).
Преимущественно использую KDE 3.5 и KDE 4.1.3.
Comment 3 Илья Шпигорь 2009-01-05 15:12:22 MSK
Думаю, что проблему можно решить если ускорить процесс создания окон.

Задержки, которые сейчас наблюдаются, связаны с более долгой отрисовкой иконок в wine по сравнению с windows. Это видно по мигающему заголовку окон.
Comment 4 Илья Шпигорь 2009-01-05 15:15:03 MSK
Скорее всего, проблема не столько в буфере клавиатуры, сколько в посылке сооющения WM_KEYDOWN еще не созданному окну.
Comment 5 Николай 2009-01-05 19:34:28 MSK
(In reply to comment #4)
> Скорее всего, проблема не столько в буфере
> клавиатуры, сколько в посылке сооющения
> WM_KEYDOWN еще не созданному окну.
Понятно.
А как-то можно это обойти, вставив некоторую паузу (например, что-то около 1/10 секунды)? Чтобы в итоге клавиши обрабатывались в уже появившемся окне.

Еще момент: такая проблема наблюдается не только при появлении окна, но и при начале редактирования строки в табличной части документа, например. Т.е. я думал временно обойти, используя поле типа не "Справочник.Товары", а "Строка". В итоге проблема аналогична: при нажатии ins - клавиши, нажатые до появления новой строки (и начала ее редактирования?) также пропадают.

ЗЫ Спасибо за оперативность. Буду ждать решение. Пока это основная проблема. Странно, что ее раньше не было (если я не пропустил).
Comment 6 Vitaly Lipatov 2009-01-05 23:02:07 MSK
Проблема, думаю, была всегда.
Постараемся решить её. Одной из идей было переключать фокус ввода до начала перерисовки окна.
В крайнем случае можно не вынимать сообщения от клавиатуры до окончания перерисовки.
Comment 7 Николай 2009-01-06 02:14:41 MSK
(In reply to comment #6)
> Проблема, думаю, была всегда.
Виноват. Не так выразился - не было (не нашел) в багах.
Comment 8 Илья Шпигорь 2009-01-11 18:02:27 MSK
Выложил два патча.

Первый откатывает патч на отступ в меню для 1с7. Эта проблема должна решиться, если иконки будут отрисовываться быстрее.

Второй - хак, запрещающий масштабировать иконки для 1с7.

Дело в том, что 1с сначала масштабирует иконки 16x16 в 32x32, а потом перед каждой отрисовкой обратно из 32x32 в 16x16. Операция масштабирования долгая, поэтому и вывод иконок так тормозит. Собственно, из-за этих иконок тормозит и создание окна, поскольку пока Non Client область не обновится, CreateWindow управленияне вернет.

У этого решения возможны негативные последствия, но если это будут незначительные визуальные недачеты, думаю, ускорение 1с того стоит.
Comment 9 Николай 2009-01-12 02:31:46 MSK
(In reply to comment #8)
> Выложил два патча.
> 
> Первый откатывает патч на отступ в меню для
> 1с7. Эта проблема должна решиться, если
> иконки будут отрисовываться быстрее.
> 
> Второй - хак, запрещающий масштабировать
> иконки для 1с7.
Несколько вопросов:
1. Как их скачать? Не нашел. Или это для внутреннего использования?
1а. Проблема в открытой части wine@etersoft? Т.е. можно ли компилировать самому?
2. Когда можно будет погонять вариант с патчем?
3. А по "буферу клавиатуры" ( http://bugs.etersoft.ru/show_bug.cgi?id=3114#c6 ) пока еще никаких сдвигов?

Спасибо.
Comment 10 Илья Шпигорь 2009-01-12 14:04:53 MSK
(In reply to comment #9)

> 1. Как их скачать? Не нашел. Или это для
> внутреннего использования?
> 1а. Проблема в открытой части wine@etersoft? Т.е.
> можно ли компилировать самому?
> 2. Когда можно будет погонять вариант с
> патчем?

Вам надо подождать выхода версии 1.0.10 или обновления для 1.0.9, если оно будет.

> 3. А по "буферу клавиатуры" (
> http://bugs.etersoft.ru/show_bug.cgi?id=3114#c6 ) пока еще
> никаких сдвигов?

Нет. Вероятнее всего, проблему удастся решить этими патчами.
Comment 11 Илья Шпигорь 2009-01-15 16:31:29 MSK
Изменил на Fixed. 

Если проблема должным образом не решится текущим патчем, надо переоткрыть.
Comment 12 Andrey Vusik 2009-01-30 16:45:48 MSK
Сборка 40/17
Заявленной проблемы нет
Comment 13 Николай 2009-03-07 02:12:20 MSK
Извиняюсь за задержку (почти месяц был в командировке, потом решал накопившуюся текучку).
Все-таки проблема до конца не решена (1.0.9 41/17, локальная версия, т.к. на сетевую закончилось время тестирования). Отображение стало быстрее, но не достаточно. Возможно это связано с размером справочника товаров - у нас порядка 12 000 - 13 000 позиций сейчас. Ведь время уходит не только на отображение, но и на чтение базы.
Думаю, что все-таки нужно копать в сторону буфера клавиатуры.

PS Лично мне это и не заметно, но фактуровщик у нас с этим сталкивается. :(
Comment 14 Илья Шпигорь 2009-03-31 10:17:12 MSD
Выложил патч.

На самом деле, как выяснилось, буфера клавиатуры в wine нет. Все сообщения WM_KEYDOWN попадают в очередь сообщений, из которой потом извлекаются и обрабатываются через hook'и.

В данном случае проблема была в том, что пока создается новое окно фокус теряется, т.е. новое окно его еще не получило, а предыдущее уже потеряло. Из-за этого вместо WM_KEYDOWN сообщений генерировались WM_SYSKEYDOWN. Дальше для их обработки вызывался hook и их обрабатывало активное окно, т.е. предыдущее.

Решение заключается в добавления буфера, в который заносятся все клавиши нажатые, пока нет окна с фокусом. Дело в том, что эти сообщения в любом случае должны быть извлечены из очереди сообщений, иначе программа не сможет работать дальше. После этого как только приходит сообщение WM_TIMER - этот буфер извлекается в окно, имеющее фокус.
Comment 15 Анатолий Лютин 2009-03-31 11:57:53 MSD
(In reply to comment #14)
> Выложил патч.
> 
> На самом деле, как выяснилось, буфера
> клавиатуры в wine нет. Все сообщения WM_KEYDOWN
> попадают в очередь сообщений, из которой
> потом извлекаются и обрабатываются через
> hook'и.

....
> 

Вообще данную функциональность должен обеспечивать диспетчер очереди сообщений. Насколько я помню алгоритм такой (помню смутно, надо проверять):
- Перед созданием окна, создать и зарегистрировать диспетчер и очередь сообщений
- Помещать сообщения в очередь
- После создания окна соединить диспетчер и окно
- Начинать извлекать сообщения из очереди.

Comment 16 Илья Шпигорь 2009-03-31 16:09:43 MSD
Выложил [TRY 2].

Скорее всего, это решение более корректно. Вместо добавления буфера, теперь игнорируются сообщения WM_SYSKEYDOWN, в случае, когда окна с фокусом ввода нет. Т.е. вместо того чтобы это сообщение обрабатывало активное окно (так должно происходить согласно MSDN), мы ждем, когда появится окно с фокусом ввода.
Comment 17 Лебединский Александр 2009-04-20 09:48:47 MSD
(In reply to comment #16)
> Выложил [TRY 2].
> 
> Скорее всего, это решение более корректно.
> Вместо добавления буфера, теперь
> игнорируются сообщения WM_SYSKEYDOWN, в случае,
> когда окна с фокусом ввода нет. Т.е. вместо
> того чтобы это сообщение обрабатывало
> активное окно (так должно происходить
> согласно MSDN), мы ждем, когда появится окно с
> фокусом ввода.
> 

Данное исправление вызывает вот такой баг: http://bugs.etersoft.ru/show_bug.cgi?id=3827
Comment 18 Илья Шпигорь 2009-04-21 10:05:14 MSD
Текущее решение приводит к баге 3827, поэтому переоткрываю.
Comment 19 Илья Шпигорь 2009-04-21 15:44:21 MSD
Была идея ввести флаг определяющий, что окно еще не созданно и не готово принимать сообщения от клавиатуры. Идея оказалась не очень удачной - сначала создается окно, затем приходят сообщения WM_KEYDOWN, затем создается нужный контрол. Определить закончило ли приложение создавать контролы в окне достаточно сложно.
Comment 20 Лебединский Александр 2009-04-21 16:28:54 MSD
(In reply to comment #19)
> Была идея ввести флаг определяющий, что
> окно еще не созданно и не готово принимать
> сообщения от клавиатуры. 

С виду всё корректно...

> место добавления буфера, теперь
> игнорируются сообщения WM_SYSKEYDOWN, в случае,
> когда окна с фокусом ввода нет.
А как узнать что существует? Каково поведение этих "псевдоменю", может возможны хаки для подобных случаев? Правда, ещё неизвестно, помог ли этот патч автору бага...
Comment 21 Илья Шпигорь 2009-04-22 12:14:08 MSD
Проблема решена. См. комментарий #2 на багу #3827.
Comment 22 Виталий Перов 2010-04-21 16:46:08 MSD
Откатил патч:

commit f6623544a352687d5a724d61f9663706f3236184
Author: Ilya Shpigor <shpigor@etersoft.ru>
Date:   Sun Jan 11 16:14:09 2009 +0300

    user32/winex11.drv: Skip the icons stretching for 1c7 (eterbug #3114)

Перед патчем изменились имена переменных. Придётся патч переделать.

Также откатил последующий патч:

commit 5208c1aeeb56caa17f62971bc4c15e2cbb96cfff
Author: Ilya Shpigor <shpigor@etersoft.ru>
Date:   Thu Feb 26 10:58:11 2009 +0300

    user32: Add the correct redrawing for minimized windows (eterbug #1011)

Надо его не забыть потом приложить.

Изменения касаются только репозитория eterhack.
Comment 23 Константин Кондратюк 2011-09-09 14:52:30 MSK
(В ответ на comment #22)
> Откатил патч:
> 
> commit f6623544a352687d5a724d61f9663706f3236184
> Author: Ilya Shpigor <shpigor@etersoft.ru>
> Date:   Sun Jan 11 16:14:09 2009 +0300
> 
>     user32/winex11.drv: Skip the icons stretching for 1c7 (eterbug #3114)

Не уверен, что icons stretching влияет на буфер клавиатуры. Возможно, это опечатка Ильи в заголовке коммита.
Comment 24 Анатолий Лютин 2011-09-09 15:18:38 MSK
(В ответ на comment #23)
> (В ответ на comment #22)
> > Откатил патч:
> > 
> > commit f6623544a352687d5a724d61f9663706f3236184
> > Author: Ilya Shpigor <shpigor@etersoft.ru>
> > Date:   Sun Jan 11 16:14:09 2009 +0300
> > 
> >     user32/winex11.drv: Skip the icons stretching for 1c7 (eterbug #3114)
> 
> Не уверен, что icons stretching влияет на буфер клавиатуры. Возможно, это
> опечатка Ильи в заголовке коммита.

Так оказалось что я отвечал в эту багу :)

Посмотри комментарий номер 8 от Ильи, по-моему он тут как раз про иконки и говорит в нём, а так же указывает патч об этом...
Comment 25 Константин Кондратюк 2011-09-09 16:07:44 MSK
(В ответ на comment #24)
> Посмотри комментарий номер 8 от Ильи, по-моему он тут как раз про иконки и
> говорит в нём, а так же указывает патч об этом...

Да, спасибо. Это именно про него.

Но winex11 в текущем вайне настолько изменён, что я не уверен, что патч просто так может быть переделан и приложен. Создал другую багу по вопросу иконок, чтобы не забыть о том, что у нас было такое решение.
Comment 26 Vitaly Lipatov 2014-09-11 18:52:03 MSK
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.