| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / 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
SPeller (2005-11-10 08:20:00) [81]Vladimir Kladov (09.11.05 20:34) [83]
А убирание WS_TABSTOP не помогает?
Vladimir Kladov (2005-11-09 20:34:00) [82]вообще-то если likeSpeedButton кнопку торкнуть мышкой, то она тоже оказывается в фокусе, и ее дальше можно пробелом нажимать. Если только в процедуре OnClick не передать фокус куда-нибудь еще. Причем, это похоже давно - если не всегда - так было. Если кто-то сумеет придумать как исправить, я только за. По мне, лучше бы она вообще фокус не получала (но как тогда она нажиматься будет, даже мышкой?). Хотя бы для bitbtn надо бы что-то придумывать. (Хотя я использование bitbtn не одобряю - проблемы с темами).
mdw (2005-11-09 16:27:00) [83]У кнопки свойство LikeSpeedButton зря убрал, DrawFocusRect все таки не тоже самое. Фокус не рисуется, но реально кнопка его получает и соответственно нажимается (пробелом).
shalex (2005-11-09 12:10:00) [84]1. Иногда не работает autosize, Вы учитываете шрифт (при разных настройках Винды) при определении размера контрола?
2. В win95 (уж так получилось, что прогу пришлось запустить на Pentium I) при стандартных свойствах контролов grushbutton не виден на grushpanel (виден только caption), если grushbutton задизабленный, то все ок. Может какие-то свойства нужно менять?
homm (2005-11-07 13:08:00) [85]
> Для начала, спасибо, что ответил на [75]...
Ты имееш ввиду письмо с ответом на [77] наверное... Лучше все-же херить перекрытие ненужных свойств, чем отказыватся от новых.
> При использовании горизонтального градиента у ProgressBar'а,
> неплохо если бы была возможность выбора, относительно чего
> заливать градиент...
Ну спрашивал ведь уже, и в деме _MCK_ есть. Логика такова - ВСЕ элементы рисуются ОДНОЙ функцией, в зависимости от параметров по умолчанию и ваших. Проверок на ТИП контрола во всем модуле (специально посчитал) четырнадцать, и лиш ОДНА из них в процедуре рисования, и ту наверное уберу! То есть фактически это ОДИН компонент (идеология KOL!). Дополнительные ветвления увеличат сложность, и как следствие размер. Градиент останется один на контрол.
MTsv DN (2005-11-07 12:12:00) [86]2 homm
Привет...
Для начала, спасибо, что ответил на [75]...
И еще предложение... При использовании горизонтального градиента у ProgressBar'а, неплохо если бы была возможность выбора, относительно чего заливать градиент... Относительно заполненого или относительно всего ProgressBar'а...
С Уважением MTsv DN
MTsv DN (2005-11-06 21:37:00) [87]ИТОГ:
Поскольку, я MCK был практически не привязан... Я заменил только KOLGRushControls.pas, удалил MMX.pas, а MCKGRushControls.pas оставил от версии 0.27...
С Уважением MTsv DN
MTsv DN (2005-11-06 20:51:00) [88]Глухо как в танке... Это не вариант...
У меня суммарный объем dfm-файлов 450kB (текстовых)... Число компонентов в районе 100 (если не больше)... Для каждого так редактировать свойства...нереально...
С Уважением MTsv DN
homm (2005-11-06 20:27:00) [89]2 MTsv DN
Все из опыта, могу ошибатся.
Есть два вида *.dfm
1) Бинарные. Если открыть в блокноте - все строки сбиты сверху, куча нечитаемых символов.
2) Текстовые. Открываеш в блокноте, а там ровнинький убористый текст с описанием всех свойств всех контролов.
Если у тебя второй вариант, тебе повезло 1-2 часа монотоной работы и все будет в порядке ;). Если первый то извеняй. (вроде первый умер после D4, но опятьже IMHO).
Собственно что делать...
Ищеш по следующим образцам строки и удалаеш их целиком, не оставляя пустых строк.
Ctl3D
EraseBackground
Brush.
Color
ParentColor
TextAlign
edgeStyle
VerticalAlign
Smooth
ProgressColor
ProgressBkColor
Flat
WordWrap
windowed
LikeSpeedButton
Image
ShowAccelChar
HasBorder
Auto3State
Уф... Вроде ниче не забыл.
ЧЕЛОВЕКИ! Может кто знает другой способ сконвертнуть ???? Может я где налажал (вроде Владимир выбрасывал какие-то свойства, и Ignore All там работал).
Гипотетически можно спроектировать интерфейс заново в новом проекте, после чего претащить *.dfm'ы и немного покрутить, чтоб пристроить к старому, или перекидать код в новый проект. НО понадябится 2 установленые дельфи, с версией 0.27 и 0.28 соответственно, а одну версию делфа на один комп поставить дважды вроде нельзя так что нужны ДВЕ дельфи.
MTsv DN (2005-11-06 19:53:00) [90]2 homm
Не хочу показаться не вежливым...
ЧТО ДЕЛАТЬ С: " Нажимаю Ignore, а он вместо следующего свойства крякозюлины пишет. Итого либо на форме нехватает компонентов, либо Stream Error..." ???????
У меня довольно много компонентов на форме, а при использовании версии 0.28, все заканчивается "Stream Error..." Наверняка надо в ручную править *.dfm файлы, но где?..
С Уважением MTsv DN
homm (2005-11-06 18:03:00) [91]Ну вот и обнавление (v0.28 от 6.11.05).
[-] В MCK часть добалена практически вся необходимая функциональность.
Пока что потерпите без загрузки картинок и события OnRecalcRects.
[-] Вылетал со второй формой в PAS_VERSION. Поправлено как в KOL(v2.20),
так и уменя (с более ранними версиями тоже будет работать).
[*] Функция GetCPUType перенесена в KOLGRushControls.pas и переименована
в CPUisMMX. Остальные проверки убраны.
[-] Если MaxProgress у ProgressBar равен нулю, вылетал. Поправлено.
[+] Максимальное значение для Progress увеличено до больших пределов.
[*] Приставка gsXXX для констант All_UpdateSpeed изменена на usXXX
[*] NewGRushPanel более не принемает второй параметр (Caption). Теперь
его надо задавать как у обычной панели.
TODO:
Сделать событие OnProgress.
Если изменить надпись, контрол не перерисовывается (нужен SetAllNeedUpdate
сразу за изменением надписи).
Сделать свойство WordWrap.
Все MCK свойства свернуты в один пункт - GRushStyles. Многие свойства,
влияющие на внешний вид классов - предшественников (обычных контролов)
но не влияющие на внешний вид GRush убраны.
homm (2005-11-06 11:24:00) [92]
> Vladimir Kladov (06.11.05 11:07) [72]
> Ignore All - не спасает?
> homm © (06.11.05 10:54) [71]
> и лично у меня тупит
Нажимаю Ignore, а он вместо следующего свойства крякозюлины пишет. Итого либо на форме нехватает компонентов, либо Stream Error.
Vladimir Kladov (2005-11-06 11:07:00) [93]Ignore All - не спасает?
homm (2005-11-06 10:54:00) [94]
> 1. При Height кнопки < 21 текст не отображается...
Какой то глюк на моей машине позволил мне думать, что "div 2" можно безболезнено заменить на "shr 1". ЩАС! В результате у мня ОК - у остальных то что ты описал. Исправил.
> 2. При размерах кнопки < 19 (по длине и высоте) не отображается
> рисунок...
> Пробывал bmp 11x11 на кнопку 17х17 - пусто; 18х17 - пусто;
> 19x18 - пусто;
> 19x19 - норма...
Все дело в свойствах, коих куча и ест-но разбиратся ты не стал, а сразу про "БАГ" заговорил. Есть такое св-во All_ContentOffsets, по умолчанию равное
fContentOffsets: (Left: 4;
Top: 4;
Right: -4;
Bottom: -4);
Задай его All_ContentOffsets := MakeRect(-80, -80, 80, 80) и сможеш отображать картины до 160х160.
> 3. Уже упоминалось... Если на GRushPanel использовать GRushButton
> и KOLEdit
> (так эффект заметнее), то появляются блики... Причем не
> только KOLEdit на и
> заголовок окна тоже...
Это не мой глюк. Положи ЛЮБОЙ прозрачный контрол, ЕдитБокс и попробуй передвигать окно за заголовок (отображать содержимое окна при перетаскивании - on).
> При замене MMX.PAS в GRushControls на MMX.PAS (04.11.2005)
> корректировка KOLGRushControls.pas:
> UseMMX := GetCPUType() >= cpuMMX; -> UseMMX := GetCPUType()
> >= [cpuMMX];
А зачем ты его заменяеш? С пакетом идет гарантировано рабочий MMX, не содержащий проверок на не используемые инструкции.
UseMMX := GetCPUType() >= [cpuMMX];?
UseMMX := cpuMMX in GetCPUType();
> 4. При работе с ПрогрессБаром максимальное значение, которое
> смог установить 31270 (или где-то близко)...
Сделаю. А к чему такие большине цифры?
Кроме того проведена очередная ревизия кода (-740 байт). И самое главное MCK! Теперь он не только есть, но и выполняет возложеные на него задачи. При открытии старых проектов будет куча сообщений о не существуещих свойствах и лично у меня тупит. Придется вручную выковыривать из *.dfm все не нужные свойства (ой, не завидую, чесс слово ;) ).
Сейчас все проверю, подкручу и вечером выложу.
MTsv DN (2005-11-04 08:18:00) [95]Привет...
При замене MMX.PAS в GRushControls на MMX.PAS (04.11.2005) корректировка KOLGRushControls.pas:
UseMMX := GetCPUType() >= cpuMMX;->UseMMX := GetCPUType() >= [cpuMMX];
С Уважением MTsv DN
MTsv DN (2005-11-03 16:14:00) [96]2 homm
Привет...
1. При Height кнопки < 21 текст не отображается...
2. При размерах кнопки < 19 (по длине и высоте) не отображается рисунок...
Пробывал bmp 11x11 на кнопку 17х17 - пусто; 18х17 - пусто; 19x18 - пусто;
19x19 - норма...
3. Уже упоминалось... Если на GRushPanel использовать GRushButton и KOLEdit
(так эффект заметнее), то появляются блики... Причем не только KOLEdit на и
заголовок окна тоже...
В дополнение:
4. При работе с ПрогрессБаром максимальное значение, которое смог установить 31270 (или где-то близко)...
С Уважением MTsv DN
Vladimir Kladov (2005-11-03 07:46:00) [97]Margin has an effect only for parent controls, having children aligned (or for the first automatic allocation of these). Margin has no effect for the child control itself and it has no effect for drawing children which already placed on the parent and have coordinates.
Thaddy (2005-11-02 21:18:00) [98]Yes, I know already ;), but for some reason the "zero oriented" Boundsrect doesn't get propagated to the "reference X, Y" oriented Clientrect with a margin of 0. They are one pixel of, not two... And it should be 0! (I think)
I feel this is not correct behaveour, since it does not involve any WM_NCPAINT messages. I will email what I mean in more detail to you personally tommorow.
(I mean I believe size of rect and size of clientrect with a margin of zero (0) should be equal to boundsrect. This is not the case. But you know I can sometimes write something stupid ;) ) This is just to explain the other readers what I am trying.
Thank you for your rapid raction.
Regards,
Thaddy
Vladimir Kladov (2005-11-02 21:02:00) [99]Thaddy, if you change your create paintbox line to following:
PB:=NewpaintBox(Form).SetPosition(20,4);
you immediately should understand what the difference is between ClientRect and BoundsRect. If not, mail me, i'll write more detailed.
Thaddy (2005-11-02 20:14:00) [100]Here's full sourcecode example:
{Program Source>
program Project1;
uses
Kol,
unit1 in 'Unit1.pas';
begin
NewForm1( Form1, nil);
Run(Form1.form);
end.
}
unit unit1;
interface
uses
Windows, Messages, Kol;
type
PForm1=^TForm1;
TForm1=object(Tobj)
Form:pControl;
PB:Pcontrol;
public
procedure PaintBoxPaint(sender:PControl;DC:HDC);
end;
procedure NewForm1( var Result: PForm1; AParent: PControl );
var
Form1:pForm1;
implementation
procedure NewForm1( var Result: PForm1; AParent: PControl );
begin
New(Result,Create);
with Result^ do
begin
Form:= NewForm(AParent,'KOLForm').SetSize(600,400).centeronparent.Tabulate;
Applet:=Form;
Form.Add2AutoFree(Result);
PB:=NewpaintBox(Form);//.SetSize(100,100).centerOnParent;
PB.OnPaint:=PaintBoxPaint;
end;
end;
{$DEFINE BUG} // Undefine to solve bug
{$IFDEF BUG}
procedure TForm1.PaintBoxPaint(sender:PControl; DC:HDC);
begin
sender.margin:=0;
sender.canvas.Brush.color:=clNavy;
sender.canvas.fillrect(sender.boundsrect);
end;
{$ELSE}
procedure TForm1.PaintBoxPaint(sender:PControl; DC:HDC);
var
R:TRect;
begin
sender.margin:=0;
R:=sender.BoundsRect;
InflateRect(R,2,2);
sender.canvas.brush.color:=clNavy;
sender.canvas.fillrect(R);
end;
{$ENDIF}
end.
| |
