-
Новости от 12 октября 2007 (KOL & MCK v2.83)
[-] Исправлен метод TList.Assign. Спасибо mdw за bug-репорты касаемо
TList и символа TLIST_FAST.
[-] Для символа TLIST_FAST, исправлено свойство TStrList.Text и
использующие его методы LoadFromFile, SaveToFile и.т.д.
[-] Для ASM_VERSION, исправлена функция CallTControlCreateWindow (не
возвращала полученный от CreateWindow результат. Это приводило к багам
в случае частого пересоздания окон).
[+] ToGRush усовершенствован: исправлен scrollbar, все scrollbar-ы
включая в выпадающем списке combo, теперь могут быть замещены для
стиля GRush, кнопка со стрелкой в combo так же в стиле GRush.
Так же, в KOL: добавлен стиль esSolid к списку типа TEdgeStyle (для
панелей), чтобы позволить создание простой панели esNone без
прозрачности вместо GRush-панели, при необходимости (обычная панель
всё-таки намного быстрее, и больше подходит для случаев больших
панелей, которые еще и могут изменять свой размер. Установкой
соответствующего общему стилю цвета (Color) вполне можно добиться
единства внешнего вида, тем не менее).
Так же, в MCK: для ряда контролов, могущих иметь внутренние линейки
прокрутки, доступно свойство OverrideScrollbars. Значение его true по
умолчанию, но генерируемый код заключается в скобки .... Т.о., для замены скроллбаров при
использовании ToGRush, достаточно добавить символ OVERRIDE_SCROLLBARS
к опциям проекта. Писатели компонентов (контролов с внутренними
скроллами) должны так же присвоить TRUE полю fHasScrollbars2Override
(protected), для обеспечения генерации соответствующего кода.
Разумеется, всегда можно вызывать функцию OverrideScrollbars в своём
коде (если не используется MCK или контрол в зеркале не поддерживает
свойство OverrideScrolbars).
См так же новую версию KOLDirDlgEx (в архиве KOLadd.zip), который
использует возможность переопределения прокруток на стиль GRush, когда
включён символ USE_GRUSH.
[*] Свойство ParentWindow теперь всегда возвращает дескриптор
родительского окна, независимо от того, является ля родительское окно
"своим" или "чужим" (установленным функцией API SetParent).
[-] Процедуры TControl.DoSetFocus и WndProcForm (asm-версии)
исправлены (обнаружены небольшие баги, ранее себя серьёзно не
проявлявшие, но мешавшие корректной работе заменителей прокруток в
стиле GRush).
[-] TControl.SetCaption - исправлена asm-версия: у LabelEffect
заголовок не изменялся при присваивании значения (не вызывался метод
Invalidate. Вместо того, вызывался лишний Invalidate для обычной
метки).
[+] Для форм со свойством CanResize = FALSE, соответствующий пункт
системного меню теперь делается недоступным.
-
++++ for this year...
-
А ТОРМОЗА КАНВАСА+БИТМАП ПРИ РИСОВАНИИ БУДУТ ПРАВИЦА ?
-
> [2] Robt © (16.10.07 15:13)
Какие тормоза?
-
-
-
НЕТ НЕ БУДУТ
Объявлется переменная C: PCanvas; присаивается и дальше используется, вместо того чтобы её каждый раз получать заново.
-
> Объявлется переменная C: PCanvas; присаивается и дальше
> используется, вместо того чтобы её каждый раз получать заново.
>
а в битмапе канвас пересоздается при каждой операции рисования типа lineto ?
-
Разберитесь. Что спрашивать? Или я должен помнить каждый нюансик в 100000 строк кода? Мне непонятно вообще, зачем в том примере, что был приведён выше, через канву рисовать. Есть гораздо более быстрый способ. ScanLine[] есть, формат битмапа знаете. И вперёд.
-
Владимир, очередной баг в TLIST_FAST. Вот простейший пример:
procedure TMainForm.Button2Click(Sender: PObj);
var SLE: PStrListEx;
i: Integer;
begin
SLE:= NewStrListEx;
for i:= 0 to 100000 do begin
SLE.AddObject(Int2Str(Random(1000)), i);
end;
SLE.Sort(False); // здесь валится
SLE.Free;
end;
-
К предыдущему посту. Проявляется только на ASM_VERSION.
-
Посмотрю.
-
Надо в процедурах сортировки {$IFDEF ASM_VERSION} заменить на ...ASM_TLIST} и такие же скобки добавить в KOL_ASM.inc. Процедуры CompareStrListItems и CompareAnsiStrListItems. Т.е. попросту отключить асм для них двух.
-
Владимир, спасибо. Вроде заработало (TLIST_FAST). Еще потестирую конечно, но пока работает.
-
Владимир, заметил небольшой баг при генерации кода для создания меню.
Вот код полученный с помощью MCK
...
Result.MainMenu1 := NewMenu( Result.Form, 0, [ '11111111' , '3333333', '3333333333', '' ], nil );
...
Result.MainMenu1.Items[ 0 ].OwnerDraw := TRUE;
Result.MainMenu1.Items[ 1 ].OwnerDraw := TRUE;
Result.MainMenu1.Items[ 2 ].OwnerDraw := TRUE;
Result.MainMenu1.OnMeasureItem := Result.MainMenu1MeasureItem;
Result.MainMenu1.OnDrawItem := Result.MainMenu1DrawItem;
...
Так вот, OnMeasureItem не будет ни разу вызван. OwnerDraw := TRUE нужно ставить после назначения события. Наверное нужно переносить назначение OwnerDraw из TKOLMenu.SetupFirst в TKOLMenu.SetupLast.
-
У меня вызывается. Так что дело не в этом (если у вас не вызывается).
-
Владимир, это маин меню, которое в строчку под заголовком формы.
-
Владимир, вот минимальный проект www.kolnmck.ru/Test.rar.
Я туда же mirror.pas положил с изменениями.
-
Еще исправление для TLIST_FAST:
//[function TStrList.GetPChars]
{$IFDEF ASM_TLIST}
{$ELSE ASM_VERSION} //Pascal
function TStrList.GetPChars(Idx: Integer): PChar;
begin
Result := PChar( fList.{$IFDEF TLIST_FAST}Items{$ELSE}fItems{$ENDIF}[ Idx ] )
end;
{$ENDIF ASM_VERSION}
Ну и в KOL_ASM.inc тоже:
{$IFDEF ASM_TLIST}
function TStrList.GetPChars(Idx: Integer): PChar;
asm
MOV EAX, [EAX].fList
MOV EAX, [EAX].TList.fItems
MOV EAX, [EAX+EDX*4]
end;
{$ENDIF}
-
Еще баг для TLIST_FAST, ASM_VERSION.
Валится в TStrList.IndexOf() при Count >= 256.
Например:
var SLE: PStrListEx;
i: Integer;
begin
SLE:= NewStrListEx;
for i:= 0 to 256 do SLE.AddObject(Int2Str(random(1000)), i);
SLE.IndexOf('2'); //Здесь падает
-
Владимир, опять про TLIST_FAST.
Возникла ошибка при разрушении меню при кол-ве элементов >= 256. Причина в TList.ReleaseObjects. Там цикл разрушения идет от 0 to Count. Т.е. сперва разрушается 0 элемент, затем 1 и т.д. Но при разрушении меню происходит удаление этого пункта из списка. Результат понятен...
В общем нужно или в TList.ReleaseObjects объекты разрушать с последнего к первому (тогда и TList.Release тоже). Так наверное правильно будет. Вот примерно так поправил:
procedure TList.ReleaseObjects;
...
{$IFDEF TLIST_FAST}
if fUseBlocks and Assigned( fBlockList ) then
begin
for i := fBlockList.Count div 2 - 1 downto 0 do
begin
CountCurrent := Integer( fBlockList.fItems[ i*2+1 ] );
BlockStart := Pointer(Integer(fBlockList.fItems[ i*2 ]) + (CountCurrent-1)*4);
for j := CountCurrent-1 downto 0 do
begin
if BlockStart^ <> 0 then begin
PObj( Pointer( BlockStart^ ) ).Free;
Dec( BlockStart );
end;
end;
end
else
{$ENDIF}
...
Или в function NewMenu(..) добавить Result.FItems.fUseBlocks:= False;
-
Нет, майн не тестировал У меня как-то так получилось, что майн меню перекрашивать не пришлось. Значит, если поменять порядок, то работает? Да, так вроде пашет, даже что-то рисует если код добавить.
По TLIST_FAST пробежал с грабляси (ctrl+F), еще до кучи нашёл. В обновлении будет. В основном это для контролов если дочерних > 256, так что не особо печально. Но есть места в DirList'е, а там почти наверняка может оказаться > 256 файлов в директории.
-
Лучше поставить от последнего к первому. Я еще как сейчас помню, лет так 9-10 назад, когда этот цикл, задумался на минуту: надо ли обращать порядок уничтожения. И мне тогда показалось, что не надо. Оказалось спустя 10 лет что всё-таки было надо :))
-
А нет, тогда я пришёд к тому что лучше обращать. Наверное просто из соображений экономии кода. Ав от сейчас - с тлист-фаст, экономии кода не получается. Но он и не для экономии кода, вообще. Надо все-таки обрашать, мало ли где еще ружжо выстрелит. К обновлению перепишу цикл по-простому.
-
хм. а почему по умолчанию для ScrollBox выключен AcceptChildren?
Это какой-то хитрый план?
-
и кстати у группбокса тоже
-
эмм... а как средствами КОЛ переименовать файл?
я увидел процедуру DoFileOP которая вроде как должна этим заниматься.
правда она по скобкой WIN_GDI.
Указал эту директиву.
Но дельфи не может найти константу FO_RENAME!
Нашел ее поиском. оказалось что эта константа спрятана под еще одной директивой WIN. Лады, ввел эту директиву тоже.
Но и тогда она не нашлась!
Даже в книгу полез. Там вообще про файловые операции - ни слова.
Дальнейшее разглядывание выявило, что эта константа вообще находится в секции implementation.
Это, извините, зачем? План не просто хитрый, но еще и крепкий? или эта процедура только для внутренних целей предназначена?
Заменив константы их значениями требуемое поведение кода было достингуто, но недоумение осталось.
-
> [26] Barloggg (24.10.07 18:16)
Чем это не устраивает? function RenameFile(const OldName, NewName: string): Boolean;
-
В скроолбокс забыл включить. Точнее, по ошибке включил в скролбаре вместо скролбокса. У себя поправил уже, в 2.84 будет.
Если у вас не WIN и не GDI, то зачем их включать. Не проще ли найти константу и поставить в параметре числовое значение, которое её соответствует.
-
-
Видел уже, вчера расшифровывал вашу шифрограимму :)
-
> ANTPro © (24.10.07 19:15) [27]
> > [26] Barloggg (24.10.07 18:16)
> Чем это не устраивает?
> function RenameFile(const OldName, NewName: string): Boolean;
дык елы палы НЕТУ функции RenameFile в kol.pas зато есть в SysUtils.pas, а это, извините, уже VCL.
> Vladimir Kladov © (24.10.07 22:04) [28]
> Если у вас не WIN и не GDI, то зачем их включать. Не проще
> ли найти константу и поставить в параметре числовое значение,
> которое её соответствует.
Ну, я так и сделал (см [26]), но нафига спрашивается нужны тогда константы? только дезориентируют. А зачем сделано это:
> Если у вас не WIN и не GDI
-
> дык елы палы НЕТУ функции RenameFile в kol.pasзато есть
> в SysUtils.pas, а это, извините, уже VCL.
Зато в Windows есть MoveFile.
-
> [31] Barloggg (25.10.07 11:49)
Мега сложная функция :) function RenameFile(const OldName, NewName: string): Boolean;
begin
Result := MoveFile(PChar(OldName), PChar(NewName));
end;
|
Есть новые 
Нет новых [134431 +10][b:0][p:0.005]