Решил создать отдельную тему...
Ошибки при подключенной UNICODE_CTRLS
1. function CrackStack_MapInResource( const MapName: String; Max_length: Integer; HandleSuspiciousAddresses: Boolean ): String;
Строка:
Resource2Stream( MapStrm, hInstance, PChar( MapName ), RT_RCDATA );
2е ошибки: несоответствие типов Char и WideChar... Еще насколько я понимаю надо в функции, String на KOLString заменить...

2. function ToRadix( number: Radix_Int; radix: Integer; min_digits: Integer ): KOLString;
Ошибка: несовпадает объявление.

3. function InsertSeparators( const s: KOLString; chars_between: Integer; Separator: KOLChar ): KOLString;
Ошибка: несовпадает объявление.

4. function IndexOfChar( const S : KOLString; Chr : KOLChar ) : Integer;
Строка:
 F := StrScanLen( P, Chr, Length( S ) );
Ошибка: несоответствие типов Char и WideChar...

Вообще функция IndexOfChar как то странно поддержку UNICODE осуществляет...
function IndexOfChar( const S : KOLString; Chr : KOLChar ) : Integer;
var P, F : PChar;
begin
 P := PChar( S );
 {$IFDEF INPACKAGE}
 F := StrScan( P, Chr );
 {$ELSE}
 F := StrScanLen( P, Chr, Length( S ) );
 {$ENDIF}
 Result := -1;
 if (F = nil) or (S = '') then Exit;
 Result := Integer( F ) - Integer( P )
        {$IFDEF INPACKAGE} + 1 {$ENDIF};
 if {(Result > Length(S)) or} (S[ Result ] <> Chr) then
   Result := -1;
end;
Кроме объявления ничего и нет. В самом начале строка S - WideString приводится к PChar...да и потом Ansi-версия StrScanLen откуда-то взялась...

Еще один вопрос.

А чем собственно результат IndexOfChar(S, Chr) отличается от Pos(Chr, S)? Или я чего-то недопонимаю?

В любом случае, в 2.87 IndexOfChar не работает с UNICODE.

Владимиру Кладову:
Будет ли официальное исправление того, о чём я писал здесь http://pda.delphimaster.net/?id=1201946463&n=10

Я исправил свой KOL.pas, но хотелось бы видеть это исправление и в будущих версиях...

скинул б сюда исправление, видимо у Владимира времени нету просто...

> скинул б сюда исправление

Всё есть по ссылке. Это очень небольшой фикс, но лично для меня очень важный.

А меня все так и интересует вопрос:
А чем собственно результат IndexOfChar(S, Chr) отличается от Pos(Chr, S)? Или я чего-то недопонимаю?

либо что б не юзать встроенную функцию Pos, либо для поддержки уникода, либо чтоб параметры местами поменять, либо я хз =)

Перемена параметров тут не при чем. Вопрос в другом. Результат IndexOfChar(S, Chr) и Pos(Chr, S) чем-нибудь отличается?

Не уловил суть вопроса.. я так понял обновление кол у тебя есть, а почему бы не проверить?) лично я не обновлялся

Pos ведь с подстрокой работает ?
или в дельфях есть оптимизация на Pos(char...) ???
значит IndexOf должен быстрее работать.

Ну, т.е. результат один и тот же... Да, работает с подстрокой, и медленнее, поэтому по совету mdw, заменил код в IndexOfChar на:

Где новая версия? Что то не нашел.

На сайте Кладова лежит обновление...

KOL.pas (2.87)
строка 39975


почему-то не корректно работает при UNICODE_CTRLS, копирует только половину символов строки с текстом подсказки.

Интересно и где же это его сайт?

> Интересно и где же это его сайт?

В интернете.
http://kolmck.net/rindex.htm

to MTsv DN
replace repne scasb in StrScanLen to


would be a lesser dirty workaround.
sure make the Char in defination changed to KOLChar first.

I am sorry, first line should be {$IFNDEF UNICODE_CTRLS}

Кажется, "официального" исправления этих ошибок не будет.
MTsv DN, может быть стоит пофиксить это всё и прикрутить к версии KOL, той, что на сайте?

столкнулся с неприятным эффектом.
на клиентской машине не влезший в чекбокс текст (из-за другой ширины текста судя по скриншоту) сделал этот самый чекбокс многострочным.
Однако у меня четко указано, что wordwrap:=false. в редакторе свойств, а не в коде конечно же.
я так полагаю это следствие политики "невмешательства" активно используемой в KOL? и глюк вышел из того факта, что умолчания у двух систем разные. Мне делать wordwrap:=false принудительно своим кодом? раз уж МСК ленится.

Что-то Владимир пропал, с марта тишина...:( Ау!!!

Нашел еще баг. В KOLAdd.pas с опцией TLIST_FAST.
Наткнулся в PTree, но и в PBits и, кажется в PFastStrListEx, то же самое. Заключается в следующем. Там (в KOLAdd.pas) активно используется приведение:
PCrackList( fList ).fXXXX или PCrackList( fChildren ).fXXXX
Что и приводит к краху, если элементов списка больше 256. Нужно или обращаться к свойствам списка и PCrackList вообще убирать, или при создании списка ставить:
{$IFDEF TLIST_FAST}fList.UseBlocks:= False;{$ENDIF}
Пока поправил у себя так, а как лучше сделать Владимир пусть принимает решение...

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, чтоб не писать каждый раз.

Никто работу ToolBar под Win98se не проверял? У меня при включенном для ToolBar ToolTip прога стабильно вылетает с ошибкой при их всплывании над кнопками ToolBar. Win98se у меня стоит под VMWare.

в процедуре:

function _WStrComp(S1, S2: PWideChar): Integer;
var Buf0: array[ 0..0 ] of WideChar;
begin
 Buf0[ 0 ] := #0;
 if S1 = nil then S1 := @ Buf0[ 0 ];
 if S2 = nil then S2 := @ Buf0[ 0 ];
 while TRUE do
 begin
   Result := Ord( S1^ ) - Ord( S2^ );
   if Result <> 0 then Exit;
   if S1^ = #0 then Exit;
 end;
end;

нехватает инкремента указателей сравниваемых строк

Модуль: KOL_ASM
Функция: Color2RGB
Описание: Очевидно, что если не SMALLEST_CODE Цвет некоторых контролов будет иметь черный цвет.
function Color2RGB( Color: TColor ): TColor;
asm
        BTR  EAX, 31
        JNC  @@exit
       AND  EAX , $7F    // <- a Fix    
        PUSH      EAX
        CALL      GetSysColor
@@exit:
end;
P.S Проверить немогу, но и без этого очевидно.

Кстати, интересный вопрос поднял Hallif...и дело даже не в АСМ версии.

Дельфи:



KOL:


Кому верить?

Разобрался. Разный TColor.

Подправлена асм-версия...

L`Autour ©   (08.09.08 06:01) [41]
Да простит меня КодГир за "стыренный" код.

2 Dimaxx ©   (11.08.08 17:00) [39]
Скиньте минимальный нерабочий проект. Так и не смог добиться ошибки...

> Скиньте минимальный нерабочий проект. Так и не смог добиться ошибки...

Пожалуйста... http://dimaxx.fatal.ru/scanline_nil.zip

Версия 2.87. Пока не поставишь принудительно pixelformat после изенения размера - любое изменение высоты картинки дает nil. С шириной все в порядке.

2 Dimaxx
Исправил...насколько хватило знаний асма :)

Удалено модератором