Итак я научился делать прозразный фон окон! Спасибо Earnest! Правда я чуть поправил код, ибо он не работал до конца нормально. Но огромное спасибо тебе за мысль!!! Спасла старика, и дала веру в себя!
Чуть позже я выложу вам способ
Теперь помогите добить окна..Я совсем перегорел..
Я прикрепляю файл с интерфейсом.
Есть БОЛЬШОЕ главное диалоговое окно. Оно имеет три кнопки слева, две справа вверху и окно контейнер.
Обратите внимание! Посередине него есть большое окно. Оно имеет полосу прокрутки. Остальное вы не увидете из-за прозрачного фона оно сделано производным от СWnd Это окно контейнер
Я нарисовал на БОЛЬШОМ (главном диалоге его как CUSTOM CONTROL)
Внутри этого окна создаются белые окошки-динамически по мере поступления сообщений от системы.
Белые окошки я сделал от диалоговых производными.
Теперь вопросы.
1.Где динамически создавать диалоговые окна? Так как я окно контейнер не создаю через Create(), то сообщения в этом классе по созданию окна отлавить невозможно. Поэтому я создаю диалоговые окна в OnInitDialog() большого окна..
2.Где ресайзить белые диалоговые окна? Они должны ресайэиться вместе с главным окном.
3.Как лучше контролировать каждое созданое белое окошко? Как знать о его уникальности? Создать массив указателей? Назначать каждому ID? Но как знать, что именно пятое диалоговое окошко должно обновить в себе элементы?

Присоединённый файл ( Кол-во скачиваний: 18 )
 all.rar 51,45 Kb

Никто даже не скачал файл!

Помогите!

Добавлено @ 17:45
Я ж вам помогал в свое время, жулики!

Coocky, это опять я...
Во первых, молодец, что справился с прозрачностью! Я же тебе говорила, что справишься
Во-вторых:
1) в OnInitDialog создавать дополнительные окна вполне нормально
2) Где ресайзить? Что за вопрос! Это же его child'ы - значит, в OnSize основного диалога
3) Конечно, нужно их все запомнить в массиве, я бы помнила pWnd, нафига их ID, это вообще что-нибудь служебное, лишь бы было.
4) Обновляются пусть сами, на OnIdle, и сами следят за своими изменениями. Скажем, главное окно по Idle вызывает их Idle-обработчики.

Как узнать, что именно пятое окно должно обновить свои данные? Можно по-разному сделать.

Например, схема N1, асинхронная: окна запрашивают данные у какого-либо объекта, назовем его "источник данных", кто бы он не был. Этот объект обладает следующим свойством: при изменении части данных он инкрементирует свой внутренний флаг timestamp.Окно, которое должно выводить данные этого источника, тоже имеет свой timestamp. Idle-обработчик спрашивает источник данных - какой нынче timestamp. Если у меня такой же, спим спокойно дальше, если больше, чем у меня, обновляем данные, обновляем timestamp и снова спим дальше.
А далее - можно по источнику данных на каждое окно, можно один для всех - как удобно...

Схема N 2, синхронная: реализуем шаблон Подписчик-Издатель. Ну, то есть, источник данных, сразу после обновления, рассылает уведомления всем заинтересованным объектам (тем, что подписались).

Мне лично для синхронизации с UI больше нравится схема N1: обновлять timestamp можно после изменения любого поля, не беспокоясь о том, единичное это изменение или пакетное - обновление данных будет происходить на Idle, без лишних морганий.

благодаря тебе

Т.е и диалоги и диалоговы элементы? Все в обработчике основного окна?
Ну я понимаю кнопки БОЛЬШОГО диалога, ну понимаю , что окно контейнер надо, но разве белый диалог и его дочернии элементы тоже там?
Я чего спросил.. Попробывал я ресайэить кнопки белого диалога(так называю что б понятней из рисунка было.. ) в обработчике OnSize() этого диалога... Дуля с маком(как в детстве говорили)
Вот примерно что получается



Дя меня вообще остались важными 3 момента.
1.Скролирование окна контейнера. Никогда руками не делал, но правда еще и не брался Но на всякий случай уже боюсь.
2.Где обрабатывать(в каком классе) сообщения. Дело в том, что программа "слушает" программы шпионы. И как только (я не знаю как это происходит-это драйверный отдел делает ) обнаруживает его-создается белый диалог с заполнеными данными про обнаруженого шпиона. Таких диалогов может создаться бесконечно.
Т.е стоит вопрос-либо класс окна контейнера либо БОЛЬШОГО окна (слушать в классе белого диалога я не вижу смысла )
3.КАК же правильно всех ресайзить!! Где,т.е.

Это сообщение отредактировал(а) Coocky - 30.1.2006, 21:42

Вставлю пару слов по поводу ресайзинга.
Я с этим уже прилично намучался, и вспомнил свой небольшой опыт программирования на JAVA. Так вот, в GUI-прибамбасе этого языка ("java awt", если не изменяет память, называется), по умолчанию на всех окнах установлны так называемые менеджеры компоновки. То есть заранее все окна разбиты на какую-то логическую структуру (например, табличный менеджер компоновки), и при добавлении элементов в окно элементы сазу заполняют такую структуру. (То есть например, ячейки некой абстрактной таблицы). И дальше при любых махинациях с позицией/размером окон менеджеры компоновки сами перерисовывают контролы в соответствии с этой "Картой". Размеры ячеек создаются как фиксированными, в пикселах, так и в процентном соотношении от размера окна. (Если когда-нибудь работал с HTML, то наверняка знако с таким подходом. )

Я подумал, почему бы данной идее не прижиться и в родимом MFC, и реализовал у себя класс, подобный явовскому табличному менеджеру компоновки. Экземпляр этого класса я создаю в каждом нужном мне окне, связываю с окном-хозяином, и в его ячейки помещаю *CWnd всех контролов, находящихся в окне-хозяине. Единственное, что после этого остается сделать - в окне-хозяине в обработчике WM_SIZE вызвать одну из функций этого класса. И все. О ресайзинге после этого можно забыть. Главное, в каждом окне правильно расчертить карту, то есть правильно заполнить параметры менеджера компоновки. Ну и естественно, делается все по принципу "матрешек" - то есть в каждом масштабируемым подобным образом окошке создается свой табличный менежер, в его ячейках - свой, и так, пока каждый контрол не окажется на своем законном месте.

Получается, что работает такая хреновина следующим образом - при получении сообщения WM_SIZE вызывается как рз та самая функция менеджера компоновки. Эта функция рассчитывает все значения координат для добавленных в него контролов, после чего каждому контролу делает SetWindowPos с соответствующими параметрами. Эта функция приводит в свою очередь к тому, что каждое добавленное в менеджер компоновки окошко в свою очередь тоже ловит WM_SIZE, и если в этих окошках есть свои "мини-карты", то для них тое соответственно вставляются обработчики этого события.
Вставка всех необходимых обработчиков занимает буквально несколько минут.
"Разметить" карту плучается чуть дольше, для этого допусти в диалоге, созданном в редакторе ресурсов, нужно для каждого кнтрола получить его указатель и засунуть в менеджер кмпоновки соответствующей функцией, тут главное не напутать с размернотью ячеек (а их можно проставлять как в пиксельном, так и в процентном соотношении, как я и говорил уже).
Ну и на разработку самго класса у меня ушло около часа-двух, и хоть он получился достаточно сырым и путанным - он мне уже сильно облегчил жизнь, с ресайзингом дочерних контролов больше не заморачиваюсь.
Так что советую воспользоваться чем-то подобным ;)

Это сообщение отредактировал(а) Dreamer_0x01 - 30.1.2006, 23:11

Кстати,о скроллинге. Одной из моих первых программ на MFC была фишка, где одно окно скроллировалось внутри другого. Ничего сложного и глючащего, все прекрасно работало.
А делал так -
1. в главном окне создавал окошко "окно 1" от CWnd и полосы прокрутки.
2. Внутри "окна 1" создавал "диалог 2" от CDialog со стилем CHILD, в отором создавал столько контроло и окон, сколько душе угодно.
3. Делал SetWindowPos "диалога 2" внутрь "окна 1" c флагом "SWP_NOZORDER" и "SWP_NOSIZE". И вот координаты, передаваемые в этот SetWindowPos величины, высчитанные из отношения разности в размерах окон "диалог 2" и "окно 1", к позиции скроллбара. А параметры скроллбара, соответственно, высчитывал также сходя из отношения размеров этих двух окон. Могу в принципе нарисовать рисуночек, если не понятно. Либо сотворить небольшой проектик, где это реализуется.

Почти моя ситуация, только этих диалогов может быть сколь угодно и создаются они динамически
Но это еще впереди..Главная проблема сейчас №1-немогу отпозиционировать элементы самого вложеного диалога по отношению к этому диалогу. Читай выше

Так как предлагает Earnest-надо тогда перебирать все диалоги в окне контейнере(кстати, а как правильно перебрать все диалоги и получить на них указатели-для окна контейнера)?-не сложно ли это будет?
Добавлено @ 10:55
Хаха!
Вообще бред!

Обьект умирает до отладки
Простите инвалида

Добавлено @ 11:24
Итак ресайзинг побежден..Осталась прокрутка
Ждите новых сообщений

Ах да,забыл спросить Как перебрать все диалоги(получить на них указатели) в окне контейнере?

Ну что ж,я начинаю востанавливать свою былую форму
Итак перебор все окон


Осталась прокрутка, пока

Ну и что это меняет?


и как поживает?

Еще не знаю Всегда пользовался только халявным CSrollView

Я даже не знаю как запускать, не говоря о расчетах..
Я не пойму -окно само прокрутит или нужно сдвигать все диалоги при прокрутке?

Coocky "Само" ничего не делается .

Не совсем поняла из твоих постов: эти самые диалоги, которых сколько угодно и которые динамически создаются - они что, в контейнере располагаются друг под другом, как бы на длинной ленте, которая проматывается через окно контейнера? Или я что-то путаю?

Почему бы тебе тогда не использовать ScrollView в качестве контейнера?
Можно также посмотреть код FormView.

Насчет ресайза я, конечно, имела в виду, что каждый, кто получает WM_SIZE, вызывает SizeWindow или MoveWindow (или лучше SetWindowPos) только для своих непосредственных детей, они, соответственно - своих и т.д.

Точно. Только еще эти диалоги могут сворачиваться и разворачиваться пользователем

А разве нет проблем присоздании на диалоге ScrollView? Просто добавил класс и все?

Вообще-то есть, но вполне обходимые.
Точно уже не помню, но смысл в том, что все view хочут иметь папой frame-window. Но хочут они этого только в паре мест, которые можно переопределить. Пару месяцев назад я в какой-то теме подробно описывала, что именно и где нужно для этого прикрутить. Тема была про использование CListView вместо CListCtrl. Я подробностей уже не помню, можешь поищешь на форуме? Если не найдешь, попробую восстановить. Помню, я это из своего старого кода выдирала...
Добавлено @ 15:24
Нашла, вот
Добавлено @ 15:28
Конечно, нужно определить свой производный класс, а в качестве документа - использовать объект, который выполняет роль источника данных. Если его еще нет - создай, интерфейс с управлением данными лучше поделить.

Нихрена себе халявный. Я даже не смог разобраться, для чего он предназначен, а не только как с ним пользоваться.
Поэтому и делал скроллинг вручную =)


Слушай, я щас в запаре, но вот вечером могу наваять тебе простенький диалог, где все будет прокручиваться так,как я говорил.

Вот только что сделал. Нехочу документ..Все нормально работает, пока не уничтожаю окно
Вылетаю в дебаг. Причем проблема не одна , а куча... А можно без документа?
Добавлено @ 15:59


Это потому, что вы не умеете их готовить
Окей! Только ,если не трудно-сделай диалог, а в нем окно с прокруткой. Ну и пусть в том окне созаться 100 кнопок.
Если я с Earnest не добью SrollView, тогда возьму твой вариант Да и полезно будет посмотреть и научится скролить

Не хочешь, не надо, можно и без документа. View всегда проверяет, есть ли у него документ...
Показывай, куда вылетает... ASSERT небось какой-нибудь?

В смысле?

Добавлено @ 16:11

ну почитай статью Earnest она предлагает документ прикреплять. А мне он не нужен. Только прокрутка

Короче не нравится ему, что указатель не из той кучи

Coocky
Проверь, что у тебя в PostNcDestroy.
Может, ты решил вообще ее не определять, раз флаг bDynamic тебе не нужен?
Так вот, по умолчанию, PostNcDestroy всегда удаляет this. Тебе же нужно переопределить этот метод и сделать его пустым...

Если я не угадала, посмотри выше по стеку, какой именно указатель удаляется.

Coocky
Через минут 10 я тебе пример со сколлинго залью. Жди, я сюда ссылку кину.

Держи плюс
Слушай, но откуда такая инфа?
Жду с нетерпением
Добавлено @ 16:44

Сегодня не дают.Завтра
Блин, я всем хочу сказать. За все время существования форума, Earnest у нас третий человек из "высших".
На сколько я помню до нее из гениев были
1. mr.DUDA
2.Андрей Ямов
Теперь Earnest
Жаль что такие люди не всегда на форуме. Обычно они его покидают через время. Но пока они есть-черпайте знания

Значит, угадала...

Ну, Coocky, ты сказал... слезы душат... пойду искать носовой платок...

Итак, вот тебе примерчик, правда, я очень торопился - увидишь по коду =)
И скроллинг только вертикальный сделал. Если понравится идея - горизонтальны сам сообразишь, он попроще в плане нормального пересчета координат будет ;)

На народ.ру конечно отстойно заливать, но больше некуда, так что уж не обессудь ;)
http://megadreamer.narod.ru/Test2.rar

Э.....Проблема.
Окно скролируется вместе с бекграундом
Добавлено @ 17:02
Dreamer_0x01
Не у тебя
Сейчас твое гляну
Круто! Молодец и быстро -то как!
Интересно, а проблемы с бекраундом будут?
Ща проверим
З.Ы.
Спасибо всем, не ожидал от вас такой инициативной помощи
Добавлено @ 17:05

Пардон. Я сильно паникую

Хм, возможно, как-то забыла про твои хитрые фоны.
Подозреваю, что тоже самое будет в варианте Dreamer_0x01, если он использует функцию ScrollDC.
Но прикрутить можно все... пойду посмотрю в ScrollView.

Все. На сегодня всем отбой!
Да думаю уже и все проблемы
Все скролируется и перерисовывается БЕЗ МЕРЦАНИЙ Всем спасибо еще раз.
С меня форуму-прозрачные окна

Так чье решение все-таки взял за основу? ;)
Добавлено @ 19:08

Не-а Я вообще контекст не трогаю, просто тупое "таскание" одного окна по другому

Тогда, может, ScrollWindow (как в ScrollView) ?
Та же фигня... Короче, в данном случае (чтобы фон был прибит) придется перерисовывать все окно, потому что функции ScrollЧегоНибудь очень экономно перемещают биты контекста и плевать им, что там - фон, текст. А в данном случае нужно именно тупо перерисовывать окно в другой позиции...

Нет. Там роме SetWindowPos() ни одной функции, что-либо скролирующей =)


Так посмотри в моем коде - так и делается! Окно таскается именно целиком =)
Я вот только не очень понял изначально - хорошо это или плохо? Нужно, чтобы фон гулял вместе с окном, или наоборот, стоял на месте?

Coocky, по-моему, нужно, чтобы фон не двигался.
Значит, твой код ему подойдет.
А вообще, если таких изысков с фоном нет (т.е. окно прокручивается как единое целое), обычно используют ScrollWindow или ScrollDC (это просто копирование той части окна, которая уже есть, но в новую позицию). Плюс, ScrollWindow еще дополнительно делает инвалидными те части окна, которые до перемещения были скрыты. И для них тебе приходит WM_PAINT.
Если делаешь ScrollDC, то это нужно делать руками, но больше управляемость...

Конечно, код получается посложнее, чем просто SetWindowPos. Но если для, скажем, списка какого-нибудь перисовка (а SetWindowPos - это полная перерисовка, как ты понимаешь)... - максимум моргание вызовет (с которым можно побороться), то для окна набитого более-менее сложной графикой (или картинкой смасштабированной), такая реализация скроллинга будет сильно тормозить... А закат солнца вручную (ScrollDC + Invalidate недостающих кусочков) - летает...

Я согласен, но во-первых, можно сделать "умную" перерисовку в OnPaint,отрисовав предварительно все содержимое окна в некий виртуальный битмеп размера, равного таскаемому окну, а во-вторых, от прокрутки обычно диких скоростей перерисовки не требуется, главное, как ты уж упомянула, чтобы не было противного глазу моргания. А подтормаживания скроллбаров работе не вредят (например, вспомним чтение документа в MS Word). Мы один раз тыркаемся в скролл, выставляем область прокрутки на нужную позицию, не сильно обращая внимания на небольшие задержки в скроллировании (а их можно сделать действительно совсем небольшими),и потом долго и упорно читаем текст с данного места.
Добавлено @ 20:48
Вообще, в программировании внешнего интерфейса есть две крайности:
1. Красиво, запутано,но глючно.
2. Строго, быстро, но скучно

Я про графику говорила - рабочий экран программ типа Photoshop, Corel, AutoCAD в конце концов. Кроме того, прокрутка - это не только с помощью скролл-баров, но еще и с помощью мышиного косеса, а также панорамирование (это когда экран как бы таскают за любое место - черт его знает, почему это панорамированием называется). Короче говоря, если в таких программах прокрутка будет тормозить, пользователи повесятся... или закидают тухлыми яйцами аффтара

Ладно, подождем Coocky, послушаем, чем же все-таки закончились его страдания.

Они еще вчера закончились

Че у вас с трафиком? Или я так быстро пишу. что вы не успеваете читать
Вот еще , что хотел спросить.. Про OnIdle.
Она только ж в App перегружается?
Дело в том, при каждом ресайзинге большого окна я перерисовываю две кнопки в правом верхнем углу. Если этого не сделать, то если резко и быстро таскать приложение(растягивать) влево-вправо, то рано или поздго-одна кнопка захватит часть изображения второй. Однако если перерисовывать -все нормально-но Ма-а-аленькое мерцание при растягивании. Я вот подумал, а что если перерисовать после растяжки, т.е. словить отсутсвие сообщения. Но только один раз, вернее когда значение счетчика остусвия сообщений =1
Только вот плохо то, ЧТО б достучаться до кнопки, нужно лезть к ним через указатели.
Как можно решить эту проблему? И вообщем сам способ-хорош?

Ну CScrollView Просто прокрутка там делается ОДНОЙ функцией Ну и твой пример посмотрел и сохранил.
Надо ж знать, как самому крутить. Кстати-ничего сложного, чистая математика. Я просто думал, что окна нужно еще и самому отрисовывать, когда они выходят за рамки окна

Еще в документе.

Но в окнах тоже можно ловить Idle.
В модальном диалоге, в карту сообщений нужно добавить обработчик сообщения WM_KICKIDLE. Это сообщение определено в MFC, нужно подключить afxpriv.h
Кажется, сообщение посылается без параметров, во всяком случае, я никогда их не использовала, и не знаю, что в них. Поэтому получить счетчик отсутствия сообщений не получится. Но можно (и даже лучше) сделать так: завести переменную в классе, скажем, bNeedRedraw, OnSize - ставим ее в 1, OnIdle - проверяем, и если она 1, делаем кнопкам Invalidate и сбрасываем.

Дык откелева у меня модальный диалог? Для моего диалога есть что нибудь похожее? А для беленьких?
Пойми, я хочу в OnIdle сделать переисовку, но как мне достучаться до окон из CWinApp?
А если оттуда нельзя, как же получить похожее на OnIdle в моих классах?

А какой же у тебя диалог? В твоем коде, что я видела - главный диалог модальный и есть. У тебя ведь вообще диалоговое приложение. Остальные диалоги - вложенные child'ы. Им ничего такого не приходит - значит, нарисуй соответствующую функцию у контейнера и вызывай из главного диалога. А главному - должен приходить WM_KICKIDLE, как я и говорила.

Для справки: для немодальных окон тоже есть свое сообщение:
WM_IDLEUPDATECMDUI, расылается из App как раз на Idle. Но это только для SDI или MDI приложения.

А ну да

Че-то я и в МСДН толком ничего не найду по этому сообщению.
Как его определить?

Coocky



и т.д.
А послать сообщение можешь вообще накрайняк всем, зарегистрировав его... Или Взведи евент, а по нему отрисовывай отдельно каждое окно. А лучше просто (диалоги то надеюсь объявляешь во фрейме документа?) взять да послать WM_PAINT каждому аля ::PostMessage(pFrame->mydlg[7]->GetSafeHwnf(),WM_PAINT,0,0) или напрямки pFrame->mydlg[7]->Invalidate(). А если я не в тему, то уж не обессуть

Да у меня окно диалоговое Какие фреймы

A!
Забросил я это дело...
Не призодит сообщения Молчит моя OnIdle

Это сообщение отредактировал(а) Coocky - 1.2.2006, 13:57

Cтвойдиалог* pDlg = (Cтвойдиалог*)AfxGetMainWnd();
он же Cтвояаппликация* papp = (Cтвояаппликация*)AfxGetApp()->m_pMainWnd;

Думаю, что диалоги ты объявляешь либо в "Cтвояаппликация" либо в "Cтвойдиалог" - вот тебе и доступ до всего
Добавлено @ 14:11
а я все таки думаю, что не стоит так широко использовать OnIddle, в крайнем случае в ней какой-нибудь евент взвести... так как пока мы находимся в OnIddle, то ничего другого не сможем наверное сделать (я опять про ядреную войну с отображением кнопки ) - война вот уже как полчаса, а оператор - кнопкодав не видит ничего, сидит кино зырит, а в OnIddle вообще пошла выполняться дефрагментация дисков на соседнем компе

а не вызывается она у меня ,OnIdle

значит грузишь прогу... А может и не вызывается, вот как проверить? - так возьми супер комп и ежели не вызовется, тогда просто не заходит туды. Хороший способ, правда?

Coocky
Про WM_KICKIDLE в MSDN действитеьльно мало (где-то в technical notes).
Ничего сложного.
1) Подключи файл <afxpriv.h>
2) В главном диалоге создай обработчик afx_msg LRESULT OnKickIdle(WPARAM,LPARAM);
(имя произвольное)
3) В карту сообщений добавь ON_MESSAGE(WM_KICKIDLE,OnKickIdle)
4) В самом обработчике делай, что хотел на Idle, возвращай 0.
Добавлено @ 14:33
OnIdle приложению не приходит потому, что это диалоговое приложение - там не вызывается CWinApp::Run, а работает просто CDialog::RunModalLoop. Там все чуть-чуть по другому. А WM_KICKIDLE должен приходить.
Добавлено @ 14:35

Как раз очень удобно использовать Idle-обработку. Но конечно, с умом - ничего тяжелого там делать не следует. На случай ядерной войны.
Но прорисовка к тяжелым функциям не относится.

Earnest
Добавлено @ 14:43

Кстати, писал я в молодости визуализацию результатов газодинамических расчетов(заливка разными цветами каждой точки- расчетной ячейки) - очень надо сказать тяжеленькая операция, если ещё и вектора - никогда момент начала войны не словить...

Кто же спорит, все что угодно можно тяжелым сделать... умеючи-то
Я про приложение Cooky говорила.

Earnest
Ну что... Еще раз доказала-что лучшая

Я вот осмелюсь вместо OnIdle воспользоваться...только не кидайтесь тухлыми помидорами преждевременно...WM_TIMER в самом окне, чтоб не надо было до него достукиваться!
Ведь это сообщение не синхронное, и если таймер его посылать чаще, чем допускает система, оно просто будет выкидываться из очереди. То есть в те моменты, когда окно ничем не занято, мы это сообщение будем ловить нормально. Как только приложение "дало газу ;)", оконная очередь сообщений нагружается и сообщения WM_TIMER не игнорируются. Думаю, стоит попробовать, во всяком случае, это точно способ хорошо самоизвратиться ;)

Интересен еще интервал, что б выкидывалось. Что б даже на движение мыши реагировало, т.е. уже выкидывалось. Такое возможно? С каким интервалом?

WM_TIMER можно, но действительно не очень понятно какой интервал установить. Кстати он не может быть меньше 10 mc.
Однако в данном случае OnIdle лучше, т.к. это сообщение гарантированно приходит каждый раз как очередь сообщений опустошается - т.е. как раз тогда, когда приложение освободилось.

Попробывал. Кнопки как в фантастике-плавно асинхроно перерисовываются в виде пробегающей строчки. Прикольный эффект, но для другого раза
А толком не спасает. все равно заметно, если резко дергать

Вот такой интервал как раз и установить. Чтоб сообщения проходили только когда система подразгрузилась. Но! Можно ведь еще добавить в класс переменную. И с помощью нее отслеживать каждые сто таких сообщений. По переполнению этого значения ее обнулять, и вызывать прорисовку. Тогда мы как раз и получим при сильной загруженности нечастые перерисовки (сотня событий через занятую очередь будет "пропихиваться" достаточно долго.) А при слабой загруженности будем переполнять эту переменную гораздо чаще.
Добавлено @ 19:47

Покажи начальству, может, оценит и попросит оставить