mdw, скинь пока мне, я как просили в [17] все баги объединил в один апдейт. Сделаю вывешу здесь и скину Кладову...

Юзал PFastStrListEx для увеличения скорости, но на каком этапе все начало падать... пришлось вернуться на обычный лист.. Возможно как раз из-за количества элементов...

Еще один баг в TLIST_FAST. Переодически пытаюсь прикрутить, так как выигрышь получается приличный, но каждый раз натыкаюсь на баги.:(

Сперва, как получить. Вот простейший пример.

var SL: PStrListEx;
   i: Integer;
begin
   SL:= NewStrListEx;
   for i:= 0 to 257 do begin
     SL.AddObject('', (i));
     SL.Items[i]:= '1111';
   end;
   SL.Free;
end;
При i = 257 зацикливается в TStrList.AddObject, вернее в fList.Insert();
Сама ошибка происходит еще при i = 256, на SL.Items[i]:= '1111';
В методе:
procedure TStrList.Put(Idx: integer; const Value: string);
begin
 Delete( Idx );
 Insert( Idx, Value );
end;

после Delete, Insert сбивается что-то. До Delete TList.fBlockList.fCount = 4, после уже TList.fBlockList.fCount = 2, а  Insert работает как будто все еще 4.
Дальше не разбирался, в чужом коде сложновато...

К слову. А зачем вообще через Delete, Insert делать? Я вот переделал малях, думаю, побыстрее будет работать...

procedure TStrList.Put(Idx: integer; const Value: string);
var P: DWORD;
   El:Pointer;
   Mem: PChar;
   L: Integer;
begin
 P := DWORD( fList.Items[ Idx ] );
 if (fTextBuf <> nil) and ( P >= DWORD( fTextBuf )) and
    ( P < DWORD( fTextBuf ) + fTextSiz ) then
 else
 begin
   El := FList.Items[ Idx ];
   FreeMem( El );
 end;

 L := Length( Value ) + 1;
 GetMem( Mem, L );
 Mem[0] := #0;
 if L > 1 then System.Move( Value[1], Mem[0], L );
 fList.Items[ Idx ]:= Mem;
end;

> после Delete, Insert сбивается что-то. До Delete TList.fBlockList.
> fCount = 4, после уже TList.fBlockList.fCount = 2, а  Insert
> работает как будто все еще 4. Дальше не разбирался, в чужом
> коде сложновато...

Только сейчас сообразил. Получается, баг будет проявляться в такой связке всегда.

TList.Delete( Idx );
TList.Insert( Idx, Value );

При Idx=256;

Это плохо, пока, наверное, TLIST_FAST - нафиг. Подождем до исправления.

2 MTsv DN
Отправил. Но исправления, так, чтоб работало. Глубже неохота копать....

Получил...

Затянувшееся, но состоявшееся обновление на http://www.kolnmck.ru.

Неофициальный апдейт для KOL&MCK версии 2.87:
http://www.kolnmck.ru/upd/kolmck287to287+.7z

Если честно "ломает" создавать список исправлений...в общем-то, все что упоминалось в этой ветке (за исключением [18])

З.Ы. Копия Кладову...

Копию я не получил, но я так взял. Попробую слить со своими изменениями.

Вот здесь исправление бага с fast tlist: http://kolmck.net/upd/to287++.rar
Посмотрите сначала, т.к. протестировал я только на приведённом примере. Может, ещё где-то не работает. (Через Insert/Update потмому что код так короче, а скорость здесь и так выиграна в разы).

> Вот здесь исправление бага с fast tlist: http://kolmck.net/upd/to287++.
> rarПосмотрите сначала, т.к. протестировал я только на приведённом
> примере. Может, ещё где-то не работает. (Через Insert/Update
> потмому что код так короче, а скорость здесь и так выиграна
> в разы).

Я там тоже что-то накосячил, сейчас звонили с работы, валится усё... Хорошо предыдущую версию оставил доступной, а то пилить через весь город...
В понедельник попробую это обновление, и отпишусь. Хотелось бы довести до ума TLIST_FAST, т.к. прирост скорости очень даже! Один кусок кода (моего), примерно с 5 минут до 50 секунд ускоряется. А в общей совокупности минут 15 получается, а это много значит когда метро с минуты на минуту должно закрыться.:)

К слову, а на КПК, TLIST_FAST дает вообще волшебный прирост, чуть ли не на порядок! Ещё бы объеденить две ветки KOL, официальную и Юрия Сидорова, вообще счастье будет. Но тут, я понял, идеологические противоречия. Ладно, если в основной ветке TLIST_FAST заработает, то там тоже не сложно будет исправить.

ЗЫ. Я сморел код для PWStrList, там примерно тоже, что и я написал.:)

Официально объеденить две ветки вряд ли получится, но я скоро сделаю синхронизацию с последней версией KOL и получится как раз та объединенная версия.
До этого не делал синхронизацию, т. к. боялся занести новых багов :)

> Вот здесь исправление бага с fast tlist: http://kolmck.net/upd/to287++.
> rar

Попробовал. Вроде работает.

Возникло пару неясностей.

1. В результате апдейтов kolmck286to287++.upd и kolmck287+to287++.upd получаются разные KOL_ASM.inc. Я тестировал то, что получается с помощью kolmck287+to287++.upd. Какой правильный?

2. Я посмотрел KOLadd.pas. Вы вернули все как было до kolmck287to287+.upd.
Хотя ошибка и не возникает сейчас, но сдается мне, что все же там ошибка присутствует. Посмотрите сами, например:

procedure TTree.Add(Node: PTree);
var Previous: PTree;
begin
 Node.Unlink;
 if fChildren = nil then
   fChildren := NewList;
 Previous := nil;
 if PCrackList( fChildren ).fCount > 0 then
   Previous := PCrackList( fChildren ).fItems[ PCrackList( fChildren ).fCount - 1 ];
//Вот здесь идет обращение к fItems, но если элементов больше 256, при
//TLIST_FAST то fItems будет nil. Или я что-то не понимаю?

 if Previous <> nil then
 begin
   Previous.fNext := Node;
   Node.fPrev := Previous;
 end;
 fChildren.Add( Node );
 Node.fParent := @Self;
end;

KOL_Asm не изменялся ни в одном из обновлений + или ++. Или в + всё-таки изменялся? Win Merge разницы не показывает.

Правильно именно Items использовать, тогда TLIST_FAST должен включаться в работу.

> KOL_Asm не изменялся ни в одном из обновлений + или ++. Или в + всё-таки изменялся?
С версии 2.86 на 2.87 изменялся же или нет? Вы же обновления выложили:
2.86 -> 2.87++ (непонятно зачем?)
и
2.87+ -> 2.87++

А зачем генерация констант  в 2.87++ для  Menu и PopupMenu стала типизированной?
Теперь Case Item of с ними не проходит.

2 L`Autour
Пардон. Это мне понадобилось, забыл убрать... Просто подправьте mirror.pas и пересоберите все...

И по 2.86 -> 2.87++, там действительно KOL_ASM.inc не меняется  хотя
для 2.86 -> 2.87 он менялся (матюгов нет). Без изменения KOL_ASM.inc - идут матюги при компиляции прог.
(на работе делал 2.86 -> 2.87 -> 2.87+ ->  2.87++, а дома решил попробовать 2.86 -> 2.87++)

Владимир, проблема у Bitmap при доступе через ScanLine. При создании битмапа с фиксированными размерами все ок. Но стоит изменить высоту (с шириной все в порядке), как ScanLine возвращает nil. Пробовал и DIB-битмап. Тоже самое - nil выдается и в ScanLine, и в DIBBits. Придется изворачиваться, но это не есть гуд. Если кто знает способ решения проблемы - подскажите.

PixelFormat присвоить, или есть ещё свойство HandleType. В общем, после изменения размера надо снова превратить его в DIB.

Спасибо, буду знать. Установка PixelFormat после изменения размеров решила проблему. А мб это "сунуть" в FormatChanged, чтоб не писать каждый раз.