Во время набивания накладной, например, когда вводишь новую строку в табличную часть, то справочник товаров (было порядка 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 В целом - весьма критично. Пока думаю предложить вместо того, чтобы вводить код сразу - давить пару раз стрелку вниз/вверх. Но это не серьезно... :(
ЗЫ Используется KDE. Другие DE еще не пробовал.
Хочу поменять описание ошибки. Как я понимаю, проблем в том, что под виндой при вызове справочника товаров(например) буфер клавиатуры не сбрасывается, т.е. появляется окно справочника и все нажатые до этого клавиши обрабатываются. Под линуксом клавиши начинают обрабатываться только с момента появления окна со справочником товаров. PS Сейчас в качестве терминального сервера под линуксом используется Core2QUAD 9400/2048 Gb. Проблема наблюдается и в терминальном режиме, и в локальном. Пробовал за это время: KDE3.5, GNOME, E17, KDE4.1.3 xfce, blacbox. Кажись ни в чем не ошибся;). Преимущественно использую KDE 3.5 и KDE 4.1.3.
Думаю, что проблему можно решить если ускорить процесс создания окон. Задержки, которые сейчас наблюдаются, связаны с более долгой отрисовкой иконок в wine по сравнению с windows. Это видно по мигающему заголовку окон.
Скорее всего, проблема не столько в буфере клавиатуры, сколько в посылке сооющения WM_KEYDOWN еще не созданному окну.
(In reply to comment #4) > Скорее всего, проблема не столько в буфере > клавиатуры, сколько в посылке сооющения > WM_KEYDOWN еще не созданному окну. Понятно. А как-то можно это обойти, вставив некоторую паузу (например, что-то около 1/10 секунды)? Чтобы в итоге клавиши обрабатывались в уже появившемся окне. Еще момент: такая проблема наблюдается не только при появлении окна, но и при начале редактирования строки в табличной части документа, например. Т.е. я думал временно обойти, используя поле типа не "Справочник.Товары", а "Строка". В итоге проблема аналогична: при нажатии ins - клавиши, нажатые до появления новой строки (и начала ее редактирования?) также пропадают. ЗЫ Спасибо за оперативность. Буду ждать решение. Пока это основная проблема. Странно, что ее раньше не было (если я не пропустил).
Проблема, думаю, была всегда. Постараемся решить её. Одной из идей было переключать фокус ввода до начала перерисовки окна. В крайнем случае можно не вынимать сообщения от клавиатуры до окончания перерисовки.
(In reply to comment #6) > Проблема, думаю, была всегда. Виноват. Не так выразился - не было (не нашел) в багах.
Выложил два патча. Первый откатывает патч на отступ в меню для 1с7. Эта проблема должна решиться, если иконки будут отрисовываться быстрее. Второй - хак, запрещающий масштабировать иконки для 1с7. Дело в том, что 1с сначала масштабирует иконки 16x16 в 32x32, а потом перед каждой отрисовкой обратно из 32x32 в 16x16. Операция масштабирования долгая, поэтому и вывод иконок так тормозит. Собственно, из-за этих иконок тормозит и создание окна, поскольку пока Non Client область не обновится, CreateWindow управленияне вернет. У этого решения возможны негативные последствия, но если это будут незначительные визуальные недачеты, думаю, ускорение 1с того стоит.
(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 ) пока еще никаких сдвигов? Спасибо.
(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 ) пока еще > никаких сдвигов? Нет. Вероятнее всего, проблему удастся решить этими патчами.
Изменил на Fixed. Если проблема должным образом не решится текущим патчем, надо переоткрыть.
Сборка 40/17 Заявленной проблемы нет
Извиняюсь за задержку (почти месяц был в командировке, потом решал накопившуюся текучку). Все-таки проблема до конца не решена (1.0.9 41/17, локальная версия, т.к. на сетевую закончилось время тестирования). Отображение стало быстрее, но не достаточно. Возможно это связано с размером справочника товаров - у нас порядка 12 000 - 13 000 позиций сейчас. Ведь время уходит не только на отображение, но и на чтение базы. Думаю, что все-таки нужно копать в сторону буфера клавиатуры. PS Лично мне это и не заметно, но фактуровщик у нас с этим сталкивается. :(
Выложил патч. На самом деле, как выяснилось, буфера клавиатуры в wine нет. Все сообщения WM_KEYDOWN попадают в очередь сообщений, из которой потом извлекаются и обрабатываются через hook'и. В данном случае проблема была в том, что пока создается новое окно фокус теряется, т.е. новое окно его еще не получило, а предыдущее уже потеряло. Из-за этого вместо WM_KEYDOWN сообщений генерировались WM_SYSKEYDOWN. Дальше для их обработки вызывался hook и их обрабатывало активное окно, т.е. предыдущее. Решение заключается в добавления буфера, в который заносятся все клавиши нажатые, пока нет окна с фокусом. Дело в том, что эти сообщения в любом случае должны быть извлечены из очереди сообщений, иначе программа не сможет работать дальше. После этого как только приходит сообщение WM_TIMER - этот буфер извлекается в окно, имеющее фокус.
(In reply to comment #14) > Выложил патч. > > На самом деле, как выяснилось, буфера > клавиатуры в wine нет. Все сообщения WM_KEYDOWN > попадают в очередь сообщений, из которой > потом извлекаются и обрабатываются через > hook'и. .... > Вообще данную функциональность должен обеспечивать диспетчер очереди сообщений. Насколько я помню алгоритм такой (помню смутно, надо проверять): - Перед созданием окна, создать и зарегистрировать диспетчер и очередь сообщений - Помещать сообщения в очередь - После создания окна соединить диспетчер и окно - Начинать извлекать сообщения из очереди.
Выложил [TRY 2]. Скорее всего, это решение более корректно. Вместо добавления буфера, теперь игнорируются сообщения WM_SYSKEYDOWN, в случае, когда окна с фокусом ввода нет. Т.е. вместо того чтобы это сообщение обрабатывало активное окно (так должно происходить согласно MSDN), мы ждем, когда появится окно с фокусом ввода.
(In reply to comment #16) > Выложил [TRY 2]. > > Скорее всего, это решение более корректно. > Вместо добавления буфера, теперь > игнорируются сообщения WM_SYSKEYDOWN, в случае, > когда окна с фокусом ввода нет. Т.е. вместо > того чтобы это сообщение обрабатывало > активное окно (так должно происходить > согласно MSDN), мы ждем, когда появится окно с > фокусом ввода. > Данное исправление вызывает вот такой баг: http://bugs.etersoft.ru/show_bug.cgi?id=3827
Текущее решение приводит к баге 3827, поэтому переоткрываю.
Была идея ввести флаг определяющий, что окно еще не созданно и не готово принимать сообщения от клавиатуры. Идея оказалась не очень удачной - сначала создается окно, затем приходят сообщения WM_KEYDOWN, затем создается нужный контрол. Определить закончило ли приложение создавать контролы в окне достаточно сложно.
(In reply to comment #19) > Была идея ввести флаг определяющий, что > окно еще не созданно и не готово принимать > сообщения от клавиатуры. С виду всё корректно... > место добавления буфера, теперь > игнорируются сообщения WM_SYSKEYDOWN, в случае, > когда окна с фокусом ввода нет. А как узнать что существует? Каково поведение этих "псевдоменю", может возможны хаки для подобных случаев? Правда, ещё неизвестно, помог ли этот патч автору бага...
Проблема решена. См. комментарий #2 на багу #3827.
Откатил патч: 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 #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 #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 #24) > Посмотри комментарий номер 8 от Ильи, по-моему он тут как раз про иконки и > говорит в нём, а так же указывает патч об этом... Да, спасибо. Это именно про него. Но winex11 в текущем вайне настолько изменён, что я не уверен, что патч просто так может быть переделан и приложен. Создал другую багу по вопросу иконок, чтобы не забыть о том, что у нас было такое решение.
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.
