Компонент TKOLQProgressBar

← →
danger © (2007-07-12 06:13) [0]

Компонент, предназначенный для создания разнообразных ProgressBar"ов (с MCK зеркалом).

← →
MTsv DN © (2007-07-12 12:59) [1]

Danger, присоединяюсь к homm"у и SergeR"y (http://delphimaster.net/view/11-1184171451/), респект за контрол... Однако сразу вопрос. Как отслеживать изменение позиции? Через PBM_SETPOS у меня не прокатило. Никакого доп свойства, как в GRush, тоже не нашел...

← →
MTsv DN © (2007-07-12 13:25) [2]

Ну в общем, чтобы оставить совместимость с ProgressBar"ами, предлагаю такой код. Процедура procedure TQProgressBar.SetPosition( Value: Integer ):
try if ( Value <= 0 ) then begin D.fPosition := 0; SendMessage(Self.Handle, PBM_SETPOS, Value, 0); Exit; end else if ( Value > D.fMaxPos ) then Value := D.fMaxPos; SendMessage(Self.Handle, PBM_SETPOS, Value, 0);

← →
Danger © (2007-07-12 18:07) [3]

> MTsv DN © (12.07.07 13:25) [2]
> Ну в общем, чтобы оставить совместимость с ProgressBar"ами,
> предлагаю такой код. Процедура procedure TQProgressBar.
> ...

Принято, внесу изменения в следующей версии. Вообще надо бы ввести OnProgressChange, так будет нагляднее.

← →
Danger © (2007-07-12 22:30) [4]

[+] Добавлено событие OnProgressChange. [+] Добавлена обработка стандартных сообщений ProgressBar"a - PBM_GETPOS, PBM_SETPOS, PBM_GETRANGE, PBM_SETRANGE, PBM_SETRANGE32. [ * ] Незначительно изменена процедура SetMaxPos.

Отправил изменения MTsv DN.

← →
MTsv DN © (2007-07-13 09:04) [5]

> Отправил изменения MTsv DN.
Обновление на http://www.kolnmck.ru/

← →
MTsv DN © (2007-07-13 09:58) [6]

> [+] Добавлена обработка стандартных сообщений ProgressBar"a - PBM_GETPOS, PBM_SETPOS, PBM_GETRANGE, PBM_SETRANGE, PBM_SETRANGE32.
"Не арбайтн" 8( Вернее не так... "Обработка" добавлена, а вот "Генерация" нет... Если программер отправляет, например PBM_SETPOS контролу, то естесссна сработает, а вот если надо отследить изменение. Я чего пристал-то. Сейчас ты ввел OnProgressChange...хорошо. Но у меня все обработчики настроены на OnMessage->PBM_SETPOS, а он щас не работает, т.к. в procedure TQProgressBar.SetPosition( Value: Integer ); ты добавил:
if Assigned( D.fOnProgChange ) then D.fOnProgChange( @Self );, но убрал, то что я предлагал в [2]. Конечно, можно перекинуть код из OnMessage в OnProgressChange...

Это не ошибка, просто реализация такая, а с моей стороны рассуждения вслух...

З.Ы. Спасибо за контрол 8)

← →
Danger © (2007-07-13 19:36) [7]

> MTsv DN © (13.07.07 09:58) [6]
> > [+] Добавлена обработка стандартных сообщений ProgressBar"a
> - PBM_GETPOS, PBM_SETPOS, PBM_GETRANGE, PBM_SETRANGE, PBM_SETRANGE32.
> "Не арбайтн" 8( Вернее не так... "Обработка" добавлена,
> а вот "Генерация" нет... Если программер отправляет, например
> PBM_SETPOS контролу, то естесссна сработает, а вот если
> надо отследить изменение.

Поправил код, теперь контрол работает подобно обычному ProgressBar"у - обрабатывает сообщения и генерирует при необходимости. При этом переименовано свойство Position в Progress для большей ясности. Так что учтены сразу и мои правки по OnProgressChange, и предложения MTsv DN по отправке сообщений.

> Конечно, можно перекинуть код из OnMessage в OnProgressChange...

Не нужно ничего перекидывать, если удобно работать в OnMessage. Сейчас должен работать OnProgressChange совместно с OnMessage (в допустимых пределах).

Я отправил изменения почтой, протестируй на своем проекте. Если будут какие-нибудь шероховатости - будем смотреть дальше, иначе это будет финальный релиз.

← →
MTsv DN © (2007-07-13 19:48) [8]

> При этом переименовано свойство Position в Progress для большей ясности.
Во. Вот это рулез. Еще бы Maximum в MaxProgress, было бы ваааще сказка :) Ща гляну...

← →
Danger © (2007-07-13 20:02) [9]

> MTsv DN © (13.07.07 19:48) [8]
> Еще бы Maximum в MaxProgress, было бы ваааще сказка :)

Названия свойств остались в наследство от родительского vcl-компонента, лучше изменить конечно.

Подождем, может еще какие-нибудь идеи возникнут, все изменения тогда и внесу разом ...

← →
MTsv DN © (2007-07-13 20:05) [10]

Danger, ну-у-у, пока вроде все в порядке :)

← →
Danger © (2007-07-13 20:23) [11]

MTsv DN, на днях интегрирую справку для XHelpGen, переименую Maximum в MaxProgress и вышлю окончательный вариант. Вообще вот, зеркало написано не идеально (я уже писал раньше, при переключении parentFont в дизайн-тайме контрол автоматически не перерисовывается).

← →
Dy1 © (2007-07-18 23:14) [12]

> переименовано свойство Position в Progress

И какой лучше использовать?

← →
=BuckLr= (2007-07-19 13:17) [13]

> Danger

Респект! Красивый контрол! Сегодня заменил им стандартный в своей программе-чистилке памяти - выглядит вааще супер! Кореша с тапок падают :)

← →
Danger © (2007-07-19 20:17) [14]

> Dy1 © (18.07.07 23:14) [12]
> > переименовано свойство Position в Progress
>И какой лучше использовать?

Очевидно, Progress.

Кстати, к выходным появится очередная версия со всеми изменениями, предложенными на данный момент (проблема, как всегда, в нехватке свободного времени). В следующей версии все будет очевидно: Position исчезает окончательно, Maximum переименовывается, улучшенная эмуляция стандартного progressbar"a и работать должно немножко быстрее (имхо). Сейчас делаю справку для XHelpGen.

← →
MTsv DN © (2007-07-23 10:10) [15]

Обновление на http://www.kolnmck.ru/

Только сейчас понадобился компонент :) Утечка в 76 байт.

Часть лога:
40D8FD [KOLQProgBar.pas][TQProgressBar.GetGradientAr2][707]
40D6AD [KOLQProgBar.pas][TQProgressBar.InitPixArray][661]
40D3A2 [KOLQProgBar.pas][TQProgressBar.InitBlockArray][582]
Блок в настоящее время используется для объекта класса: Unknown

D7, MCK 2.73, WinXP SP2

> Dy1 © (22.08.07 20:20) [16]
> Только сейчас понадобился компонент :) Утечка в 76 байт.

Дома посмотрю, как только выдастся возможность.

> > Dy1 © (22.08.07 20:20) [16]> Только сейчас понадобился
> компонент :) Утечка в 76 байт. Дома посмотрю, как только
> выдастся возможность.

Я не смог моделировать ситуацию, чтобы было видно эту утечку. Вышли проект, на котором видно. И подробнее про условия, когда возникает.

забыл что делал для исправления этой проблемы. Поэтому:
Удалил MHXP. Появилась утечка 76 Бт (лог "01.txt")
Ставлю Windowed:=False для любого контрола на форме - утечка 124 Бт дополнительно (это к кому?), присутствуют USE_GRAPHCTLS, GRAPHCTL_XPSTYLES и GRAPHCTL_HOTTRACK. Лог 02.txt
В архиве отсутствуют модули FastMM4 и его dll; менеджер D7 заменён FastMM4-ным, KOLnMCK 2.73
www.dy.cdrrhq.ru/WinUPack_Dy_src.rar

> Dy1 © (25.08.07 11:51) [19]
> MHXP. Появилась утечка 76 Бт (лог "01.txt")

Я вообще критично отношусь к компонентам МН*. Довольно шероховатые компоненты (имхо). Да и какое отношение имеет компонент к MHXP, если проблемы появляются после его добавления/удаления? Попробуй протестить у себя с пустым КОЛ-проектом, как там насчет утечек?

>Ставлю Windowed:
> =False для любого контрола на форме - утечка 124 Бт дополнительно
> (это к кому?), присутствуют USE_GRAPHCTLS, GRAPHCTL_XPSTYLES
> и GRAPHCTL_HOTTRACK. Лог 02.txt В архиве отсутствуют модули
> FastMM4 и его dll; менеджер D7 заменён FastMM4-ным, KOLnMCK

С USE_GRAPHCTLS, GRAPHCTL_XPSTYLES и GRAPHCTL_HOTTRACK не тестировал (да и не хочу). Если утечка возникает только при использовании этих директив - смотрите сам KOL; если и без них - будем посмотреть еще.

www.dy.cdrrhq.ru/WinUPack_Dy_src.rar

Проект посмотрю сегодня.

> Dy1 © (25.08.07 11:51) [19]
Блок памяти был выделен и не освобожден. Размер: 76

402815 [System][@ReallocMem]
404448 [System][DynArraySetLength]
40451E [System][@DynArraySetLength]
40E846 [KOLQProgBar.pas][KOLQProgBar][TQProgressBar.GetGradientAr2][707]
408E29 [KOL][HelpGetBoundsRect]
40E5CC [KOLQProgBar.pas][KOLQProgBar][TQProgressBar.InitPixArray][661]
40451E [System][@DynArraySetLength]
40FB40 [KOLQProgBar.pas][KOLQProgBar][TQProgressBar.Resize][1059]
40DD99 [KOLQProgBar.pas][KOLQProgBar][QProgBar_WndProc][446]

Блок в настоящее время используется для объекта класса: Unknown

Вроде он и не должен освобождаться. Вызывается процедура инициализации, выделяется память под динамический массив. После выполнения нужных нам действий память не освобождается (скорее всего, это и выглядит для MemProof-a утечкой), просто при следующем запуске инициализации, если нужно, длина массива устанавливается в новое значение. Вот там неявно и происходит высвобождение памяти через DynArraySetLength. Дополнительно, при разрушении объекта длина всех динамических массивов устанавливается в ноль.

Компонент TKOLQProgressBar Найти похожие ветки