| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
GRush Controls
homm © (2005-10-22 16:03:00)Эпиграф:
"Лучшее враг хорошего"
Многие из вас знакомы с котролами 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
homm (2006-08-30 11:19:00) [1]У, брат :)
Тебе и вправду еще копать и копать :)
GRush вообще не при чем, и документация к ним тем более :) Смотри в сторону Border и Margin'ов всяких.
Barloggg (2006-08-30 09:26:00) [2]все, наконец-то осилил твой пример.
интересно что такого есть в нескольких моих группбоксов, что они не отрисовываются вообще при их высоте 16 пикселей.
там их пять штук в ряд лежит, все выровнены по caTop и внутренние три не отображатся... как будто верхнее поле удвоено...
в твоем примере все нормально отображется...
в общем копать мне еще и копать. описаний в исходниках у тебя надо сказать всего ничего.
Кстати а почему внутри твоего Grushpanel между детками выровненными по caTop такие большие пропуски? и чем это регулировать?
homm (2006-08-29 13:07:00) [3]> Если crushpanel при создании имеет высоту = 1 и visible
> = true, то все бабахает.
> Вчера методом деления пополам вычислил тот Groupbox что
> вызывал падение...
Я это уже нашел как-то. Просто сейчас нет желания возится с апдейтом, хотя всяческих исправлений накопилось порядочно. :) В общем вот необходимые исправления для версии 0,35:
сторки
1832: if (W<=0) or (H<=0) then
1833: exit;
- удалить
сроку
1873: if (aBRW>0) and (aBRH>0) and (M>0) and (N>0) then
- изменить.
Barloggg (2006-08-29 09:20:00) [4]Если crushpanel при создании имеет высоту = 1 и visible = true, то все бабахает.
Вчера методом деления пополам вычислил тот Groupbox что вызывал падение...
Barloggg (2006-08-28 10:39:00) [5]насчет "..." я сделал смешнее... по команде от первой прорисовки наращиваю все кнопочки с малыми габаритами до приемлемых габаритов, а также сдвижения их влево на пару пикселей. таких кнопочек оказалось немного, где-то пару тройку десятков.
пример видел, но не понял как именно это сделано.
похоже левое и верхнее поля contextoffset уведены в минус, верно?
сейчас буду экспериментировать. и вышлю код.
homm (2006-07-31 14:27:00) [6]> а в моем проекте под 50 GroupBox'ов. и их тоже хочется...
Пример как его сделать:
http://homm86.narod.ru/grushgroup.rar
Там только один косяк. Если принять для этого ГрупБокса Alig отличный от none то при первой прорисовке он не правильно прорисовывается. поэтому присутствует
procedure TForm1.KOLForm1FormCreate(Sender: PObj);
begin
Form.Height := Form.Height+1;
end;
Твой код, конечно будет интересен, шли. А насчет "..." вопрос уже был. См. например [71] (пункт 2).
homm (2006-07-31 12:56:00) [7]2 Barloggg
Идея с включаемым файлом действительно интересная, тем более что в нем же можно и оформление менять. :) А насчет GroupBox мне кажется был способ. Сейчас поставлю дельфи и посмотрю :)
Barloggg (2006-07-31 10:07:00) [8]В общем в качестве резюме могу подкинуть homm идею создать файлик "быстрого подключения"
просто *.inc файл который вписывается строчкой {$I QuickGrush.inc} и автоматом превращает все контролы в Grush.
без необходимости установки компонентов и возни с ребилдом всего установленного в MCK добра.
а также хочется GrushGroupBox. пусть даже не отдельным компонентом, а хотя бы галочкой GrushPanel.LookLikeGroupbox:=true;
Barloggg (2006-07-31 10:04:00) [9]Однако на этом халява закончилась.
Для того чтобы 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 09:57:00) [10]Хочу поделиться своим опытом.
Имею большое приложение с размером 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.
Панелей у меня в приложении почти нет, так что они лично мне не понадобились, но тоже можно так сделать.
homm (2006-04-09 07:14:00) [11]
> [153] Duber
см [134]. Нельзя разве подробнее написать. Кидаете невнятную строчку, я должен разбиратся что вы имеете ввиду (тем более что у меня временно преоритет сменился с Delphi на PHP).
Duber (2006-04-09 02:01:00) [12]Куча забытых ресурсов по завершении приложения!
homm (2006-04-08 17:49:00) [13]См. пост [139] и демо проекты.
Psychedelic (2006-04-06 09:02:00) [14]В этом наборе есть компонент GRushImageCollection. Он что держит только один рисунок? Или он как Imagelist (судя по названию - collection - вроде да)? Если да, то как добавить несколько битмапов?
NightLord (2006-02-19 21:09:00) [15]Можно сделать в компоненте поддержку нескольких менеджеров.
Например менеджер для "DefColor", для "DefBorder", и.т.д. И один общий.
Когда для определенного свойства менеджер не указан, то используется общий.
denis111 (2006-02-19 20:43:00) [16]да, действительно было б неплохо. это можно даже считать недосмотром борланда:) ведь могли бы сделать как в 3дс максе - копируешь св-во одного объекта, вставляешь в другой, а он спрашивает просто копировать или сделать instance, т. е. меняешь потом св-ва у одного, а у второго автоматически меняются.
Наверное так нереально сделать в делфи иде/вцл:(
homm (2006-02-19 19:58:00) [17]
> У меня есть предложение добавить контрол по управлению настройками
> всех компонентов сразу.
Это отличная идея. Она реализована в 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кб).
Непросто будет написать редактор компонента.
Как следствие полноценная реализация появится ой как не скоро :(
В принципе все реалезуемо, но я пока не спешу начинать. Может есть какие-то предложения, замечания, мысли по этому поводу?
NightLord (2006-02-19 13:01:00) [18]У меня есть предложение добавить контрол по управлению настройками всех компонентов сразу. Т.е. поменял расцветку в контроле, а он автоматически поменял во всех других компанентах, назначеных на управление.
denis111 (2006-02-18 20:25:00) [19]ну вобщем-то есть же альтернативные скроллбары для обычного делфи вцл. например FatScrollBar вроде как рисуется сам _ http://hkdsoft.narod.ru/delphi/files/fatscrollbar.rar. можь можно как-то портировать.
а где это "у вас" ? интересно. а то я чё-то не помню кто это и где спрашивал :))
homm (2006-02-18 17:29:00) [20]
> А не хочешь ли ещё скроллбар красивый добавить? :)
Читал я твою ветку про эту программу, поэтому сразу увидев твое имя в списке последних постивших, понял о чем будет разговор.
Ну во-первых: К тебе не относится, но кое кому бы я там у вас пальцы пообрывал, а то уж больно широко посажены. (цитата: "Ну и где ты эти компоненты взял? На к-а-к-о-м н-и-б-у-д-ь форуме по дельфи?").
Конкретно по скролбарам: Ничего не хочу обещать, но если M$ не накосячила с перерисовкой (как например это присходит в CheckBox) то я посмотрю что можно сделать, и возможно что-то получится. Если же стандартный Скроллбар рисуется как ему угодно, и где угодно то сразу НЕТ. Слишком уж сложнее реализовать данный элемент нежели тот же CheckBox с нуля (хотя у меня был опыт такой реализации в Direct Draw).
| |
Страницы: 