GRush Controls

← →
homm © (2005-10-22 16:03) [0]

Эпиграф:
"Лучшее враг хорошего"

Многие из вас знакомы с котролами 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 © (2005-10-22 16:50) [1]

Упс...
http://www.homm86.narod.ru

← →
MTsv DN (2005-10-22 17:18) [2]

Привет...
Лично мне, очень понравилось... Работает без глюков (ATI Radeon 9600 Mobility)... Очень перспективные компоненты...
> Из недостатков (читать: еще не дописал)
со всем согласен...

Первое: так и не смог отобразить на кнопке картинку...
Второе: для моих надобностей не хватает Prpgress, ComboBox и UpDown

Пока оставлю RbControls, но буду следить за развитием GRush

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

← →
MTsv DN (2005-10-22 17:21) [3]

P.S. Для Demo"к не хватает RES файлов...

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

← →
ECM © (2005-10-22 17:24) [4]

Совет: Выбрось DCU из архива - толку от них нет, а вес добавляет...:)

← →
MTsv DN (2005-10-22 17:42) [5]

P.S.S. Bitmap отобразил (в MCK), но только "вручную". Через image не получилось...

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

← →
homm © (2005-10-22 18:03) [6]

2 MTsv DN
> Первое: так и не смог отобразить на кнопке картинку...
В демах есть и не раз
Gluph := NewBitMap(0, 0); Gluph.LoadFromResourceName(hInstance, "RAZOR"); Button4.All_GlyphBitmap := Gluph; Gluph.Free;

> Второе: для моих надобностей не хватает Prpgress, ComboBox и UpDown
Помнится в каком-то посте ты (а может не ты?) говорил, что RB кнопку
приклел на ComboBox. Это наверное лучший выход т.к. делать "дорисовку"
не получится (там и темы, и прочие глупости перерисовываются когда хотят),
а самому ComboBox с нуля писать накладно и не экономично (размер ехе).

> P.S. Для Demo"к не хватает RES файлов..
Добавил.

2 ECM
> Совет: Выбрось DCU из архива - толку от них нет, а вес добавляет...:)
Уже знаю. Выкинул.

← →
homm © (2005-10-22 18:04) [7]

2 MTsv DN
Дак
> MCK в проекте начало существование с сегодняшнего дня.
> Ничего кроме создания контролов она делать еще не умеет

← →
MTsv DN (2005-10-22 18:20) [8]

> 2 MTsv DN
> > Первое: так и не смог отобразить на кнопке картинку...
>
> В демах есть и не раз
> Gluph := NewBitMap(0, 0);
> Gluph.LoadFromResourceName(hInstance, "RAZOR");
> Button4.All_GlyphBitmap := Gluph;
> Gluph.Free;

Да... Я уже разобрался...

> > Второе: для моих надобностей не хватает Prpgress, ComboBox
> и UpDown
> Помнится в каком-то посте ты (а может не ты?) говорил, что
> RB кнопку
> приклел на ComboBox. Это наверное лучший выход т.к. делать
> "дорисовку"
> не получится (там и темы, и прочие глупости перерисовываются
> когда хотят),
> а самому ComboBox с нуля писать накладно и не экономично
> (размер ехе).

Да-да...приклеиваю кнопку на комбик... Но прогресса не хватает :о)

> 2 MTsv DN
> Дак
> > MCK в проекте начало существование с сегодняшнего дня.
>
> > Ничего кроме создания контролов она делать еще не умеет

Усек :о)

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

← →
SPeller © (2005-10-22 20:17) [9]

А это... Влодить в архив ЕХЕшник скомпиленной демы можно? А то мне ГЛУБОКО ЛЕНИВО устанавливать компоненты только ради того, чтобы посмотреть на их внешний вид.

← →
SPeller © (2005-10-22 20:27) [10]

Кстати, на сайте ссылочки такае есть у тебя:
file:///F:/HTML/homm86/ets.zip
file:///F:/HTML/homm86/old/ets.055.zip
file:///F:/HTML/homm86/old/ets.075.zip

Поменял бы..

← →
homm © (2005-10-22 21:34) [11]

> А то мне ГЛУБОКО ЛЕНИВО устанавливать компоненты только ради того, чтобы посмотреть на их внешний вид.

4 из 5 дем коловские, ставить ниче не надо, а вид как у RB, только лучше ;)

← →
SPeller © (2005-10-23 06:53) [12]

Это надо ставить компоненты, потом компилять. Неужели сложно готовую ЕХЕшку туда сунуть?

← →
homm © (2005-10-23 08:52) [13]

Кто нибудь объясните человеку, что ставить надо только MCK, а коловские не надо. Тем не менее залил с ехе смотри на здоровье ;)

← →
SPeller © (2005-10-23 09:58) [14]

Да всё я знаю :) Просто вроде как положено скомпиленную дему выкладывать. За ЕХЕшки спасибо :)

← →
fellix (2005-10-23 11:07) [15]

> homm

Мне кажется, SPeller прав. Хоть один демо-EXEшник в пакете должен быть. Обычные законы промоутинга.
Не стоит заставлять пользователя даже компилить - он должен сразу видеть, что получит. К тому же, я так понимаю, это уже третий вариант выложен, а в первом ни одна демка не компилилась без ошибок - приходилось вручную править.
Да еще, при установке пакета лезут warnings & hints (Delphi 5). Лучше бы от них избавиться.
Ну и пока последнее: третий вариант grushcontrols.zip: unexpected end of archive (WinRAR 3.50). Кстати, tinypictures тоже.

← →
ECM © (2005-10-23 14:02) [16]

Наличие EXE-шника в демо уже является правилом (во всяком случае для КОЛ).

> fellix (23.10.05 11:07) [15]
> ...unexpected end of archive ...

Такое бывает если файл недокачан...Скорость скачивания с narod.ru очень "тосклива" - если качать через IE - часто обрывается...:)

← →
Thaddy (2005-10-23 14:26) [17]

Looks good.....
.... but RA/RB ;) controls seem more stable for now.... I had some unexpected difficulties, I will check them out. Maybe my fault.
Both sets are a good thing!

← →
fellix (2005-10-23 15:10) [18]

> ECM © (23.10.05 14:02) [16]

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

← →
ECM © (2005-10-23 16:01) [19]

> Уж если что-то утверждаю, значит уверен

Эх..все бы так...:)

← →
SPeller © (2005-10-23 19:49) [20]

fellix (23.10.05 15:10) [18]
Естественно, качал несколько раз
Я вот, честно говоря, вообще не понимаю проблем с народом :-) Слышу всё, что на народе скорости хреновые, рвётся, лагает и т.п., но сам не замечал. Да, скорость бывает не ахти, но всё всегда качается. Медленно но верно. Эксплорером. :)

← →
homm © (2005-10-23 19:56) [21]

Thaddy > controls seem more stable for now
Сократ персональный 4.1 > элементы управления кажутся более конюшней сейчас
Ой, не могу, "конюшней" ;o))

2 SPeller, ECM, fellix
Развели тут offtopic.

Насчет организации ProgressBar, кому какой подход больше нравится?
1) Задать MaxProgress фиксировано в 100 и не мучится, тогда прямо на контроле выводить N% (в RB так)
2) Оставить пользователю MaxProgress, пусть пользуется, а выводить в попугаях, процент кому надо в Caption дорисуют.
3) Оставить пользователю MaxProgress, пусть пользуется, но выводить M%, пересчитывая попугаев на проценты.

Пока оставлю наверное вариант 2. Пока еще не совсем готово. Завтра выложу обновление.

← →
ECM © (2005-10-23 19:57) [22]

Попробовал запустить под Win98 ... Все демки выпадают по Assert (включил в опциях проекта)

Can not create DIB section, error: 87, Параметр задан неверно. (D:\KOL\kol.pas, line 52280, address $428238)

Вот стек вызовов для DemoProject99:

> + $DC[004281F4]{DEMOPROJECT99.EXE} KOL.TBitmap.GetHandle + $DC
> + $6[004287C2]{DEMOPROJECT99.EXE} KOL.TBitmap.Convert2Mask + $6
> + $50[00427F10]{DEMOPROJECT99.EXE} KOL.TBitmap.StretchDrawTransparent + $50
> + $2D[00427EB5]{DEMOPROJECT99.EXE} KOL.TBitmap.DrawTransparent + $2D
> + $34[0042ABBB]{DEMOPROJECT99.EXE} KOLGRushControls.DrawGRushControlState (Line 1112, "KOLGRushControls.pas" + 133) + $34
> + $4C[004270C4]{DEMOPROJECT99.EXE} KOL.TControl.GetBoundsRect + $4C
> + $26[0042ADAF]{DEMOPROJECT99.EXE} KOLGRushControls.CheckNeedUpdate (Line 1149, "KOLGRushControls.pas" + 3) + $26
> + $19[0042B7CB]{DEMOPROJECT99.EXE} KOLGRushControls.WndProcGRush (Line 1368, "KOLGRushControls.pas" + 129) + $19
> + $2B[00427223]{DEMOPROJECT99.EXE} KOL.TControl.Invalidate + $2B
> + $3[0042B75E]{DEMOPROJECT99.EXE} KOLGRushControls.WndProcGRush (Line 1356, "KOLGRushControls.pas" + 117) + $3
> + $41[00428DCD]{DEMOPROJECT99.EXE} KOL.EnumDynHandlers + $41
> + $D5[00426D11]{DEMOPROJECT99.EXE} KOL.TControl.WndProc + $D5
> + $5C[00426C98]{DEMOPROJECT99.EXE} KOL.TControl.WndProc + $5C
> + $14[00425404]{DEMOPROJECT99.EXE} KOL.CallCtlWndProc + $14
> + $61[00425475]{DEMOPROJECT99.EXE} KOL.WndFunc + $61
> + $18C[00426B90]{DEMOPROJECT99.EXE} KOL.TControl.CreateWindow + $18C
> + $C[004254DC]{DEMOPROJECT99.EXE} KOL.CallTControlCreateWindow + $C
> + $E[004274AE]{DEMOPROJECT99.EXE} KOL.TControl.CreateChildWindows + $E
> + $22[00426A26]{DEMOPROJECT99.EXE} KOL.TControl.CreateWindow + $22
> + $C[004254DC]{DEMOPROJECT99.EXE} KOL.CallTControlCreateWindow + $C
> + $E[004274AE]{DEMOPROJECT99.EXE} KOL.TControl.CreateChildWindows + $E
> + $22[00426A26]{DEMOPROJECT99.EXE} KOL.TControl.CreateWindow + $22
> + $C[004254DC]{DEMOPROJECT99.EXE} KOL.CallTControlCreateWindow + $C
> + $10[004254F4]{DEMOPROJECT99.EXE} KOL.Run + $10
> + $8[0042D062]{DEMOPROJECT99.EXE} DemoProject99.DemoProject99 (Line 148, "D:\KOL\Components\GRush\Demos\DemoProject99.dpr" + 5) + $8

Возможно это ошибка в KOL (2.18) - не разбирался...
Если Assert-ы запретить - запускается, но все картинки "замусорены"...

← →
homm © (2005-10-23 21:40) [23]

У-У как все запущено...

> все картинки "замусорены"
не понимаю как это. Пришлите небольшой кусочек экрана ;)

> D:\KOL\kol.pas, line 52261 - 52272
if Empty then Exit; if fHandle = 0 then begin if fDIBBits <> nil then begin OldBits := fDIBBits; DC0 := GetDC( 0 ); fDIBBits := nil; //fDIBHeader.bmiHeader.biCompression := 0; fHandle := CreateDIBSection( DC0, fDIBHeader^, DIB_RGB_COLORS, fDIBBits, 0, 0 );

Отсюда вроде как вытекает что
1) Empty=false
2) fHandle=0
3) fDIBBits <> nil

То есть попытка создать DIB секцию, хотя
> Line 1112, "KOLGRushControls.pas"
fGlyphBitmap.DrawTransparent(Bitmap.Canvas.Handle, GlyphRect.Left, GlyphRect.Top, Data.fGlyphBitmap.Pixels[0,0]);
где fGlyphBitmap сроду не DIB (по крайней мере мне кажется что LoadFromResourceName не должна DIB возвращать).

Попробуйте в деме строку
Glyph := NewBitmap(0, 0);
Glyph.LoadFromResourceName(hInstance, "ICO1");
заменить
Glyph := NewDIBBitmap(0,0,pf24bit);
Glyph.LoadFromResourceName(hInstance, "ICO1");
и скажите что получится. (по крайней мере в RB так битмап для подгрузки из ресурса создается, и ес-сно DrawTransparent рисуется).

ЗЫ Ой народ вы бы видели эту красотищу (GRushProgressBar)! Пойду еще часок полюбуюсь...

← →
ECM © (2005-10-23 22:54) [24]

> Попробуйте в деме строку
> Glyph := NewBitmap(0, 0);
> заменить
> Glyph := NewDIBBitmap(0,0,pf24bit);

Так не падает, но теперь Glyph выводится без прозрачности - на розовом фоне.

> Пришлите небольшой кусочек экрана

http://ecm-soft.pisem.net/files/ss.zip
NewBitmap.png - первоначальный вариант
NewDIB.png - вариант с NewDIBBitmap

← →
homm © (2005-10-23 23:50) [25]

2 ECM
> Glyph выводится без прозрачности - на розовом фоне.
Ну на самом деле он выводится прозрачным, только прозрачным цветом
становится черный. Почему - надо разбиратся на месте, а место там
где 98 стоит, а у меня не ст... тфу не установлена, так что видимо
придется замять до поры до времени.

2 All World

У меня завтра уже наступило! Так что сливаю новую версию 0.26.

News:
[+] Добавлен компонент GRush Progress Bar. Ура товариши.
[+] Добавлены соответствующие свойства у PGRushControl:
All_DrawProgress - Отрисовка циферок.
All_DrawProgressRect, All_ProgressVertical. Все булины.
[*] Подправлены функции: DeactivateSublings, DoPop, DoPush, DoEnter, DoExit,
а также реакция на сообщения WM_TIMER, WM_PAINT, BM_SETCHECK, BM_GETCHECK и т.д.
[*] Если BorderWidth = 0 то он все равно лез. Исправлено.
[*] ShadowOffset был байт, стал смолинт. Может принимать отрицательные значения.

Параметры от PControl: Progress и MaxProgress актуальны и для GRush Progress Bar.
В MCK все по прежнему плохо.

← →
fellix (2005-10-24 01:48) [26]

> homm © (23.10.05 19:56) [21]
> 2 SPeller, ECM, fellix - Развели тут offtopic.

Offtopic - не offtopic, но файлы по-прежнему не скачиваются.

← →
homm © (2005-10-24 05:16) [27]

2 fellix
Я проверил уже 3 раз. Все качается, распаковывается, запускается. Если у тебя нет, то это только у тебя одного, значит это offtopic. (попробуй уже какой нибудь даунловд менеджер)

← →
homm © (2005-10-24 12:45) [28]

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

← →
ECM © (2005-10-24 17:38) [29]

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

С ума сойти... не знал - не знал...(я про прозрачность)... прямо глаза отрылись... :) (еще с Win 3.0 закрыты были)
...А делать за тебя никому особо и не хотелось...

← →
shalex © (2005-10-24 20:44) [30]

Кажется autosize не работает в RadioBoxе... может еще где-то?

← →
MTsv DN (2005-10-25 15:25) [31]

> Offtopic - не offtopic, но файлы по-прежнему не скачиваются.
Однозначно Offtopic... Если не докачивается возьмите FlashGet или смените броузер... Здесь же компонент обсуждают...

> 2 ECM
> > Glyph выводится без прозрачности - на розовом фоне.
> Ну на самом деле он выводится прозрачным, только прозрачным
> цветом
> становится черный. Почему - надо разбиратся на месте, а
> место там
> где 98 стоит, а у меня не ст... тфу не установлена, так
> что видимо
> придется замять до поры до времени.
Все это полная фигня... Единственное, что не работает в 98 винде, это NewBitmap. Заменяешь его как предложил homm (или так: NewDIBBitmap(0, 0, pfCustom) - разницы нет) и все нормально запускается...

А розовый цвет фона... homm - это твой "косячок", похоже ты в секцию BITMAP файла ico.res засунул ico-шку, она конвертанулась...отсюда и розовый фон... Кто хочет, может посмотреть эту картинку http://www.uus4u.com/download/other/demoproject55_win98.png Специально заменил BITMAP в ico.res.

> Кажется autosize не работает в RadioBoxе... может еще где-то?
autosize не "не работает", а работает некорректно... После autosize увеличьте ширину на 3 пикселя и все...

Думаю для начала... Компонент ОЧЕНЬ даже рабочий...

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

← →
Vladimyr © (2005-10-25 16:06) [32]

А можно убрать прямоугольник по краям Progress Bar (или сделать невидимым) ?
Тогда бы он стал просто овальной сосиской! :)

← →
MTsv DN (2005-10-25 20:24) [33]

> А можно убрать прямоугольник по краям Progress Bar (или сделать невидимым) ?
А лучше сгладить его, как само заполнение...

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

← →
fellix (2005-10-26 01:30) [34]

> MTsv DN (25.10.05 15:25) [31]
> Если не докачивается возьмите FlashGet или смените броузер... Здесь же компонент обсуждают...

Возможно это и оффтопик - пусть модератор решает - но интересно, что бы вы обсуждали, если бы не могли скачать?
Не загружается с трех разных компов через трех разных киевских провайдеров. Автору только и надо, что архив перепаковать (WinRAR"ом исходники плюс 1 demo-exe в 50К помещаются), а вы начинаете о download менеджерах рассуждать. Считаете, что кроме вас все остальные - ламеры? Я за свой базар отвечаю.

← →
nicesc (2005-10-26 06:37) [35]

Ну ё маё! Если не скачивается с народа, то сначала нужно попробовать просто в браузере открыть ссылку на файл.

Вот переложил:
hice.antosha.ru/grushcontrols.zip

← →
DmiSb (2005-10-26 08:00) [36]

Если из основной формы открыть вторую

NewForm2(Form2, Applet);
Form2.Form.ShowModal;

с размещенном на ней любым GRush контролом,
при её закрытии и последующим

Form2.Form.Free;

вылетает RunTime error 216 at 0000DBE1
Закрытие формы без GRush контролов происходит нормально

D5, KOL 2.18

← →
fellix (2005-10-26 10:18) [37]

> nicesc (26.10.05 06:37) [35]

Thanks, it works.

← →
MTsv DN (2005-10-26 11:29) [38]

> вылетает RunTime error 216 at 0000DBE1
> Закрытие формы без GRush контролов происходит нормально

Попробуйте сделать REBUILD для KOLnMCK и GRushControls... Т.к. у меня все в норме, можете посмотреть: http://www.uus4u.com/download/other/aladin.rar

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

← →
DmiSb (2005-10-26 13:33) [39]

2 MTsv DN
Странно.
Когда столкнулся с этой ошибкой, все снес, заново поставил KOL 2.18 и GRushControls, эффект ноль.
А как у вас крейтиться и удалятся форма ?
Если я делаю Form2.Form.Hide то оштбки нет.
Такая же ошибка, если пытаюсь любой GRushControl сделать Free еще до закрытия формы.

← →
DmiSb (2005-10-26 13:33) [40]

2 MTsv DN
Странно.
Когда столкнулся с этой ошибкой, все снес, заново поставил KOL 2.18 и GRushControls, эффект ноль.
А как у вас крейтиться и удалятся форма ?
Если я делаю Form2.Form.Hide то ошибки нет.
Такая же ошибка, если пытаюсь любой GRushControl сделать Free еще до закрытия формы.

← →
MTsv DN (2005-10-26 15:06) [41]

Закачайте еще раз aladin.rar. Там весь проект...

Инфа: Delphi 7 + KOLnMCK 2.18

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

← →
MTsv DN (2005-10-26 15:15) [42]

Если надо без MCK: http://www.uus4u.com/download/other/grush_demo_womck_twoforms.rar

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

← →
homm © (2005-10-27 07:21) [43]

> > А можно убрать прямоугольник по краям Progress Bar (или
> сделать невидимым) ?
> А лучше сгладить его, как само заполнение...

All_DrawProgressRect := false

Скруглить и сгладить? Может для этого частного случая стоит на панель таких же размеров боросить?

← →
homm © (2005-10-27 07:23) [44]

> fellix (26.10.05 01:30) [34]

> Автору только и надо, что архив перепаковать

Как ты думаеш, возможно ли было новую версию выложить, не перепаковывая архива?

← →
homm © (2005-10-27 07:29) [45]

> > Кажется autosize не работает в RadioBoxе... может еще
> где-то?
> autosize не "не работает", а работает некорректно... После
> autosize увеличьте ширину на 3 пикселя и все...

кажется я знаю куда надо копать (ButtonActions). Я в принципе о нем (автосайз) еще и не думал.

← →
fellix (2005-10-27 12:36) [46]

> homm © (27.10.05 07:23) [44]
> ...возможно ли было новую версию выложить, не перепаковывая архива?

Цитирую: "[18] ...предыдущие варианты скачивались нормально".
Кстати, а зачем так сложно - tar + zip ? Используйте WinRAR - размер будет почти вдвое меньше; все только спасибо скажут. (P.S. С tinypictures.zip та же ситуация.)

← →
shalex © (2005-10-27 20:05) [47]

1) Рядом с KOLLabel (на расстоянии примерно 10-15 пикселей) происходит затирание: http://kol.lighthost.ru/1.png
2)
> ЗЫ Прошу тех, кого не затруднит присылать отзывы и предложения
>
> сюда на фрум (расматриваются даже сообщение типа "а вот
> сдесь пиксель должен быть
> $fffefd, а он $fffefc")

Может я придираюсь, но указанные пиксели должны быть либо цветом фона, либо.... http://kol.lighthost.ru/2.png

← →
shalex © (2005-10-27 21:37) [48]

И еще одно предложение-просьба: вместе с версией указывайте дату выпуска, а то не понятно: уже новая версия или еще старая... нужно запоминать номер версии... удобней, когда есть дата.

← →
homm © (2005-10-28 21:41) [49]

> 1) Рядом с KOLLabel (на расстоянии примерно 10-15 пикселей)
> происходит затирание: http://kol.lighthost.ru/1.png

Проект пожалуйста, а то даже примерно не понял о чем ты.

> Может я придираюсь, но указанные пиксели должны быть либо
> цветом фона, либо....

shalex, ты наверное знаеш ответ, но другим будет полезно.

Достаточно сложно срезать подложку и на ней рисовать компонент (и возможно ли вообще?).
1) Следует указать All_ColorOuter := AlignColorTo16Bit($XXXXXX); где $XXXXXX должно быть близко к цвету подложки.
2) Можно отказатся от сглаживания. All_Antialiasing := false;

> fellix (27.10.05 12:36) [46]

1) *.tar.zip это неприрывный *.zip
2) rar принято распространять самораспоковывающимся (+70 кб)
3) У меня нет лицензии на WinRar.
4) У меня нет старого rar (<=2.9), а открывать архивы приходится на машинах именно с ним.
4) Кто-то вопил что RBControls сжатые RAR"ом не скачиваются (блин. кто же это был...)
5) Если я 7zip запакую лично ты мне спасибо скажеш? (с ним размер раза в 3 менше будет наверное)
6) Тебе спросить бельше нечего?
7) Еще пара сообщений с такой чущью и лично я тебя перестану замечать.

← →
homm © (2005-10-29 20:53) [50]

Свойства All_AlphaRect, XXX_BorderRect ( далее - "вышеупомянутые ректы" ;))
пересчитываются при изменении размеров компонента. Чтобы иметь возможность
их изменить я эксплуатировал OnResize, который вызывался сразу после вычисления
вышеупомянутых ректов, но до Invalidate, именно в нем (OnResize) и следовало
изменять вышеупомянутые ректы. Возникали две проблемы.
1) если контрол создается строкой например
ProgressBar2 := PGRushControl(NewGRushProgressBar(Panel4).SetSize(45, 200).SetPosition(12, 40));
ProgressBar2.OnResize := ProgressBar2OnResize;
то приходится еще раз изменять размеры контрола, после присвоения процедуры.
2) В ProgressBar сама полоса и есть BorderRect, и было бы неплохо иметь
возможность его изменить перед отображением.

Найденое решение: (возможно придется чуток подправить сырца, если у кого
используются вышеупомянутые ректы):
Нафиг эти свойства нужны! Вместо этого ввести событие
OnRecalcRects : TOnRecalcRects TOnRecalcRects = procedure( Sender: PGRushControl; var Rects: TRects ) of object; TRects = record DefBorderRect: TRect; OverBorderRect: TRect; DownBorderRect: TRect; DisBorderRect: TRect; AlphaRect: TRect; end;

Итого изменения в версии 0.27 от 29 октября 2005
[-] Отжал целых 800 байт! Все на чистой оптимизации, без потери функциональности ест-сно.
[+] Новое событие OnRecalcRects вызывается всякий раз когда GRush"и сами изменяют бордеры.
[*] Точка на RadioBox стала без острых углов, организовано как у CheckBox.
[*] В скринах 98 были не закрашеные точки бордера. Что-то с этом сделел, но не могу проверить. :(
[*] CommandActions поправил для правильного AutoSize для CheckBox и RadioBox.
[*] В MCK деме показал, как сделать то, что MTsv DN предложил насчет ProgressBar.

2 MTsv DN

> Кто хочет, может посмотреть эту картинку http://www.uus4u.
> com/download/other/demoproject55_win98.png Специально заменил
> BITMAP в ico.res.

Что это, кстати за дешевая подделка? Сей скрин из ХРени. ППКС

← →
MTsv DN (2005-10-30 07:56) [51]

> 2 MTsv DN
>
> > Кто хочет, может посмотреть эту картинку http://www.uus4u.
>
> > com/download/other/demoproject55_win98.png Специально
> заменил
> > BITMAP в ico.res.
>
> Что это, кстати за дешевая подделка? Сей скрин из ХРени.
> ППКС

Привет...
homm, это не подделка, это ЛЕНЬ... Лень было Винду перегружать :) http://www.uus4u.com/download/other/98.jpg - это Винда 98... Поэтому повторюсь... В 98ой работает нормально...

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

← →
homm © (2005-10-30 20:24) [52]

> Из недостатков (читать: еще не дописал):

> * Не работает TAB.

Упс. Оказывается для поддержки этой клавиши не нужно ничего дописывать. У форм и аплетов есть такие процедуры Tabulate и TabulateEx. Просто не знал.

← →
DmiSb (2005-10-31 06:55) [53]

Не, все равно не хочет вторая форма нормально удаляться [36]
Не знаю как в 7 Дельфе, но в 5-ой - ошибка
И никакие REBUILD не помогают
Сегодня скачал КОЛ 2.19 и последний GRush.
Поставил только эти два пакета - ошибка не пообеждается

← →
homm © (2005-10-31 07:39) [54]

Вылетает если PAS_VERSION. Надо было с этого начинать. Буду смотреть...

← →
nicesc (2005-11-01 09:15) [55]

Народ, подскажите как в 7ку её перегнать

← →
nicesc (2005-11-01 09:18) [56]

Всё разобрался, нужно было удалить system.pas/dcu

← →
nicesc (2005-11-01 10:15) [57]

Если положить стандартныйконтр на GRushPanel то при наведении курсора на кнопку GRushButton возникает эффект мерцания, и если бежит прогресс бар создается эффект мерцания

← →
NightLord © (2005-11-01 19:52) [58]

> nicesc (01.11.05 09:15) [55]
> Народ, подскажите как в 7ку её перегнать
>
> Всё разобрался, нужно было удалить system.pas/dcu

В каком смысле удалить? И что помагло? Мне тож надо в 7-мую =(

← →
MTsv DN (2005-11-01 20:39) [59]

> В каком смысле удалить? И что помагло? Мне тож надо в 7-
> мую =(

Ничего удалять не надо...
Просто берешь файл: GRushControls_D6.dpk, переименновываешь его в GRushControls_D7.dpk... И в GRushControls_D7.dpk все _D6 заменяешь на _D7... и ВСЕ...

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

← →
NightLord © (2005-11-02 00:35) [60]

Спасибо все работает. У меня вот еще вопрос можно ли сделать так чтобы кнопки не выделялись пунктирной линией?

← →
MTsv DN (2005-11-02 07:11) [61]

> Спасибо все работает. У меня вот еще вопрос можно ли сделать
> так чтобы кнопки не выделялись пунктирной линией?

Для каждой кнопки: GRushButton1.All_DrawFocusRect := false;

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

← →
homm © (2005-11-02 10:58) [62]

homm © (31.10.05 07:39) [54]
Разобрался. В функции WndProcGRush добавь третьей строкой
if Data = nil then exit;
Щас нет возможности обновить.

← →
MTsv DN (2005-11-02 14:00) [63]

2 homm
Привет...
Появились некоторые замечания:
1. При Height кнопки < 21 текст не отображается...
2. При размерах кнопки < 19 (по длине и высоте) не отображается рисунок...
Пробывал bmp 11x11 на кнопку 17х17 - пусто; 18х17 - пусто; 19x18 - пусто;
19x19 - норма...
3. Уже упоминалось... Если на GRushPanel использовать GRushButton и KOLEdit
(так эффект заметнее), то появляются блики... Причем не только KOLEdit на и
заголовок окна тоже...

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

← →
Thaddy (2005-11-02 20:01) [64]

<CITATION>
3. Уже упоминалось... Если на GRushPanel использовать GRushButton и KOLEdit
(так эффект заметнее), то появляются блики... Причем не только KOLEdit на и
заголовок окна тоже...
</CITATION>

This seems to be a bug in KOL: Boundsrect is always two pixels short X and Y direction.
Boundsrect should be exactly the bounding rectangle, inclusing everything, of a control. Since sometime now, it isn"t anymore.

Try a Paintbox with the following OnPaint routine:
procedure PaintBoxPaint(sender:PControl; DC:HDC); begin sender.margin:=0; sender.canvas.brush.color:=clNavy; sender.canvas.fillrect(sender.boundsrect); end;

This only works properly like this:

procedure PaintBoxPaint(sender:PControl; DC:HDC); var R:TRect; begin sender.margin:=0; R:=sender.BoudsRect; InflateRect(R,2,2); sender.canvas.brush.color:=clNavy; sender.canvas.fillrect(R); end;

And as such I consider this a bug in KOL, not in GRush Controls, because it happens also in other controls.

Maybe somebody can explain this behaveour?

Regards,

Thaddy

← →
Thaddy (2005-11-02 20:14) [65]

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.

← →
Vladimir Kladov (2005-11-02 21:02) [66]

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 21:18) [67]

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-03 07:46) [68]

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.

← →
MTsv DN (2005-11-03 16:14) [69]

2 homm
Привет...
1. При Height кнопки < 21 текст не отображается...
2. При размерах кнопки < 19 (по длине и высоте) не отображается рисунок...
Пробывал bmp 11x11 на кнопку 17х17 - пусто; 18х17 - пусто; 19x18 - пусто;
19x19 - норма...
3. Уже упоминалось... Если на GRushPanel использовать GRushButton и KOLEdit
(так эффект заметнее), то появляются блики... Причем не только KOLEdit на и
заголовок окна тоже...
В дополнение:
4. При работе с ПрогрессБаром максимальное значение, которое смог установить 31270 (или где-то близко)...

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

← →
MTsv DN (2005-11-04 08:18) [70]

Привет...

При замене MMX.PAS в GRushControls на MMX.PAS (04.11.2005) корректировка KOLGRushControls.pas:
UseMMX := GetCPUType() >= cpuMMX; -> UseMMX := GetCPUType() >= [cpuMMX];

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

← →
homm © (2005-11-06 10:54) [71]

> 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 все не нужные свойства (ой, не завидую, чесс слово ;) ).

Сейчас все проверю, подкручу и вечером выложу.

← →
Vladimir Kladov (2005-11-06 11:07) [72]

Ignore All - не спасает?

← →
homm © (2005-11-06 11:24) [73]

> Vladimir Kladov (06.11.05 11:07) [72]

> Ignore All - не спасает?

> homm © (06.11.05 10:54) [71]
> и лично у меня тупит
Нажимаю Ignore, а он вместо следующего свойства крякозюлины пишет. Итого либо на форме нехватает компонентов, либо Stream Error.

← →
homm © (2005-11-06 18:03) [74]

Ну вот и обнавление (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 убраны.

← →
MTsv DN (2005-11-06 19:53) [75]

2 homm
Не хочу показаться не вежливым...
ЧТО ДЕЛАТЬ С: "Нажимаю Ignore, а он вместо следующего свойства крякозюлины пишет. Итого либо на форме нехватает компонентов, либо Stream Error..." ???????

У меня довольно много компонентов на форме, а при использовании версии 0.28, все заканчивается "Stream Error..." Наверняка надо в ручную править *.dfm файлы, но где?..

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

← →
homm © (2005-11-06 20:27) [76]

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 20:51) [77]

Глухо как в танке... Это не вариант...
У меня суммарный объем dfm-файлов 450kB (текстовых)... Число компонентов в районе 100 (если не больше)... Для каждого так редактировать свойства...нереально...

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

← →
MTsv DN (2005-11-06 21:37) [78]

ИТОГ:
Поскольку, я MCK был практически не привязан... Я заменил только KOLGRushControls.pas, удалил MMX.pas, а MCKGRushControls.pas оставил от версии 0.27...

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

← →
MTsv DN (2005-11-07 12:12) [79]

2 homm
Привет...
Для начала, спасибо, что ответил на [75]...
И еще предложение... При использовании горизонтального градиента у ProgressBar"а, неплохо если бы была возможность выбора, относительно чего заливать градиент... Относительно заполненого или относительно всего ProgressBar"а...

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

← →
homm © (2005-11-07 13:08) [80]

> Для начала, спасибо, что ответил на [75]...
Ты имееш ввиду письмо с ответом на [77] наверное... Лучше все-же херить перекрытие ненужных свойств, чем отказыватся от новых.

> При использовании горизонтального градиента у ProgressBar"а,
> неплохо если бы была возможность выбора, относительно чего
> заливать градиент...
Ну спрашивал ведь уже, и в деме _MCK_ есть. Логика такова - ВСЕ элементы рисуются ОДНОЙ функцией, в зависимости от параметров по умолчанию и ваших. Проверок на ТИП контрола во всем модуле (специально посчитал) четырнадцать, и лиш ОДНА из них в процедуре рисования, и ту наверное уберу! То есть фактически это ОДИН компонент (идеология KOL!). Дополнительные ветвления увеличат сложность, и как следствие размер. Градиент останется один на контрол.

← →
shalex © (2005-11-09 12:10) [81]

1. Иногда не работает autosize, Вы учитываете шрифт (при разных настройках Винды) при определении размера контрола?

2. В win95 (уж так получилось, что прогу пришлось запустить на Pentium I) при стандартных свойствах контролов grushbutton не виден на grushpanel (виден только caption), если grushbutton задизабленный, то все ок. Может какие-то свойства нужно менять?

← →
mdw © (2005-11-09 16:27) [82]

У кнопки свойство LikeSpeedButton зря убрал, DrawFocusRect все таки не тоже самое. Фокус не рисуется, но реально кнопка его получает и соответственно нажимается (пробелом).

← →
Vladimir Kladov (2005-11-09 20:34) [83]

вообще-то если likeSpeedButton кнопку торкнуть мышкой, то она тоже оказывается в фокусе, и ее дальше можно пробелом нажимать. Если только в процедуре OnClick не передать фокус куда-нибудь еще. Причем, это похоже давно - если не всегда - так было. Если кто-то сумеет придумать как исправить, я только за. По мне, лучше бы она вообще фокус не получала (но как тогда она нажиматься будет, даже мышкой?). Хотя бы для bitbtn надо бы что-то придумывать. (Хотя я использование bitbtn не одобряю - проблемы с темами).

← →
SPeller © (2005-11-10 08:20) [84]

Vladimir Kladov (09.11.05 20:34) [83]
А убирание WS_TABSTOP не помогает?

← →
GMax (2005-11-10 13:19) [85]

2 Vladimir Kladov:
насчёт bitbtn.
а как бы тогда получить кнопку одновременно с текстом и иконкой ?
в MSDN вроде такие нарисованы (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/buttons/usingbuttons.asp),

но по крайней мере в KOL при присвоении иконки текст пропадает.

← →
Vladimir Kladov (2005-11-10 20:10) [86]

LikeSpeedButton через убирание стиля WS_TABSTOP как раз и сделан. Но у Windows есть свое мнение по поводу оконного класса "BUTTON", если нажать мышкой, то фокус все-таки за ним (вроде так получается). Можно попробовать сделать BitBtn на другом классе, например, Static.

Кнопка с картинкой сделана через стиль. Может другое сочетание стилей надо. Какое - не знаю.

← →
SPeller © (2005-11-11 06:00) [87]

Тогда надо проверить приход события WM_SETFOCUS, и если приходит, то отлавливать его..?

← →
Vladimir Kladov (2005-11-11 11:06) [88]

он отлавливается, но если его запретить (кстати единственный правильный вариант тогда - отдать фокус обратно), то нажатие есть, а визуально кнопка не нажимается. Можно по отжатию фокус возвращать, тогда в приходе фокуса надо запоминать окно, от которого фокус. А если это окно не нашего приложения - как быть?

← →
SPeller © (2005-11-11 13:05) [89]

Мнда... Тогда проще будет рисовать самому, по всей видимости.

← →
homm © (2005-11-11 23:23) [90]

> 1. Иногда не работает autosize, Вы учитываете шрифт (при
> разных настройках Винды) при определении размера контрола?
>
Шрифт учитывает KOL. AUTOSIZE счисается для стандартных shadowoffsets, может ты их измняеш?

> 2. В win95 (уж так получилось, что прогу пришлось запустить
> на Pentium I) при стандартных свойствах контролов grushbutton
> не виден на grushpanel (виден только caption), если grushbutton
> задизабленный, то все ок. Может какие-то свойства нужно
> менять?
http://delphimaster.net/view/11-1127191462/

← →
Vladimir Kladov (2005-11-11 23:33) [91]

В 2.22 исправлено же вроде?

← →
homm © (2005-11-13 18:11) [92]

news v0.29 от 13.11.05
[*] Исправлены зеркала, особено для сплиттера и прогрессбара.
[-] Дико извеняюсь, но я в прошлой версии забыл убрать Vertical у ProgressBar.
[+] Событие OnProgressChange;
[+] События OnProgressChange, OnRecalcRects можно теперь в зеркале делать.

Прозрачность в KOL пока в подвешаном состоянии, если нужна - испльзуйте 2.21.

← →
MTsv DN (2005-11-21 11:20) [93]

Привет...
Огромная просьба... Если возможно, добавить для ПрогрессБара свойство "обратного заполнения", т.е. справа налево и сверху вниз (в зависимости от Vertical)...

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

← →
homm © (2005-11-21 12:48) [94]

> MTsv DN (21.11.05 11:20) [93]

Вот тут тебе и пригодится перехват OnRecalcRects.
procedure TForm1.GRushProgressBar2RecalcRects(Sender: PGRushControl; var Rects: TRects); var W: integer; begin with Rects.DefBorderRect do begin W := Right - Left; Left := Sender.Width - W; Right := Left + W end; end;

Мысли шире ;)

← →
MTsv DN (2005-11-21 13:17) [95]

О-о-о... :)
Сенкс....

← →
homm © (2005-11-25 18:25) [96]

news v0.30 от 25.11.05

[*] Очень мне не нравятся дела в KOL с функцией DrawTransparent и я решил использовать системную TransparentBlt там, где это возможно. Если будут проблемы типа "в 9х прозрачность не работает, в ХРени все ОК" то это к Владимиру
[*] Наконец-то контролы стали чичтить за собой мусор при уничтожении. Теперь используется CustomObj вмест CustomData
[*] При изменении Caption больше не нужно вызывать SetAllNeedUpdate, теперь он вызывается автоматически
[*] Оптимизированы конструкторы, вынесен общий код
[*] Теперь используется OnPaint вместо перехвата WM_PAINT. Это будет экономить немного кода, если в проекте уже используется OnPaint. Если нет, то немного кода будет экономить директива GRUSH_OLD_PAINT

Убедительная просьба
Прочтите ReadMe прежде чем пользоватся.
Кстати с этой версией идет отличный бонус (какой - в Readme).

← →
Vladimyr © (2005-11-28 16:40) [97]

В демах из последней версии архива наблюдается интересный глюк:

при первом запуске программы иногда не прорисовывается кусок формы (одна из панелей), там остаётся кусок экрана, который был раньше.
Если провести мышью над этим куском, то он прорисовывается и дальше работает нормально.

Глюк был замечен в DemoProject55.exe и Aladin.exe.

← →
MTsv DN (2005-11-29 09:46) [98]

> В демах из последней версии архива наблюдается интересный глюк:

> при первом запуске программы иногда не прорисовывается кусок формы (одна из панелей), там остаётся кусок экрана, который был раньше.
> Если провести мышью над этим куском, то он прорисовывается и дальше работает нормально.

> Глюк был замечен в DemoProject55.exe и Aladin.exe.
А Вы обновили KOL до версии 2.22+ или хотя бы прочитали файл #README#RUS#.txt. У меня такого не наблюдается...

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

← →
Vladimyr © (2005-11-29 22:42) [99]

Я не обновлял KOL. Я взял готовые exe-шники из архива :)

← →
MTsv DN (2005-11-30 09:43) [100]

Привет...

Я не обновлял KOL. Я взял готовые exe-шники из архива :)
А Windows какая?

На сайте у homm86"a есть патч, который обновляет файл KOL.PAS до версии 2.22+. Все нормально работает......НО ТОЛЬКО В WINDOWS ХР

2 homm86
Оговорюсь сразу - Я ПРОЧИТАЛ: Если будут проблемы типа "в 9х прозрачность не работает, в ХРени все ОК" то это к Владимиру.
Но при обновлении до 2.22+ и gRush 0.30, я в Windows 98 ожидал, в крайнем случае, неправильную "прозрачность". Однако, Windows 98 зависла, а затем аварийно завершилась...без каких-либо последующих проблем, но все же... Сейчас попытаюсь создать минимальный проект, как сделал отпишусь...

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

← →
MTsv DN (2005-11-30 11:37) [101]

Привет...

Вот обещанный проект:
исходники (9 kB) : http://www.uus4u.com/download/modules/KOLnMCK/demo_src.zip
exe&comments (95 kB): http://www.uus4u.com/download/modules/KOLnMCK/demo_exe.zip

Все комментарии в demo_exe.zip.
УБЕДИТЕЛЬНАЯ ПРОСЬБА. КТО ЕЩЕ МОЖЕТ ПРОТЕСТИРОВАТЬ НА WINDOWS 98, СДЕЛАЙТЕ ЭТО. ОПИСАНИЕ ТЕСТА В demo_exe.zip

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

← →
Vladimyr © (2005-11-30 16:46) [102]

Глюки наблюдаются в 2000-й винде.
Конечно, это не ХР, но и не 98! :)

← →
homm © (2005-12-01 10:22) [103]

Мельком глянул (дома буду только в воскресенье).

2 Vladimyr
В универе под 2000 (что то возле селерон 400) все работает (с сайта скачал, не с собой принес если что). Вы говорите в некоторых случаях? может стоит раскрыть?

2 MTsv DN

> Оговорюсь сразу - Я ПРОЧИТАЛ: Если будут проблемы типа "в
> 9х прозрачность не работает, в ХРени все ОК" то это к Владимиру.
Это не отричение от всех проблем прозрачности, это действительно только про DrawTransparent.

У тебя в деме стоит Transparent=TRUE, а у меня в демах прописано
OnFormCreate...
homm_altTransparent := TRUE.

Это и есть основное отличие старого механизма от нового. Он задается новой функцией (я то думал это сразу бросится в глаза).

Все это безобразие в демах тоже появляется (вылет винды)?

← →
Vladimyr © (2005-12-01 19:28) [104]

2 homm :
да нечего, собственно, раскрывать...
глюк то проявится, то нет (чаще нет)
системы никакой не заметил

← →
MTsv DN (2005-12-02 09:29) [105]

Привет...
У тебя в деме стоит Transparent=TRUE, а у меня в демах прописано
OnFormCreate...
homm_altTransparent := TRUE.

Это и есть основное отличие старого механизма от нового. Он задается новой функцией (я то думал это сразу бросится в глаза).
Протестил...
Вот ссылка на ехе-шники: http://www.uus4u.com/download/modules/KOLnMCK/demo_with_hommTransparent.rar
А проект тот же, только сначала установил homm_altTransparent := TRUE для всех gRush компонентов, а затем вообще для всех (Естесссссно, Transparent установил в FALSE) ... Эффект хреновый... Неправильно прорисовывается сразу, причем все компоненты... Компилировал под Windows 98SE, Delphi 7.

Все это безобразие в демах тоже появляется (вылет винды)?
В демах "безобразие" не проявляется, т.к. в демах я не нагружал окно (т.е. кнопку вниз в демах не надо жать и окно там из-за этого столько не прорисовывается). А вылет Винды был только раз, чаще все ограничивалось зависом системы и кнопкой Reset...

С Уваженим MTsv DN

← →
homm © (2005-12-03 19:28) [106]

р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р!
Щас буду ругать. Сильно!
1) Я же попросил НЕ ИСПОЛЬЗОВАТЬ старый версии зеркал в новых проектах.
2) Как по твоему вместе уживутся DoubleBuffered и homm_altDoubleBuffered.
3) Щас ты скажеш что не использовали homm_altDoubleBuffered. У меня, как и у Владимира прозрачность держится имено на нем.

Надо же сначала чуть чуть попытатся понять с чем имееш дело, перед тем как дурацкие демы стряпать.

Если в 9х действительно есть глюки, то пиши конечно.

что-то кстати твоя дема 5 сек грузится Begin/EndUpdate не спасают.

http://www.homm86.narod.ru/files/qqqq.rar

← →
MTsv DN (2005-12-03 20:32) [107]

Привет...

Надо же сначала чуть чуть попытатся понять с чем имееш дело, перед тем как дурацкие демы стряпать.
Для начала замечу, что !!! ЭТУ ТЕМУ СОЗДАЛ ТЫ !!! И вот это: "ЗЫ Прошу тех, кого не затруднит присылать отзывы и предложения
сюда на фрум (расматриваются даже сообщение типа "а вот сдесь пиксель должен быть
$fffefd, а он $fffefc")" - ТВОИ СЛОВА !!! И Я НИГДЕ НЕ ГОВОРИЛ, ЧТО ЭКСПЕРТ В ГРАФИКЕ !!!
Надеюсь перебранка окончена...

3) Щас ты скажеш что не использовали homm_altDoubleBuffered. У меня, как и у Владимира прозрачность держится имено на нем.
Специально проверил... Все равно не работает... Как без homm_altDoubleBuffered неправильно прорисовывалось, так и с ним тоже...

5 сек грузится
Естессссно, я же добавляю в цикле 1000 элементов в дерево... Ты demo-проект то скачивал?..

1) Я же попросил НЕ ИСПОЛЬЗОВАТЬ старый версии зеркал в новых проектах.
Этот проект "с нуля"...и версия gRush была сразу поставлена 0.30 (соответственно и KOL 2.22+), т.к. я в Windows 98 не программирую, я в ней тестирую свой проект. И когда при тесте проекта, у меня начались косяки, пришлось искать в чем дело...

ИТОГ:
1. При использовании gRush 0.30 ни Transparent, ни homm_altTransparent (homm_altDoubleBuffered), У МЕНЯ не заработало... При "нагрузке" на приложение (имеется в виду прорисовка) наблюдаются "глюки"...
2. При отключении и Transparent, и homm_altTransparent все в норме...

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

← →
homm © (2005-12-03 21:29) [108]

Ты же DoubleBuffered у правого TreeView включил. Или отпиратся будеш?
То ести ТЫ включаеш старый механизм вместе с новым.

Потом ты
http://www.homm86.narod.ru/files/qqqq.rar
посмотрел? Она тоже чтоли глючит?

> 5 сек грузится
> Естессссно, я же добавляю в цикле 1000 элементов в дерево.
> ..
Да нет, не естественно...

> ТВОИ СЛОВА !!! И Я НИГДЕ НЕ ГОВОРИЛ, ЧТО ЭКСПЕРТ В ГРАФИКЕ
> !!!
Причем сдесь эксперт? Демы для того и созданы чтобы смотреть как пользоватся той или иной системой (концепцией, компонентом), а ты в лоб всегда начинаеш пользоватся, так как привык, а не так как надо.

> 1) Я же попросил НЕ ИСПОЛЬЗОВАТЬ старый версии зеркал в
> новых проектах.
А это насчет не существующих свойств.

> 1. При использовании gRush 0.30 ни Transparent, ни homm_altTransparent
> (homm_altDoubleBuffered), У МЕНЯ ...
Дак о чем и реч...

Ладно, вроде с этим разобрались...
Тем временем исправил чуть-чуть прозрачность, кстати проект MTsv DN тоже в этом помог :)
качать :
http://www.homm86.narod.ru/files/kol222p.zip
В ГРаше старая лежит!

← →
MTsv DN (2005-12-03 22:13) [109]

Привет...

2 homm
Твой вариант работает как нормально, но это не совсем, то что я выложил я на сайт...

Вот твой код:
..... end; TreeView1.EndUpdate; TreeView1.homm_altDoubleBuffered := TRUE; ListBox1.homm_altTransparent := TRUE; end;
и все Transparent"ы := false. Все работает...

А ты попробуй вот так:
...... end; TreeView1.EndUpdate; TreeView1.homm_altDoubleBuffered := TRUE; ListBox1.homm_altTransparent := TRUE; TreeView1.homm_altTransparent := TRUE; ListBox1.homm_altDoubleBuffered := TRUE; GRushPanel1.homm_altDoubleBuffered := TRUE; GRushPanel1.homm_altTransparent := TRUE; GRushPanel2.homm_altTransparent := TRUE; GRushPanel2.homm_altDoubleBuffered := TRUE; end;
и все Transparent"ы := false. У панелей homm_altTransparent включи...У МЕНЯ КОСЯЧИТ...И с последним kol222p.zip (и даже homm_ED_altTransparent попробывал. Кстати, что такой ED?)... Если ты спросишь на фиг я у панелей вкл. прозрачность, то я отвечу: черные уголки у панелей достают, а при вкл. прозрачности их нет...

P.S. Не подумай, что я выпендриваюсь или пытаюсь тебя достать... Просто ты сам просил присылать отзывы и предложения...

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

← →
homm © (2005-12-03 22:49) [110]

Ну наконец-то пошел конструктивный разговор ;)

> Кстати, что такой ED?
Прозрачность EditBox и Memo. В оригенавле ED_Transparent тоже есть.

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

Твой пример работает без проблем.

Делал в таком порядке:
Опубликовал qqqq
Сделел прозрачные панели, увидел что не работет,
Исправил так, что у меня все работает
Выложил новый kol222p.zip

Тебе сделать в таком порядке:
Убедится сто ты поставил kol222p.zip верно
Сделай ребилд (на всякий)
Все-таки рассказать, что за косяки.
Проверить в XP (если счас есть возможность).

← →
MTsv DN (2005-12-04 09:47) [111]

Привет...

Значится так:
>Тебе сделать в таком порядке:
Убедится сто ты поставил kol222p.zip верно
Сделай ребилд (на всякий)
Установился правильно. Ребилд сделал. Размер KOL.PAS - 2067618.

>Все-таки рассказать, что за косяки.
Помятуя о том, что ты сказал, qqqq изменил вот так:
....... end; TreeView1.EndUpdate; ListBox1.homm_altTransparent := TRUE; TreeView1.homm_altTransparent := TRUE; GRushPanel1.homm_altTransparent := TRUE; GRushPanel2.homm_altTransparent := TRUE;
и начал тестить:
Шаг 1:
Запуск... Прорисовывается все нормально... http://www.uus4u.com/download/modules/KOLnMCK/gRush/demo_start_window.png
Шаг 2:
Жму и удерживаю кнопку вниз... При достижения 40-45% от высоты дерева, при двух разных запусках, отрисовывалось по-разному (запускал раз 5-7, чаще всего вариант 1, но 2 тоже получается):
1 (qqqq не зависало. Была возможность дойти до конца дерева, но см. Шаг 3). http://www.uus4u.com/download/modules/KOLnMCK/gRush/demo_bug_at_work_presskey_1.png
2 (qqqq завивало). http://www.uus4u.com/download/modules/KOLnMCK/gRush/demo_bug_at_work_presskey_2.png
Шаг 3:
И в первом и во втором случае (прорисовка в Шаге 2) я "накрывал" форму другой (например IE), затем сворачивал IE и получал:
http://www.uus4u.com/download/modules/KOLnMCK/gRush/demo_bug_at_work_presskey_1_after.png

>Проверить в XP (если счас есть возможность).
Работает как часы... Тестировал qqqq... Если надо могу еще свой рабочий проект тестануть, но думаю проблем в XP не будет...

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

← →
homm © (2005-12-04 11:47) [112]

1) Найди WndProcPaint, измени окончание так:
Rslt := 0; Result := True; if fUpdRgn <> 0 then DeleteObject( fUpdRgn ); Exit; end;

Если не помогло:
2) Может хватит ТВОЮ прорисовку тестировать. Ты же прозрачность тестируеш. Скачай qqqq еще раз и прогони его.

← →
homm © (2005-12-04 12:01) [113]

Кстати. Я вот что вспомнил: Поговаривают вTransparentBlt под 9х GDI течет. Разремарь //UseSystemGradient := FALSE; в конце KOLGRushControls.pas

← →
MTsv DN (2005-12-04 13:24) [114]

Привет...

> Может хватит ТВОЮ прорисовку тестировать. Ты же прозрачность тестируеш.
Извини, конечно, но что значит: "МОЮ ПРОРИСОВКУ"?.. Не МОЮ, а ПОЛЬЗОВАТЕЛЬСКУЮ... Это две разные вещи... Я колеса не изобретал, я просто показал, что есть "глюки" с прозрачностью при использовании ручной прорисовки компонентов... Кто даст гарантию, что при использовании прорисовки Васи Пупкина, не выплывут теже проблемы...

ИТОГ:
> Разремарь //UseSystemGradient := FALSE; в конце KOLGRushControls.pas Именно это восстановило нормальную работу gRush как в qqqq и demo_temp, так и в моем проекте. Однако, как я уже писал в комментариях к ехе-никам, скорость прорисовки ОЧЕНЬ медленная...

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

← →
MTsv DN (2005-12-04 14:14) [115]

Привет...

Информация "в догонку"... QQQQ2 (без МОЕЙ ручной прорисовки) тоже не пашет... Тот же самый "косяк". Причем я ничего не компилил, а взял ехе-шник прямо из архива. Тест все тот же: достижение конца дерева без "косяков".

Шаг 1:
http://www.uus4u.com/download/modules/KOLnMCK/gRush/qqqq2_start.png - все в норме. ПринтСкрин работает нормально.
Шаг 2:
"Побежали" вниз по дереву... На 380-410 прорисовке (счетчик с левой стороны) получается, что пропадает градиентная панель... Сразу жму ПринтСкрин.........и получаю:
http://www.uus4u.com/download/modules/KOLnMCK/gRush/qqqq2_bug_clipboard.png - да. Именно все в черно-белых тонах...
А на самом деле:
http://www.uus4u.com/download/modules/KOLnMCK/gRush/qqqq2_bug_photo.jpg - (да JPG) фотка с "цифры" конечно поганая, но левая часть отсутсятвует...

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

> Извини, конечно, но что значит: "МОЮ ПРОРИСОВКУ"?.. Не МОЮ,
> а ПОЛЬЗОВАТЕЛЬСКУЮ...
Пользовательской она буде тогда, когда ты DrawText поставиш на CustomDraw, а когда у тебя две страници кода - это ТВОЯ прорисовка.

> Информация "в догонку"... QQQQ2 (без МОЕЙ ручной прорисовки)
> тоже не пашет... Тот же самый "косяк". Причем
> я ничего не компилил, а взял ехе-шник прямо из архива
Тут то и оно. (если не понял прочни ИТОГ: своего предидущего поста)

> Однако, как я уже писал в комментариях к ехе-никам, скорость
> прорисовки ОЧЕНЬ медленная...
Странно. У меня на Сел563 шкала загрузки проца выше 15% ни-ни. Может опубликуеш ехе вместе с исходником, который медлено рисуется или сам в XP прогонишь.

← →
MTsv DN (2005-12-04 16:24) [117]

Привет...

Ну и что ты этим сказать хочешь: "Тут то и оно."?.. Чего "оно"-то?..Твои слова: Скачай qqqq еще раз и прогони его. Я и прогнал, взял твой ехе-шник и в 98ой протестил как до этого... Как с прорисовкой не работает (при //UseSystemGradient := FALSE;), так и без нее (твой пример)...

А ехе-шик с исходником... Вот: http://www.uus4u.com/download/modules/KOLnMCK/gRush/qqqq.rar Это, кстати, твой первый qqqq, с добавкой:
ListBox1.homm_altTransparent := TRUE; TreeView1.homm_altTransparent := TRUE; GRushPanel1.homm_altTransparent := TRUE; GRushPanel2.homm_altTransparent := TRUE;
Разремарил //UseSystemGradient := FALSE; и в 98ом все еле прорисовывается...

или сам в XP прогонишь
И при чем тут XP, я и не говорил, что в ХР какие-то "косяки" замечены, я тебе все время про 98ую говорю...

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

← →
MTsv DN (2005-12-04 16:40) [118]

Привет...

А еще вот:
http://www.uus4u.com/download/modules/KOLnMCK/gRush/exe_fast_slow.rar Это вообще qqqq2 неизменненный мной... Исходники у тебя на сервере.

temp_fast_bug.exe - при //UseSystemGradient := FALSE;
temp_slow_ok.exe - при UseSystemGradient := FALSE;

Медленно ТОЛЬКО в Windows 98 !!!!! В ХР "косяки" отсутствуют и скорости одинаковы...

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

2 MTsv DN

> Ну и что ты этим сказать хочешь: "Тут то и оно."?.. Чего
> "оно"-то?..Твои слова: Скачай qqqq еще раз и прогони его.
> Я и прогнал, взял твой ехе-шник и в 98ой протестил как
> до этого... Как с прорисовкой не работает (при //UseSystemGradient
> := FALSE;), так и без нее (твой пример)...
Тебя х*й проссыш. Ты же в [114] сказал что UseSystemGradient := FALSE; все решает, кроме производительности. В [117] снова вылетает, а в [118] опять нет... Пойми когда я отсылал вторую версию qqqq, я не знал где ошибка, потому он и откомпилен без учета этого. Я же написал " (если не понял прочни ИТОГ: своего предидущего ([114])поста)".

> Медленно ТОЛЬКО в Windows 98 !!!!! В ХР "косяки" отсутствуют
> и скорости одинаковы...
"Е***я девяносто восьмая. Приведите сюда Била Гейтса"
(C) SouthPark. Big. Long. Uncuted.

По тексту readme.txt из demo_exe.zip:

> Наблюдения:
> temp_kol222_gRush029.exe - передвижение курсора вниз быстрое
> "без тормозов", до последнего элемента доходит нормально.
> ..
> temp_kol222p_gRush029.exe - передвижение курсора вниз МЕДЛЕННОЕ,
> чем ниже спускается курсор, тем "тормоза" сильнее, до последнего
> элемента доходит нормально...
> temp_kol222p_gRush030.exe - передвижение курсора вниз быстрое
> "без тормозов". В районе 45-50% от всей "высоты дерева"
> прорисовка элементов дерева "перескакивает" на ListBox,
> далее поведение прорисовки непредсказуемо...

Для системы 98 в 0.29 использовалась DrawTransparent - отсюда тормоза, в 0.30 TransparentBlt - Отсюда глюки. Прозрачность элементов непричем с самого начала. Дальше...

> Не пробывал связку: KOL222 + gRush030, т.к. в README к gRush
> сказано, что нужна минимум 222+
В ридми сказано что демы компилироватся не будут. Самим контролам паралельно, возможно стоит даже до 2.21 откатить.

2 Все остальные (если такие еще остались)

ИТОГ: Сделаю проверку на версию винды в GRush. Тормоза в 98 БУДУТ. Нужно снова переписывать DrawTransprent. Возможно Вам. Прозрачность казырна, только темы всеравно не держит. Если кто хочет знать мое мнение - поддержка тем без ручного рисования контролов (для этого тоже есть свой API) НЕРЕАЛЬНА. Microsoft прокосячила с этим CheckBox ом, залив его сначала черным, а затем отрисовав правильно поверх, а многие Theme Makerы взяли луну за шаблон. Есть правда и отличные темы (WaterColor, MacOS, в последнй даже кнопка с альфа каналом отлично рисуется), но даже если бы их было большенство - стандартная то тупит. Пользуйтесь моей прозрачностью и GRush контролами, а темы фтопку.

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

Привет...

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

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

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

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

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

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

Привет...

Самим контролам паралельно, возможно стоит даже до 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

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. Ну нельзя же на столько людей, которые смотрят твой проект не уважать.

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

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

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

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

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

> 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. Но оказалось что можно прекрасно и без оного можно обойтись не хуже.

Новости от 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 © (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
кажется еще для каких то свойств такая лабуда была, но назвать щас не могу, не помню... сначала не понимал в чем дело, но если выставить значение свойства в то, что было по умолчанию, то ошибка пропадает, и все копилируется замечательно

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

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

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

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

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

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

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

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

Новости от 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-06 15:22) [140]

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

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

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

> особенно 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 :)

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

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

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

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

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

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

> У меня есть предложение добавить контрол по управлению настройками
> всех компонентов сразу.
Это отличная идея. Она реализована в 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 уведены в минус, верно?
сейчас буду экспериментировать. и вышлю код.

← →
Barloggg (2006-08-29 09:20) [161]

Если crushpanel при создании имеет высоту = 1 и visible = true, то все бабахает.
Вчера методом деления пополам вычислил тот Groupbox что вызывал падение...

> Если 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-30 09:26) [163]

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

Кстати а почему внутри твоего Grushpanel между детками выровненными по caTop такие большие пропуски? и чем это регулировать?

У, брат :)
Тебе и вправду еще копать и копать :)

GRush вообще не при чем, и документация к ним тем более :) Смотри в сторону Border и Margin"ов всяких.

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