update idletasks
do...@doro.poltava.ua
Всем привет !
Опишу проблему.
Возникает она на медленных компутерах,
или на быстрых, если все ускорить :-)
Представьте окно, в левой части которого находится,
например listbox с информацией о пользователях,
по одному пользователю на строку.
В правой части, находится пара десятков виджетов, для отображения
атрибутов пользователя.
Активировали пользователя, пошла выборка атрибутов с Бд
и визуализация в правом окне.
Что происходит ?
Если быстро двигаться по списку пользователей,
то изза медленности рисования правых виджетов иногда возникают
всякие там ошибки что однин из правых виджетов уже существует,
или наоборот его нет, а обращения в других функциях к нему уже происходит.
Безусловно, если дать время на завершение всех вызовов по правым окнам
при активации пользователя в левом окне, никаких ошибок не происходит.
Как решить проблему ?
есть идея использовать grub, исключив возможность
направления события на левое окно.
Что еще ?
PS. Это виртуальный пример. В реальности все сложнее
и понятно, что я обрабатываю такие вещи как например
отказ от повторного рисования левых виджетов при переходе
от пользователя к пользователю.
В реальности слева дерево со списком обьектов с
различными атрибутами.
Good luck.
----------------------
With respect, Eduard.
mailto:do...@doro.poltava.ua
http://doro.poltava.ua
ICQ: 176017203
Artem Chuprina
d> Всем привет !
d> Опишу проблему.
d> Возникает она на медленных компутерах,
d> или на быстрых, если все ускорить :-)
d> Представьте окно, в левой части которого находится,
d> например listbox с информацией о пользователях,
d> по одному пользователю на строку.
d> В правой части, находится пара десятков виджетов, для отображения
d> атрибутов пользователя.
d> Активировали пользователя, пошла выборка атрибутов с Бд
d> и визуализация в правом окне.
d> Что происходит ?
d> Если быстро двигаться по списку пользователей,
d> то изза медленности рисования правых виджетов иногда возникают
d> всякие там ошибки что однин из правых виджетов уже существует,
d> или наоборот его нет, а обращения в других функциях к нему уже происходит.
d> Безусловно, если дать время на завершение всех вызовов по правым окнам
d> при активации пользователя в левом окне, никаких ошибок не происходит.
d> Как решить проблему ?
d> есть идея использовать grub, исключив возможность
d> направления события на левое окно.
d> Что еще ?
d> PS. Это виртуальный пример. В реальности все сложнее
d> и понятно, что я обрабатываю такие вещи как например
d> отказ от повторного рисования левых виджетов при переходе
d> от пользователя к пользователю.
d> В реальности слева дерево со списком обьектов с
d> различными атрибутами.
Сдается мне, что надо не прибивать и создавать заново виджеты, а менять
в них значения.
Ну и нарисованность виджетов не то чтобы очень сильно коррелирует с их
существованием...
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
У кошки четыре ноги: ввод, вывод, земля и питание.
do...@doro.poltava.ua
Артем, спасибо за ответ.
Так и сделано, я ведь в PS. описал
1) если однотипные данные выводятся то виджеты я не перерисовываю а меняю значения
2) а для разнотипных - приходится перерисовывать.
если можно (вопрос к модератору)
я брошу два скриншота
для разнотипных данных ?
а то на пальцах модно и ошибиться в обьяснениях
Kirill Frolov
> Безусловно, если дать время на завершение всех вызовов по правым окнам
> при активации пользователя в левом окне, никаких ошибок не происходит.
> Как решить проблему ?
Очевидно -- до завершения очередной операции отрисовки не стартовать
другие. Непонятно только, откуда в чистом эхотаге оно так получается.
Где-то запускается обработка событий -- блокирующий вызов какой-либо
функции (обращение к серверу БД)?
Kirill Frolov
> Так и сделано, я ведь в PS. описал
> 1) если однотипные данные выводятся то виджеты я не перерисовываю а меняю значения
> 2) а для разнотипных - приходится перерисовывать.
Не надо. При конечном (и ограниченном) числе типов можно все окна
заранее создать, а потом только упаковывать. Так реально быстрей.
> я брошу два скриншота
> для разнотипных данных ?
Выложи куда-нибудь, чтоб по http смотреть. И не надо мучать
общественность ююками -- они в гугле не видны. :-(
Нарисуй на бумажке конечный автомат своего мегавиджета с основными
событиями -- сразу дойдёт. Любой блокирующий вызов интерфейсов ос у тебя
вызывает запуск обработки событий и переход в этом автомате по событию
из листбокса.
do...@doro.poltava.ua
On Thu, 23 Nov 2006, Kirill Frolov wrote:
> > Так и сделано, я ведь в PS. описал
> > 1) если однотипные данные выводятся то виджеты я не перерисовываю а меняю значения
> > 2) а для разнотипных - приходится перерисовывать.
>
> Не надо. При конечном (и ограниченном) числе типов можно все окна
> заранее создать, а потом только упаковывать. Так реально быстрей.
>
> > я брошу два скриншота
> > для разнотипных данных ?
>
> Выложи куда-нибудь, чтоб по http смотреть. И не надо мучать
> общественность ююками -- они в гугле не видны. :-(
http://doro.poltava.ua/1.jpg
http://doro.poltava.ua/2.jpg
Пояснения:
при быстром перемещении от Сидельникова к 18
иногда происходит то, что я описал.
Alexander Zubarev
Я так понимаю, ситуация происходить под Win? Проверьте под Linux, должно
исчезнуть...
KF> Очевидно -- до завершения очередной операции отрисовки не стартовать
KF> другие.
Это к сожалению не всегда возможно... Сталкивался уже.
KF> Hепонятно только, откуда в чистом эхотаге оно так получается.
В виндах создание окон и отрисовка асинхронны. И я уже нарывался на глюку,
когда после создания виджета в тикле, реальное окно еще не создалось. И при
попытке писать в него происходит ошибка на уровне WinAPI, которая теряется
где-то в потрохах Tk (обнаружено было экзотическим способом, на отладочной
версии виндов).
То есть на мой взгляд это бага виндовой реализации tk. :-(
update idletasks она не лечится (по скольку с точки зрения тикля никаких
отложенных событий нет). after idle - тоже не помогает.
Мне удалось ее обойти только "after 100 ..."
Вот примерно в таком духе:
------------
update idletasks
after 100 "focus $p"
-----------
do...@doro.poltava.ua
On Fri, 24 Nov 2006, Alexander Zubarev wrote:
> Я так понимаю, ситуация происходить под Win? Проверьте под Linux, должно
> исчезнуть...
Вы абсолютно правы !
под линь даже пробовать не хочу, не по религиозным причинам, просто заказчику надо под винь.
>
> KF> Очевидно -- до завершения очередной операции отрисовки не стартовать
> KF> другие.
>
> Это к сожалению не всегда возможно... Сталкивался уже.
>
> KF> Hепонятно только, откуда в чистом эхотаге оно так получается.
>
> В виндах создание окон и отрисовка асинхронны. И я уже нарывался на глюку,
> когда после создания виджета в тикле, реальное окно еще не создалось. И при
> попытке писать в него происходит ошибка на уровне WinAPI, которая теряется
> где-то в потрохах Tk (обнаружено было экзотическим способом, на отладочной
> версии виндов).
> То есть на мой взгляд это бага виндовой реализации tk. :-(
> update idletasks она не лечится (по скольку с точки зрения тикля никаких
> отложенных событий нет). after idle - тоже не помогает.
> Мне удалось ее обойти только "after 100 ..."
> Вот примерно в таком духе:
> ------------
> update idletasks
> after 100 "focus $p"
> -----------
Спасибо.
А возможно ли как нибудь установить глобально интервал между событиями,
касающихся клавы и мыши ?