Владимир, опять про 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)

Чем это не устраивает?

В скроолбокс забыл включить. Точнее, по ошибке включил в скролбаре вместо скролбокса. У себя поправил уже, в 2.84 будет.

Если у вас не WIN и не GDI, то зачем их включать. Не проще ли найти константу и поставить в параметре числовое значение, которое её соответствует.

> [28] Vladimir Kladov ©   (24.10.07 22:04)
> в 2.84 будет.

Владимир, а вот это будет? (вдруг не видели…)
http://pda.delphimaster.net/?n=10&id=1163789456

Видел уже, вчера расшифровывал вашу шифрограимму :)

> 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)

Мега сложная функция :)