| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
GRush Controls
homm © (2005-10-22 16:03:00)
Страницы: < 1 2 3 4 5 6 7 8 9 >
Эпиграф:
"Лучшее враг хорошего"
Многие из вас знакомы с котролами RBControls от Nathanaлl VERON.
Еще большим из вас, наверное знам порт этих контролов под KOL
от RA. Два месяца назад я тоже впервые увидел эти контролы.
Надо сказать что они меня сильно порадовали и я даже стал разбиратся
в исходниках, присылать баг репорты и замечания по коду, и примерно
дня через 3 я понял что ни Nathanaлl VERON ни RA до этого ни разу
не работали с графикой. Многие наверное замечали что RB просто не
реально долго изменяют свой размер, достаточно не быстро рисуются
и прорисовка их в некоторых случаях не совсем коректна. Все это
подталкнуло меня к написанию своего аналога, полностью заменившего
бы контролы RB.
Итак почти через два месяца работы (ну нет у меня возможности
писать каждый день) я хочу поделится своими трудами - GRushControls.
Оновные отличия (преимущества) GRush Controls по сравнению с RB Controls.
-------------------------------------------------------------------------
Первое и самое главное - они БЫСТРЕЕ, причем я говорю не о процентах и
даже не "разах". Они быстрее на порядок! Стоить наверное уточнить о
что под скоростью прорисовки я имею ввиду не только реакцию на
Invalidate, хотя и ее тоже, но и на изменение размеров контрола.
Но что значит "быстрее"? Фактически на их основе становится реально
развешать панелей с градиентом по форме, развернутой на весь экран,
нагрузить ее элементами под завязку и запустить все это чудо на любой
машине с процессором P200 MMX и метрами так восмью видео памяти не
переживая что на разворачивание формы пользователь будет лицезреть
"в реальном времени".
-------------------------------------------------------------------------
Второе о чем бы я хоте упомянуть коректность прорисовки. Попробуйте при
16 битах запустить RB и вы неприменно увидите полосы на градиенте. Еще
например в RB видны какието "битые пикселы" внизу у градиента панели.
Но это по большому счету не так важно, гораздо важнее то что ...
-------------------------------------------------------------------------
В третьих RB - прямо не контролы, а спльшной компромис. Яркий пример -
в панели нельзя использовать схлаживание рамки однавременно с градиентной
заливкой. В GRush таких ограничений нет. Вы в можете задать сглаживание,
градиент, произвольную ширину Border'а, отдельно настроить размер скругления
по вертикали и горизонтали, поместить рисунок, отфармотировать надпись
(слова "выбрать ориентацию текста" слабо подходят для выражения сути
происходящего). Все выше перечисленое можно проделать не только с панелью.
Можно вполне задать Border для сплиттера, или вставить изображение в CheckBox.
Кроме того большинство параметров прорисовки для каждого "состояния" задаются
отдельно (всего состояний четыре: нормальное, с наведеным курсором, с нажатием,
неактивный контрол) это позволяет делать вещи, о которых я даже не подазревал
кагда писал компаненты (элементрарные прмер - смещение градиента на пиксаль
вниз в состоянии "нажато" придает эфект утапливаемой кнопки)
-------------------------------------------------------------------------
Кроме того:
* Размер кода GRush меньше примерно на 5 кб
* Размер выполняемого приложения в памяти в общем случае меньше
(конкретные цифры зависят он размеров компанентов и аоличества панелей)
* Много еще приятных мелочей.
Из недостатков (читать: еще не дописал):
* MCK в проекте начало существование с сегодняшнего дня. Ничего кроме создания
контролов она делать еще не умеет, посему все свойства надобно где нибудь
в FormCreate выставлять (в вемах ощие принцип показан).
* Отсутствуют некоторые контролы (ProgressBar, StyleManager, возможно Memo)
* Кнопка не может быть "вдавлена" (AllowAllUp), не работает DoubleClick.
* Не работает TAB.
* Не все задуманое безобразие относительно взаимного расположения рисунка (Glyph)
и текста реализовано.
* Безобразная работа с Glyph (сам Bitmap)
После всего прочтенного наверняка у многих возник вопрос:
"А где это чудо можно закачать?"
Ответ прост:
http:/www.homm86.narod.ru
Огромное спасибо shalex и RA за помощь и тестирование.
ЗЫ Прошу тех, кого не затруднит присылать отзывы и предложения
сюда на фрум (расматриваются даже сообщение типа "а вот сдесь пиксель должен быть
$fffefd, а он $fffefc"), а также небольшой снимок градиентной панели в (!) 16 битах
в формате PNG на мыло вместе с моделью вашей видео карты (тут недавно глюки у одного
человека были, как бы не пришлось все ядро прорисовки переделывать).
--
____________________________________________________________
С уважением,
Карпинский Александр | mailto:homm86@mail.ru
denis111 (2006-02-17 18:47:00) [21]Да, компоненты суперские. Спасибо за них.
А не хочешь ли ещё скроллбар красивый добавить? :) или сразу всякие мемо и тп с красив. скроллами.
а то вот скроллы весь вид портят _ http://keygenmusic.nm.ru/images/modlist.png:)
homm (2006-02-15 22:39:00) [22]
> Молодец! Шикарные контролы,
Серьезно? А я и не заметил ;))
> особенно ToolBar (но НЕ НАСТОЯЩИЙ)!
Во-превых это не тулбар, а набор контролов, похожий на тулбар. ;) Просто мне понадобилось, и я решил включить в демы чтобы показать как еще можно извратится. Во-вторых: А смысл плясать от настоящего? Ради ImageList, функции которого с головой перекрываются ImageCollection?
> Как насчёт других контролов, например EditBox,
GRushEditBox = GRushPanel с дочерним прозрачным EditBox без бордера.
> ComboBox,
GRushComboBox = ComboBox с маленькой GRushButton справа.
> ListBox
Э-э? Про EditBox я уже говорил?
В принципе для них можно сделать и зеркала, и объекты с автоматическим создание всех нужных контролов. Может и будут.
ElDev (2006-02-15 22:11:00) [23]Молодец! Шикарные контролы, особенно ToolBar (но НЕ НАСТОЯЩИЙ)! Как насчёт других контролов, например EditBox, ComboBox, ListBox.
homm (2006-02-14 22:58:00) [24]Сегодняшняя версия юбилейная. По моим подсченям первая публичная версия носила номер 0.25, сегодняшняя 0.35-я, т.е. десятам публичная. Вкусностей просто целый вогон! Размер одних модули GRush (без tinyPictures и демок) составляет 874кб (!) (для справки - в версии 0.34 всего 255кб). Для начала рядовые новости:
[-] Устранена небольшая утечка из-за отсутствия вызова RemoveProp.
[-] Несколько незначительных багов устранено.
MCK:
[*] Исправлена путаница с некоторыми свойствами. В частности ShadowOffset, так что если вдруг пропали надписи на кнопках - возможно в ShadowOffset установлено значение 255.
[-] Несколько незначительных багов устранено.
Вкусность №1
Я решил что всетаки экономия процесорного времени таким путем, который был раньше слишком расточительна по отношению к оперативе. Поэтому теперь любой временый битмап, о котором можно с определенной вероятностью сказать что в ближайшее время он не понядобится, освобождается. Не сказать что это экономит несметные количесва драгоценных байтов оперативы, но с учетом того, что GRush'и итак не много ее ели, это оказалось довольно полезно. Вернутся к старому механизму менеджмента ресурсами можно отключив символ USE_MEMSAVEMODE.
Вкусность №2
Процедура BitmapAntialias4X (кстати, также объявленая в Interface) получила "знания" об MMX инструкциях. Сама она стала быстрее в два раза, но вот что-то скорость прорисовки больших сглаженых круглешков по краям не слишком увеличилась. Видимо "узкое место" в GDI, поэтому введена еще одна процедура BitmapAntialias2X (тоже с MMX) и по умолчанию используется именно двойное сглаживание, если правда объявлен симаол USE_2XAA_INSTEAD_OF_4XAA (а по умолчанию он объявлен).
Вкусность №3
Вот это уже интереснее: при двойном щелчке на TKOLGRyshImageCollection откроется окно редактора компонента. В нем можно открыть картинку, убрать картинку, сохранить картинку(!), УВИДЕТЬ картинку(!). Вот только при сохранении расширене к файлу Вы должны сами дописать, просто Collection не хранит точный тип картинки (ему это не нужно), а хранит только информацию это PNG или нет.
Внимательный коловец заметил, что перечисленые выше добавки едва тянут на 50кб исходного текста, соответственно возникает вопрос: что же за штука такая еще весит порядка 600кб в исходниках? Итак...
Вкусность №4
Для всех стандартных компонентов сделаны редакторы свойств! Открываются они при двойном щелчке на свойстве GRushStyles любого компонента. Описывать их не вижу смысла, разобратся в них не составит труда. Скаже лишь что это точно удобнее чем в Инспекторе свойства перебирать.
Хотелбы отметить что для вкусности №3 и 4 применяется очень свежий подход (по крайней мере я такого не видел еще не у кого). Использовать стандартые кирпичные кнопки мне не хотелось, но и переписывать GRush на VCL тоже желания небыло. Решение нашлось очень простое: Изначально редакторы компонентов - обычные MCK проекты, "препроцеснутые" DIPP'ом и подправленые уже после включения в пакет. Соответственно сами редакторы - коловские формы! Фактически редакторы являются MCK-сгенерироваными KOL формами для зеркальных компонентов коловских отражений выполняюшиеся из VCL Design-time кода. (предидущее предложение одобрено минздравом России как безопасное для здоровья средство уничтожения ламеров ;) )
И на последок небольшой административный вопрос: библиотеку я теперь буду выкладывать в rar, а в *.zip версии ее yflt.cm можно будет взять с небольшой задержкой с http://www.kolnmck.ru
http://www.homm86.narod.ru/grushcontrols.rar
Vladimir Kladov (2006-02-06 15:22:00) [25]Нашел где утечка, будет в обновлении. Только доразбираюсь с Unicode маленько. Если вдруг повезет то сегодня.
homm (2006-02-06 12:22:00) [26]Новости от 6 февраля 2006 г.
GRushControls v0.34
[+] Добавлен новый компонент TKOLGRushImageCollection. У него нет "отражения" в KOLGRushControls.pas, а служит он для загрузки изображений. В связи с этим:
[!] Начиная с этой версии модули библиотеки tinyPictures входят в пакет GRushControls и являются его неотъемлемой частью.
[-] Еще раз "Испрвлена потенциальная ошибка, если присвоить All_GlyphBitmap := nil". В предидущей версии поспешил :)
[*] Немного уменшен размер *.dfm файлов, содержащих GRush контролы.
tinyJPGGIFBMP.pas:
[+] Добавлена процедура
procedure tinyLoadJPGGIFBMPResource(var TargetBitmap: PBitMap; Inst : HInst; ResName : PChar; ResType : PChar);
tinyPNG.pas:
[+] Добавлена функция
function tinyLoadPNGResource(var TargetBitmap: PBitMap; Inst : HInst; ResName : PChar; ResType : PChar): DWORD;
Итак что дает этот TKOLGRushImageCollection, и как им пользоватся? Отражение для этого компонента есть нечто иное как PBitmap. В этот битмап с помощию библиотеки tinyPictures подгружается рисунок из ресурсов, используемый как All_GlyphBitmap для контролов, после чего он благополучно уничтожается. Т.е. не смотря на объявление GRushImageCollection1 в классе формы, доступ в runtime к этому объекту запрещен (к сожалению мной, а не компилятором :) ). Основное свойство - ImageType. По умолчанию оно равно None. Если его изменить, появится диалог открытия файла. При открытии графического файла его тип определится автаматически и занесется в ImageType, а содержимое файла будет полностью загружено в ОП (файла, а не картинки). Для освобождения файла нужно просто выбрать ImageType = None. Содержимое файла полностью хранится в *.dfm файле, и наличие оригинального не требуется.
Каждый контрол теперь имеет свойство imagecollection, связывающее его с определенным TKOLGRushImageCollection. Значения параметров All_GlyphWidth и All_GlyphHeight теперь выставляются по следующей схеме: если TKOLGRushControl.GRushStyle.GlyphWidth не равно нулю, то присваевается это значение, если оно равно нулю, но не равно нулю свойство TKOLGRushImageCollestion.ImageWidth, то присваевается это значение. Если же оба свойства равны нулю, то ничего не присвивается и следовательно All_GlyphWidth становится равным All_GlyphBitmap.Width. Для свойства Height все аналогично.
homm (2006-02-06 12:22:00) [27]Новости от 6 февраля 2006 г.
GRushControls v0.34
[+] Добавлен новый компонент TKOLGRushImageCollection. У него нет "отражения" в KOLGRushControls.pas, а служит он для загрузки изображений. В связи с этим:
[!] Начиная с этой версии модули библиотеки tinyPictures входят в пакет GRushControls и являются его неотъемлемой частью.
[-] Еще раз "Испрвлена потенциальная ошибка, если присвоить All_GlyphBitmap := nil". В предидущей версии поспешил :)
[*] Немного уменшен размер *.dfm файлов, содержащих GRush контролы.
tinyJPGGIFBMP.pas:
[+] Добавлена процедура
procedure tinyLoadJPGGIFBMPResource(var TargetBitmap: PBitMap; Inst : HInst; ResName : PChar; ResType : PChar);
tinyPNG.pas:
[+] Добавлена функция
function tinyLoadPNGResource(var TargetBitmap: PBitMap; Inst : HInst; ResName : PChar; ResType : PChar): DWORD;
Итак что дает этот TKOLGRushImageCollection, и как им пользоватся? Отражение для этого компонента есть нечто иное как PBitmap. В этот битмап с помощию библиотеки tinyPictures подгружается рисунок из ресурсов, используемый как All_GlyphBitmap для контролов, после чего он благополучно уничтожается. Т.е. не смотря на объявление GRushImageCollection1 в классе формы, доступ в runtime к этому объекту запрещен (к сожалению мной, а не компилятором :) ). Основное свойство - ImageType. По умолчанию оно равно None. Если его изменить, появится диалог открытия файла. При открытии графического файла его тип определится автаматически и занесется в ImageType, а содержимое файла будет полностью загружено в ОП (файла, а не картинки). Для освобождения файла нужно просто выбрать ImageType = None. Содержимое файла полностью хранится в *.dfm файле, и наличие оригинального не требуется.
Каждый контрол теперь имеет свойство imagecollection, связывающее его с определенным TKOLGRushImageCollection. Значения параметров All_GlyphWidth и All_GlyphHeight теперь выставляются по следующей схеме: если TKOLGRushControl.GRushStyle.GlyphWidth не равно нулю, то присваевается это значение, если оно равно нулю, но не равно нулю свойство TKOLGRushImageCollestion.ImageWidth, то присваевается это значение. Если же оба свойства равны нулю, то ничего не присвивается и следовательно All_GlyphWidth становится равным All_GlyphBitmap.Width. Для свойства Height все аналогично.
Vladimir Kladov (2006-02-05 21:34:00) [28]Источник утечки WndProcDoEraseBkgnd, но сама утечка происходит в TControl.Destroy, причем только в асм-версии. Завтра надеюсь разобраться.
homm (2006-02-02 13:23:00) [29]Вот посмотри ка сюда:
program Project1;
uses
windows,
messages,
KOL;
begin
Applet := NewForm(nil, '');
Applet.Canvas.Brush;
NewPanel(Applet, esRaised).SetPosition(64, 16).Canvas.Brush;
run(applet);
end.
Канва течет - GRush течет. Без канвы, сам понимаешь никуда. Владимир заметит этот скромный пост - исправит, тогда поговорим.
Ты кстати не знаеш что нужно сделать чтобы MemProf показывал CallStack для каждой ошибки, а то он только адреса выдает.
ЗЫ А чтобы Владимир точно заметил эту ошибку запостите ее ему на мыло.
ElDev (2006-02-02 12:15:00) [30]Запусти MemProf для своего примера. У меня MemProf выдаёт большой список.
homm (2006-02-01 12:45:00) [31]Каих? Ресурсы разные бывают. GDI, User, просто память?
ElDev (2006-02-01 09:01:00) [32]Утечка ресурсов продолжается, особенно после кликов.
homm (2006-01-30 23:50:00) [33]Новости от 31 января 2006 г
GRushControls v0.33
[-] "Устранена" псевдо-утечка рессурсов из-зв псевдо-неуничтожения таймера.
[*] Исправлена неверная работа свойств XXX_GlyphItemX, XXX_GlyphItemY, All_GlyphWidth, All_GlyphHeight.
[*] Для избежания конфликтов в именах многие используемые типы получили приставку GRush (TControlType --> TGRushControlType). В основном это внутрение типы, но есть и использевый как параметр для RecalcRects (TRects --> TGrushRects). Его придется переименовывать во всех объявлениях функций для OnRecalcRects.
[*] Разрядность практически всех свойств приведена к 32 (не думаю что с этим могут быть проблемы).
[+] Добавлены свойства:
All_Spacing : DWORD = растояние между текстом и рисунком (если оба присутствуют на элементе)
All_SplitterDotsCount : DWORD = количество серых точек на Splitter. Впрочем никто не мешает изменять его джля других контролов.
[-] Устранена утечка памяти и GDI ресурсов при уничтожении контрола.
[*] Испрвлена потенциальная ошибка, если присвоить All_GlyphBitmap := nil.
MCK:
[-] Убрана лишняя в некоторых случаях генерация байт-кода для Collapse.
[*] Исправлена генерация байт-кода All_ColorCheck и All_UpdateSpeed для CheckBox для Collapse.
[+] Добавлена генерация кода для свойства All_SplitterDotsCount (для Splitter соотвктственно)
homm (2006-01-15 09:49:00) [34]2 BeZ
Да действительно нет такого свойства TGRushControl.All_Spacing, а в MCK есть. На самом деле fSpacing и у TGRushControl есть и даже используется при расчетах, но нет его в списке глобальных свойств. В следующей версии конечно добавлю, но вот следующая версия боюсь будет не раньше чем через неделю (сессия, да и других дел накопилось).
BeZ (2006-01-11 15:58:00) [35]To Homm
по поводу свойства All_spacing
у меня в проектах, свойство по умолчанию стоит в 5
если данно свойство у какого то компонента изменить, то при компиляции
в unit1_1.inc вываливается шибка
<GRUshControl>.All_Spacing:= 3;
и пишет что All_Spacing undeclarade identifier
кажется еще для каких то свойств такая лабуда была, но назвать щас не могу, не помню... сначала не понимал в чем дело, но если выставить значение свойства в то, что было по умолчанию, то ошибка пропадает, и все копилируется замечательно
конечно, может я что то делаю не правильно, но погляди пожалуста на это в своем проекте (например)
SPeller (2006-01-07 11:07:00) [36]homm © (23.12.05 9:35) [127]
Если у кого другое мнение по этому вопросу, не стесняйтесь, аргументировано доказывайте, все выше изложеное мое ИМХО
Даже если и уничтожаются таймеры сами, то в любом случае хорошим стилем программирования является уничтожение вручную того, что вручную создал.
homm (2006-01-06 22:07:00) [37]Новости от 6 января 2006 г. (с) ;)
GRush Controls v0.32
[+] Добавлено множество символов условной компиляции для уменьшеня кода некоторых проектов. Причем эффект от отключения нескольких символов зачастую больше чем сумма эффектов (в байтах) от отключения каждого по отдельности. По умолчанию включен символ MOSTCOMPATIBILITY, автоматически включающий все остальные. Если хотите отключить какой-либо символ, нужно вначале отключить MOSTCOMPATIBILITY.
[+] Генерация P-кода (байт кода) для системы Collapse обеспечена в полном объеме. Для использования этой возможности нужно объявить ", KOLGRushControls" в файле "CollapseUses.inc" и "GR0O_ = object( TGRushControl ) end;" в "CollapseObjects.inc" (именно такой выход я нашел из сложившейся ситуации - уменьшить имена не свойств, а имя Fake'а для объекта).
[+] Вставил описалова в совместимом с xhelpgen формате. В начале модуля просто каша получилась, без указаной тулзы не прочитать ниче. (Кстати чтобы получить русское описание нужно в ini файле прописать SpecialChar== вместо звездочки).
[+] Теперь свойства XXX_GlyphItemX, XXX_GlyphItemY, All_GlyphWidth, All_GlyphHeight работают так, как я задумывал. Вот небольшой лекбиз на эту тему:
По умолчанию свойства All_GlyphWidth/All_GlyphHeight (при присвоении All_GlyphBitmap битмапа) устанавливаются равными All_GlyphBitmap.Width/All_GlyphBitmap.Height соответственно. Но это не одно и тоже! Свойства All_GlyphWidth/All_GlyphHeight нужы для формирования своеобразной матрици. Из All_GlyphBitmap как бы получается не одно изображение, а таблица иконок высотой и длиной согласно свойствам All_GlyphWidth/All_GlyphHeight. А для каждого состояния прорисовки определены еще два свойства - XXX_GlyphItemX, XXX_GlyphItemY. Они как раз и говорят о том, какой элемент из этой матрици выбрать. Для простоты понимания вот пример: Имеем битмап с тремя иконками 32*32 вряд (т.е. сам битмап имеет размер 96*32). Загружаем его в качестве All_GlyphBitmap (при этом All_GlyphWidth=96 All_GlyphHeight=32), меняем All_GlyphWidth:=32, меняем Down_GlyphItemX:=1 Over_GlyphItemX:=2. Получаем эффект как в деме№88 (все бегом смотреть!). Все это нужно для одной очень интересной вещи: Делаем огромный битмап с иконками для всего приложения! Загружаем его и присваеваем в All_GlyphBitmap по очереди для всех компонентов. При этом битмап не дублируется, а лиш увеличивается счетчик обращений. После этого, вызываем Free для этого бптмапа (что однако не приводит к его уничтожению, но позволяет уничтожить его после уничтожения последнего использующего его контрола автоматически!). Осталось только настроить координаты GlyphItemX/GlyphItemY для виртуальной матрици иконок! что упрощается write-only свойствами All_GlyphItemX/All_GlyphItemY.
Я не удержался и засунул средьненький Gif в дему№88, распоковывает его конечно tinyPictures (см ниже).
Хотел бы сразу сказать о 2-х подставах:
1) В предидущих версиях свойства XXX_GlyphItemX, XXX_GlyphItemY были инициализированы от балды, придется их поправить на нули или нужные значения у контролов, для которых нужно использовать All_GlyphBitmap в уже существующих приложениях.
2) В моем коде нет никаких проверок на выходы значений XXX_GlyphItemX, XXX_GlyphItemY за пределы воображаемой матрици изображений, как нет и проверки на All_GlyphBitmap.Width > All_GlyphWidth при присвоении последней. Не допускайте ошибок, или приверяйте сами.
Рекомендуется версия KOL&MCK+Collapse 2.30 для работы с GRushControls версии 0.32.
Прочие новости:
[*] Обновил tinyPictures. Изменения в tinyJPGGIFBMP.pas: теперь не создается дочерний объект для TBitmap, что положительно сказывается на размере. Изменения в MZLib.pas: убрал проверку на версии, оптимизировал процедуру контрольной суммы (по размеру, есес-но ;) ).
PS Надеюсь все в курсе, что моя реализация прозрачности контролов оффициально утверждена и ободрена и заменила прежнюю начиная с версии 2.28. (это я для тех пишу, кто Readme к предидущей версии читал (если были конечно такие ;) ).
homm (2005-12-23 09:35:00) [38]
> Ritter (19.12.05 21:54) [126]
Таймер не системный объект а лиш привязка к системному объекту (окну). В противном случае не уничтоженый таймер бы продолжал посылать WM_PAINT. Освобождать там нечего, т.к. таймер не создается а устанавливается ( SetTimer).
Я провел вот такой эксперимент:
for i:= 0 to 99999 do beginНажимал долго, используемая память не увеличилась ни на килобайт, процессор в конечном итоге не нагружался. Чего не скажеш о варианте, когда 80 заменил на i. Вот тогда действительно 10000 таймеров создается. Я так понимаю вопрос возник из-за MemProof. Он не считает системные ресурсы, но считает разницу между удачными (возратившими не ноль) вызовами функций создающих (или устанавливающих, как в данном случае) и уничтожающих различные объекты, не вдаваясь в подробности (надо бы еще и TimerID в этом случае смотреть).
SetTimer(GRushButton1.Handle, 80, 50, nil);
end;
Если у кого другое мнение по этому вопросу, не стесняйтесь, аргументировано доказывайте, все выше изложеное мое ИМХО.
> Vladimyr © (12.12.05 20:39) [125]
Как раз это бы и не помагло - раньше был ValidateRect еще на WM_ERASEBKGND. Но оказалось что можно прекрасно и без оного можно обойтись не хуже.
Ritter (2005-12-19 21:54:00) [39]Homm, в GrushControls допущена утечка системных ресурсов:
Таймеры у Вас создаются в процедурах DoXXX и уничтожаются при обработке сообщения WM_Timer после завершения отрисовки. Однако, если SetTimer вызывается из др. процедуры DoXXX еще до того, как была завершена предыдущая отрисовка, то создается _новый_ таймер (несмотря на то что значения nIDEvent совпадают), а предыдущий уже освободить невозможно.
С уважением, Ritter
Vladimyr (2005-12-12 20:39:00) [40]2 homm:
с новой сборкой в W2K глюков не замечено.
Да и вообще глюк не страшный, надо просто добавить
invalidateвForm.OnShow
| |
