| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Компонент TKOLQProgressBar
danger © (2007-07-12 06:13:00)Компонент, предназначенный для создания разнообразных ProgressBar'ов (с MCK зеркалом).
Danger (2007-08-26 13:53:00) [1]
> 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. Дополнительно, при разрушении объекта длина всех динамических массивов устанавливается в ноль.
danger (2007-08-25 13:40:00) [2]
> 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 (2007-08-25 11:51:00) [3]забыл что делал для исправления этой проблемы. Поэтому:
Удалил 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
Danger (2007-08-24 17:25:00) [4]
> > Dy1 © (22.08.07 20:20) [16]> Только сейчас понадобился
> компонент :) Утечка в 76 байт. Дома посмотрю, как только
> выдастся возможность.
Я не смог моделировать ситуацию, чтобы было видно эту утечку. Вышли проект, на котором видно. И подробнее про условия, когда возникает.
danger (2007-08-24 06:27:00) [5]
> Dy1 © (22.08.07 20:20) [16]
> Только сейчас понадобился компонент :) Утечка в 76 байт.
Дома посмотрю, как только выдастся возможность.
Dy1 (2007-08-22 20:20:00) [6]Только сейчас понадобился компонент :) Утечка в 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
MTsv DN (2007-07-23 10:10:00) [7]Обновление на http://www.kolnmck.ru/
Danger (2007-07-19 20:17:00) [8]
> Dy1 © (18.07.07 23:14) [12]
> > переименовано свойство Position в Progress
>И какой лучше использовать?
Очевидно, Progress.
Кстати, к выходным появится очередная версия со всеми изменениями, предложенными на данный момент (проблема, как всегда, в нехватке свободного времени). В следующей версии все будет очевидно: Position исчезает окончательно, Maximum переименовывается, улучшенная эмуляция стандартного progressbar'a и работать должно немножко быстрее (имхо). Сейчас делаю справку для XHelpGen.
=BuckLr= (2007-07-19 13:17:00) [9]
> Danger
Респект! Красивый контрол! Сегодня заменил им стандартный в своей программе-чистилке памяти - выглядит вааще супер! Кореша с тапок падают :)
Dy1 (2007-07-18 23:14:00) [10]> переименовано свойство Position в Progress
И какой лучше использовать?
Danger (2007-07-13 20:23:00) [11]MTsv DN, на днях интегрирую справку для XHelpGen, переименую Maximum в MaxProgress и вышлю окончательный вариант. Вообще вот, зеркало написано не идеально (я уже писал раньше, при переключении parentFont в дизайн-тайме контрол автоматически не перерисовывается).
MTsv DN (2007-07-13 20:05:00) [12]Danger,ну-у-у, пока вроде все в порядке :)
Danger (2007-07-13 20:02:00) [13]
> MTsv DN © (13.07.07 19:48) [8]
> Еще бы Maximum в MaxProgress, было бы ваааще сказка :)
Названия свойств остались в наследство от родительского vcl-компонента, лучше изменить конечно.
Подождем, может еще какие-нибудь идеи возникнут, все изменения тогда и внесу разом ...
MTsv DN (2007-07-13 19:48:00) [14]> При этом переименовано свойство Position в Progress для большей ясности.
Во. Вот это рулез. Еще бы Maximum в MaxProgress, было бы ваааще сказка :) Ща гляну...
Danger (2007-07-13 19:36:00) [15]
> 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 09:58:00) [16]> [+] Добавлена обработка стандартных сообщений 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, но убрал, то что я предлагал в [2]. Конечно, можно перекинуть код из OnMessageв OnProgressChange...
D.fOnProgChange( @Self );
Это не ошибка, просто реализация такая, а с моей стороны рассуждения вслух...
З.Ы. Спасибо за контрол 8)
MTsv DN (2007-07-13 09:04:00) [17]> Отправил изменения MTsv DN.
Обновление на http://www.kolnmck.ru/
Danger (2007-07-12 22:30:00) [18]
[+] Добавлено событие OnProgressChange.
[+] Добавлена обработка стандартных сообщений ProgressBar'a - PBM_GETPOS, PBM_SETPOS, PBM_GETRANGE, PBM_SETRANGE, PBM_SETRANGE32.
[ * ] Незначительно изменена процедура SetMaxPos.
Отправил изменения MTsv DN.
Danger (2007-07-12 18:07:00) [19]
> MTsv DN © (12.07.07 13:25) [2]
> Ну в общем, чтобы оставить совместимость с ProgressBar'ами,
> предлагаю такой код. Процедура procedure TQProgressBar.
> ...
Принято, внесу изменения в следующей версии. Вообще надо бы ввести OnProgressChange, так будет нагляднее.
MTsv DN (2007-07-12 13:25:00) [20]Ну в общем, чтобы оставить совместимость с 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);
| |
Страницы: 