GRush Controls

← →
MTsv DN (2005-12-04 18:35) [120]

Привет...

Да-а-а... В [117] я чуть сильно "завернул", извиняюсь...

ИТОГ в [118]. Т.е. в 98ой при "//UseSystemGradient := FALSE;" - высокая производительность, но "косяк" при прорисовке, а при "UseSystemGradient := FALSE;" - низкая производительность, но нормально работает, без "косяков"...

Самим контролам паралельно, возможно стоит даже до 2.21 откатить.
А вот это надо попробывать...

С Уважением MTsv DN

← →
SPeller © (2005-12-04 20:59) [121]

оффтопик:
Наблюдаю за всем этим, и понимаю, чем чревато надеяться на систему :)

← →
homm © (2005-12-10 19:47) [122]

> Vladimyr © (30.11.05 16:46) [102]
>
> Глюки наблюдаются в 2000-й винде.
> Конечно, это не ХР, но и не 98! :)
Поставил сегодня W2K. Сколько ни бился, описаного эффекта на заметил. Может в этой версии прозрачности (третий апдейт как не как) уже и нет такого глюка? Если у вас еще появляется, может дело в SP или чем-то еще (у меня "голая" 2K, из дров только видяха).

← →
MTsv DN © (2005-12-11 10:07) [123]

Привет...

Самим контролам паралельно, возможно стоит даже до 2.21 откатить.
Ты оказался прав... При откате до версии 2.21 и разремаренной строке UseSystemGradient := FALSE; (версия gRush 0.30) все нормально работает... Производительность восстановилась...

Однако, наблюдаются "мерцания" при прорисовке gRush-контролов, т.е. при наведении на контрол, прорисовка не плавная, а в "несколько приемов"... При отведении курсора, тоже самое (GRushSpeed по умолчанию)...

Причем в Windows XP SP2 их можно заметить тоже, конечно, не так "откровенно", как в Windows 98 SE...
Вот проект: http://www.uus4u.com/download/modules/KOLnMCK/gRush/temp2.rar

Использовал:
KOLnMCK 2.21
gRush 0.30 (UseSystemGradient := FALSE;)
Delphi 7
Windows XP SP2 (если надо...видео ATI Radeon 9600 Mobility)

С Уважением MTsv DN

← →
homm © (2005-12-11 14:50) [124]

news on 11.12.05 v0.30.1
Ждал что выйдет v2.23, ждал что Владимир примет решение о внедрении или замене прозрачности. Недождался пока. Исправлена утечка ресурсов в 9x. В архиве обновлена версия прозрачности до последней.

2 MTsv DN
Это глюк KOL!
В #README#RUS#.txt я писал:

> Все эти действия не должны сказатся на работе и размере
> других проектов за исключением 2b), которое благотворно
> сказывается на старом механизме
> прозрачности, но не излечивает его.
Имено этот глюк я и имел ввиду. Почему-то когда я сразу предложил Владимиру убрать строки из WndProcPaint
if fUpdRgn <> 0 then SelectClipRgn( fPaintDC, fUpdRgn );
он намекнул что это по моей просьбе он так удерживает "сестер" от перерисовки, хотя я (где-то месяц назад, когда начались исправления в прозрачности KOLa) говорил только о "племянниках" перерисовывающегося контрола.
Просто поставь мою прозрачность (для любой версии кола) по инструкции из #README#RUS#.txt и пользуйся ей или выполни только пункт 2b) из той-же инструкции если хочеш пользоватся старой прозрачностью (нет ни каких плюсов, ктоме MCK свойств).

ЗЫ Опять DFMы не открываются без хака MCKGRushConrols.pas. Ну нельзя же на столько людей, которые смотрят твой проект не уважать.

← →
Vladimyr © (2005-12-12 20:39) [125]

2 homm:
с новой сборкой в W2K глюков не замечено.
Да и вообще глюк не страшный, надо просто добавить
invalidate в Form.OnShow

← →
Ritter (2005-12-19 21:54) [126]

Homm, в GrushControls допущена утечка системных ресурсов:

Таймеры у Вас создаются в процедурах DoXXX и уничтожаются при обработке сообщения WM_Timer после завершения отрисовки. Однако, если SetTimer вызывается из др. процедуры DoXXX еще до того, как была завершена предыдущая отрисовка, то создается _новый_ таймер (несмотря на то что значения nIDEvent совпадают), а предыдущий уже освободить невозможно.

С уважением, Ritter

← →
homm © (2005-12-23 09:35) [127]

> Ritter (19.12.05 21:54) [126]

Таймер не системный объект а лиш привязка к системному объекту (окну). В противном случае не уничтоженый таймер бы продолжал посылать WM_PAINT. Освобождать там нечего, т.к. таймер не создается а устанавливается (SetTimer).
Я провел вот такой эксперимент:
for i:= 0 to 99999 do begin SetTimer(GRushButton1.Handle, 80, 50, nil); end;Нажимал долго, используемая память не увеличилась ни на килобайт, процессор в конечном итоге не нагружался. Чего не скажеш о варианте, когда 80 заменил на i. Вот тогда действительно 10000 таймеров создается. Я так понимаю вопрос возник из-за MemProof. Он не считает системные ресурсы, но считает разницу между удачными (возратившими не ноль) вызовами функций создающих (или устанавливающих, как в данном случае) и уничтожающих различные объекты, не вдаваясь в подробности (надо бы еще и TimerID в этом случае смотреть).

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

> Vladimyr © (12.12.05 20:39) [125]
Как раз это бы и не помагло - раньше был ValidateRect еще на WM_ERASEBKGND. Но оказалось что можно прекрасно и без оного можно обойтись не хуже.

← →
homm © (2006-01-06 22:07) [128]

Новости от 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 к предидущей версии читал (если были конечно такие ;) ).

← →
SPeller © (2006-01-07 11:07) [129]

homm © (23.12.05 9:35) [127]
Если у кого другое мнение по этому вопросу, не стесняйтесь, аргументировано доказывайте, все выше изложеное мое ИМХО
Даже если и уничтожаются таймеры сами, то в любом случае хорошим стилем программирования является уничтожение вручную того, что вручную создал.

← →
BeZ (2006-01-11 15:58) [130]

To Homm
по поводу свойства All_spacing

у меня в проектах, свойство по умолчанию стоит в 5
если данно свойство у какого то компонента изменить, то при компиляции
в unit1_1.inc вываливается шибка

<GRUshControl>.All_Spacing:= 3;

и пишет что All_Spacing undeclarade identifier
кажется еще для каких то свойств такая лабуда была, но назвать щас не могу, не помню... сначала не понимал в чем дело, но если выставить значение свойства в то, что было по умолчанию, то ошибка пропадает, и все копилируется замечательно

конечно, может я что то делаю не правильно, но погляди пожалуста на это в своем проекте (например)

← →
homm © (2006-01-15 09:49) [131]

2 BeZ
Да действительно нет такого свойства TGRushControl.All_Spacing, а в MCK есть. На самом деле fSpacing и у TGRushControl есть и даже используется при расчетах, но нет его в списке глобальных свойств. В следующей версии конечно добавлю, но вот следующая версия боюсь будет не раньше чем через неделю (сессия, да и других дел накопилось).

← →
homm © (2006-01-30 23:50) [132]

Новости от 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 соотвктственно)

← →
ElDev (2006-02-01 09:01) [133]

Утечка ресурсов продолжается, особенно после кликов.

← →
homm © (2006-02-01 12:45) [134]

Каих? Ресурсы разные бывают. GDI, User, просто память?

← →
ElDev (2006-02-02 12:15) [135]

Запусти MemProf для своего примера. У меня MemProf выдаёт большой список.

← →
homm © (2006-02-02 13:23) [136]

Вот посмотри ка сюда:
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 для каждой ошибки, а то он только адреса выдает.

ЗЫ А чтобы Владимир точно заметил эту ошибку запостите ее ему на мыло.

← →
Vladimir Kladov (2006-02-05 21:34) [137]

Источник утечки WndProcDoEraseBkgnd, но сама утечка происходит в TControl.Destroy, причем только в асм-версии. Завтра надеюсь разобраться.

← →
homm © (2006-02-06 12:22) [138]

Новости от 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) [139]

← →
Vladimir Kladov (2006-02-06 15:22) [140]

Нашел где утечка, будет в обновлении. Только доразбираюсь с Unicode маленько. Если вдруг повезет то сегодня.

← →
homm © (2006-02-14 22:58) [141]

Сегодняшняя версия юбилейная. По моим подсченям первая публичная версия носила номер 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

← →
ElDev (2006-02-15 22:11) [142]

Молодец! Шикарные контролы, особенно ToolBar (но НЕ НАСТОЯЩИЙ)! Как насчёт других контролов, например EditBox, ComboBox, ListBox.

← →
homm © (2006-02-15 22:39) [143]

> Молодец! Шикарные контролы,
Серьезно? А я и не заметил ;))

> особенно ToolBar (но НЕ НАСТОЯЩИЙ)!
Во-превых это не тулбар, а набор контролов, похожий на тулбар. ;) Просто мне понадобилось, и я решил включить в демы чтобы показать как еще можно извратится. Во-вторых: А смысл плясать от настоящего? Ради ImageList, функции которого с головой перекрываются ImageCollection?

> Как насчёт других контролов, например EditBox,
GRushEditBox = GRushPanel с дочерним прозрачным EditBox без бордера.

> ComboBox,
GRushComboBox = ComboBox с маленькой GRushButton справа.

> ListBox
Э-э? Про EditBox я уже говорил?

В принципе для них можно сделать и зеркала, и объекты с автоматическим создание всех нужных контролов. Может и будут.

← →
denis111 (2006-02-17 18:47) [144]

Да, компоненты суперские. Спасибо за них.
А не хочешь ли ещё скроллбар красивый добавить? :) или сразу всякие мемо и тп с красив. скроллами.
а то вот скроллы весь вид портят _http://keygenmusic.nm.ru/images/modlist.png :)

← →
homm © (2006-02-18 17:29) [145]

> А не хочешь ли ещё скроллбар красивый добавить? :)
Читал я твою ветку про эту программу, поэтому сразу увидев твое имя в списке последних постивших, понял о чем будет разговор.

Ну во-первых: К тебе не относится, но кое кому бы я там у вас пальцы пообрывал, а то уж больно широко посажены. (цитата: "Ну и где ты эти компоненты взял? На к-а-к-о-м н-и-б-у-д-ь форуме по дельфи?").

Конкретно по скролбарам: Ничего не хочу обещать, но если M$ не накосячила с перерисовкой (как например это присходит в CheckBox) то я посмотрю что можно сделать, и возможно что-то получится. Если же стандартный Скроллбар рисуется как ему угодно, и где угодно то сразу НЕТ. Слишком уж сложнее реализовать данный элемент нежели тот же CheckBox с нуля (хотя у меня был опыт такой реализации в Direct Draw).

← →
denis111 (2006-02-18 20:25) [146]

ну вобщем-то есть же альтернативные скроллбары для обычного делфи вцл. например FatScrollBar вроде как рисуется сам _http://hkdsoft.narod.ru/delphi/files/fatscrollbar.rar . можь можно как-то портировать.
а где это "у вас" ? интересно. а то я чё-то не помню кто это и где спрашивал :))

← →
NightLord © (2006-02-19 13:01) [147]

У меня есть предложение добавить контрол по управлению настройками всех компонентов сразу. Т.е. поменял расцветку в контроле, а он автоматически поменял во всех других компанентах, назначеных на управление.

← →
homm © (2006-02-19 19:58) [148]

> У меня есть предложение добавить контрол по управлению настройками
> всех компонентов сразу.
Это отличная идея. Она реализована в RB, я сам об этом думал но до сих пор не брался за написание вот по какой причине: В RB свойств не так уж и много. Кроме того, если в RB все свойства так сказать крос-компонентны, то кому в GRush понравится, если свойство скажем BorderRoundWidth/Height станет общим для CheckBox и RadioBox? Они станут неразличимы при отжатом состоянии. То-же самое со стилем градиента. Плоский градиент на панелях после смены градиента в StyleManagerе придется востанавливать вручную. Зачем тогда вообще нужен будет такой менеджер? Тем не менее думаю что такая штука, все-же нужна, т.к. она не только позволит денамически изменять стиль приложения во время исполнения, но и существенно сэкономить код создания окна. Я предлогаю сделать так:

Будет так сказать флаговое свойство у StyleManager, которое будет определять какие имено свойства он применяет при создании или же при ручтом вызове ApplyProperties. Например так:

TGRushProperty = (gpDefColorFrom, gpDefColorTo, gpDefColorOuter, gpDefColorText, gpDefColorShadow, gpDefBorderColor, gpDefBorderRoundWidth, gpDefBorderRoundHeight, gpDefBorderWidth, gpDefGradientStyle, gpDefShadowOffset, gpOverColorFrom, gpOverColorTo, gpOverColorOuter, gpOverColorText, gpOverColorShadow, gpOverBorderColor, gpOverBorderRoundWidth, gpOverBorderRoundHeight, gpOverBorderWidth, gpOverGradientStyle, gpOverShadowOffset, gpDownColorFrom, gpDownColorTo, gpDownColorOuter, gpDownColorText, gpDownColorShadow, gpDownBorderColor, gpDownBorderRoundWidth, gpDownBorderRoundHeight, gpDownBorderWidth, gpDownGradientStyle, gpDownShadowOffset, gpDisColorFrom, gpDisColorTo, gpDisColorOuter, gpDisColorText, gpDisColorShadow, gpDisBorderColor, gpDisBorderRoundWidth, gpDisBorderRoundHeight, gpDisBorderWidth, gpDisGradientStyle, gpDisShadowOffset, gpContentOffsets, gpSplitterDotsCount, gpCheckMetric, gpColorCheck, gpGlyphVAlign, gpGlyphHAlign, gpTextVAlign, gpTextHAlign, gpDrawGlyph, gpDrawText, gpDrawFocusRect, gpDrawProgress, gpDrawProgressRect, gpGlyphAttached, gpCropTopFirst, gpAntiAliasing, gpProgressVertical, gpUpdateSpeed, gpSpacing) TGRushProperties = set of TGRushProperty;
Мда... 63-х битный тип данных. Потянет ли D3?
Конечно можно будет константы сделать типа такого, для удобства работы в RunTime:
gpAllColorFrom: TGRushProperties = [ gpDefColorFrom, gpOverColorFrom, gpDownColorFrom, gpDisColorFrom];

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

Плюсы:
Офигенная гибкость. Особено если всякие вкусности типа Load/SaveSettingsToStream добавить.
Минусы:
Очень много кода получится в методе ApplyProperties (~4..16кб).
Непросто будет написать редактор компонента.
Как следствие полноценная реализация появится ой как не скоро :(

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

← →
denis111 (2006-02-19 20:43) [149]

да, действительно было б неплохо. это можно даже считать недосмотром борланда:) ведь могли бы сделать как в 3дс максе - копируешь св-во одного объекта, вставляешь в другой, а он спрашивает просто копировать или сделать instance, т. е. меняешь потом св-ва у одного, а у второго автоматически меняются.
Наверное так нереально сделать в делфи иде/вцл:(

Можно сделать в компоненте поддержку нескольких менеджеров.
Например менеджер для "DefColor", для "DefBorder", и.т.д. И один общий.
Когда для определенного свойства менеджер не указан, то используется общий.

В этом наборе есть компонент GRushImageCollection. Он что держит только один рисунок? Или он как Imagelist (судя по названию - collection - вроде да)? Если да, то как добавить несколько битмапов?

См. пост [139] и демо проекты.

← →
Duber (2006-04-09 02:01) [153]

Куча забытых ресурсов по завершении приложения!

> [153] Duber

см [134]. Нельзя разве подробнее написать. Кидаете невнятную строчку, я должен разбиратся что вы имеете ввиду (тем более что у меня временно преоритет сменился с Delphi на PHP).

← →
Barloggg (2006-07-31 09:57) [155]

Хочу поделиться своим опытом.
Имею большое приложение с размером dfm файла под мегабайт. то есть компонентов там куча набросана.
и захотелось мне Grush"ей.
Но не буду же я перекликивать мышкой в самом деле.
И вот что я сделал: перекрыл функции создания компонентов!
написал вот это перед фкнкцией создания формы
function NewButton(AParent: PControl; const Caption: KOLString ): PControl; begin if ParamStr(1)<>"" then result:=kol.NewButton(AParent,Caption) else begin result:=NewGrushButton(AParent,Caption); result.Height:=22; end; end;
и вуаля! теперь все кнопочки стали Grush"ными.
Без установки компонентов, без ребилда MCK. легко и просто. Ну, кончено внешний вид особо не понастраиваешь, но это тоже можно сделать. только ручками.
К тому же использование ParamStr(1) позволило сделать эту опцию отключаемой. прелесть!
Так же я поступил с CheckBox и RadioBox. Легко и непринуженно они превратились в GrushCheckBox и GrushRadiobox.
Панелей у меня в приложении почти нет, так что они лично мне не понадобились, но тоже можно так сделать.

← →
Barloggg (2006-07-31 10:04) [156]

Однако на этом халява закончилась.
Для того чтобы KolScrollBar превратить в GrushProgressBar пришлось поработать. Во-первых добавить две дополнительных функции
function NewScrollBar( AParent: PControl; BarSide: TScrollerBar ): PControl; begin if ParamStr(1)<>"" then result:=kol.NewScrollBar(AParent,BarSide) else begin result:=NewGrushProgressBar(AParent); result.OnMouseMove:=form1.GRushProgressBarMouseMove; result.OnMouseDown:=form1.GRushProgressBar1MouseDown; rs:=true; end; end;
а еще поставить флажок rs:=true по которому в первом onPaint произойдет запуск процедуры, которая всем указанным ScrollBar произведет пересчет координат в Grush.
Но тем не менее заработало! правда небольшую неприятность доставило отсутствие в GrushProgressBar аналога SBMin.

ВСЕ! больше я ничего выжать не сумел.
а в моем проекте под 50 GroupBox"ов. и их тоже хочется...
Я конечно понимаю, что GroupBox это просто панель с рамкой, но к рамке прилагается еще и Caption и вот с эти Caption как раз и возникли проблемы.
Во многих GroupBox детки не имеют фиксированого размера и выровнены такими вещами как caTop и caClient.
и они нахально наезжают на этот самый Caption. я даже нашел что-то вроде верхнего поля (ContentOffset) но он сдвигает вниз не только всех деток, но и само Caption.
В общем от GroupBox -> GrushPanel. пришлось отказаться.

← →
Barloggg (2006-07-31 10:07) [157]

В общем в качестве резюме могу подкинуть homm идею создать файлик "быстрого подключения"
просто *.inc файл который вписывается строчкой {$I QuickGrush.inc} и автоматом превращает все контролы в Grush.
без необходимости установки компонентов и возни с ребилдом всего установленного в MCK добра.

а также хочется GrushGroupBox. пусть даже не отдельным компонентом, а хотя бы галочкой GrushPanel.LookLikeGroupbox:=true;

2 Barloggg
Идея с включаемым файлом действительно интересная, тем более что в нем же можно и оформление менять. :) А насчет GroupBox мне кажется был способ. Сейчас поставлю дельфи и посмотрю :)

> а в моем проекте под 50 GroupBox"ов. и их тоже хочется...

Пример как его сделать:
http://homm86.narod.ru/grushgroup.rar

Там только один косяк. Если принять для этого ГрупБокса Alig отличный от none то при первой прорисовке он не правильно прорисовывается. поэтому присутствует
procedure TForm1.KOLForm1FormCreate(Sender: PObj); begin Form.Height := Form.Height+1; end;

Твой код, конечно будет интересен, шли. А насчет "..." вопрос уже был. См. например [71] (пункт 2).

← →
Barloggg (2006-08-28 10:39) [160]

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

пример видел, но не понял как именно это сделано.
похоже левое и верхнее поля contextoffset уведены в минус, верно?
сейчас буду экспериментировать. и вышлю код.

GRush Controls Найти похожие ветки