Версия 2.81

← →
Vladimir Kladov © (2007-09-29 10:20) [0]

Новости от 29 сентября 2007 (KOL & MCK v2.81) [-] TStrListEx: обеспечен свой метод DeleteLast (без него, список объектов рос безгранично по мере вызовов TStrList.DeleteLast). [-] Исправления для символа UNICODE_CTRLS: - TOpenDirDialogEx.InitialPath (string -> KOLString); - WndProcJustOneNotify: asm-версия запрещена для UNICODE_CTRLS; [+] Добавлена процедура WindowsLogoff. [-] Исправлено компилирование в Delphi2 (константа SPI_GETSNAPTODEFBUTTON неизвестна для D2, так же были проблемы с декларацией GetUpdateRgn и GetChildRgn в D2). [-] TLIST_FAST иправлен для некоторых методов TStrList, TStrListEx, TDirList. [-] Исправлена asm-версия функции Parse для случая символ #0 в качестве сеператора (так же изменена функция IndexOfCharsMin - asm-версия). [-] В функции ComboboxDropDown, исправлено использование символа USE_DROPDOWNCOUNT. [-] В Pascal-версии функции ApplyImageLists2ListView, константа $4FFC заменена на $403F, как и в ASM-версии. [-] Для тулбара, не удаётся обеспечить одновременно и выравнивание дочерних контролов вправо, и выравнивание соседних с тулбаром контролов. Введён символ условной компиляции TOOLBAR_FORCE_CHILDALIGN для тех, кому важнее обеспечивать корректное выравнивание дочерних контролов (и если тулбар сам расположен на отдельной панели, проблемы выравнивания соседних с ним контролов не существует). [-] Для символа MODAL_ACTIVATE_FIX, исправлена проблема с возможно не присвоенным полем Applet.fModalForm (Access violation). [-] Для прозрачного rich edit, сообщение WM_LBUTTONDOWN так же добавлено к списку сообщений, требующих перерисовки содержимого. [*] MCK Для TKOLLabel, свойство TabOrder может быть установлено в значение >= 0, что позволяет его корректно размещать в нужной позиции при выравнивании (т.к. Align использует TabOrder для определения порядка одинаково выровненных контролов). Значение по умолчанию остаётся -1, и всегда можно восстановить значение -1 вручную. [*] MCK Для TKOLButton, если его свойство WordWrap = true, создаётся многострочная кнопка (добавляется стиль BS_MULTILINE). [*] MCK Если специальный комментарий //don"t change uses добавлен перед директивой uses в файле DPR проекта, MCK более не трогает его. Это может быть необходимо, если вы хотите разместить ссылки на какие-либо модули до ссылки на модуль KOL.pas в списке uses проекта. [*] Изменения в visual_xp_styles.inc: - рисование прозрачной панели; - рисование фокусной рамки для чек-боксов; - рисование многострочных кнопок; [+] В файле KOLDEF.inc, добавлено определение {$SetPEFlags 1} для BDS 2006, и оно может быть отменено символом NO_STRIP_RELOC (это необходимо при создании DLL).

← →
vampir_infernal (2007-09-29 12:14) [1]

Владимир, Вам письмо.

← →
Vladimir Kladov © (2007-09-29 18:10) [2]

ничего нет.

← →
vampir_infernal (2007-09-29 21:54) [3]

отправлял на vk@kolmck.net

← →
Vladimir Kladov © (2007-09-30 06:00) [4]

Вот такие "добрые" люди как вы, пишут мой адрес в прямом эфире, а потом мне идут десятки спам-сообщений. И я еще даже не знаю, сколько писем режется на сервере, до того, как я увижу список. Вы хотя бы тему писем внятно пишите чтобы среди спама можно было разглядеть, что это письмо нормальное.

← →
vampir_infernal (2007-09-30 11:27) [5]

Извиняюсь

← →
MTsv DN © (2007-10-02 15:33) [6]

2 Kladov
В файле KOLadd.pas второй uses можно весь закомментировать, ни один модуль не используется, но подключается (ShlObj, CommCtrl, ActiveX...) Итог: -1кБ.

← →
vampir_infernal (2007-10-05 20:15) [7]

Владимир, в том же KOLAdd.pas можно перенести упоминание модуля ToGrush во вторую секцию uses, так как в разделе интерфейса ничего из ToGrush не упоминается.

← →
Vladimir Kladov © (2007-10-05 20:32) [8]

цель можно узнать? Просто в начале оно как-то удобнее, мне кажется.

← →
vampir_infernal (2007-10-06 08:33) [9]

Дело конечно Ваше, но я считаю, что если модуль используется только в секции реализации, то он должен быть прописан во второй секции uses. Я считаю, что такое описание соответствует "правильному", "понятному" оформлению кода, то есть когда модули прописаны там, где они используются, а не в одной секции все разом. Некоторые анализаторы кода типа Icarus даже выделяют такое, имхо, "не правильное" оформление, и советуют перенести упоминание во вторую секцию.
На работоспособность\размер программ это никак не влияет.

← →
mdw © (2007-10-11 14:01) [10]

Начиная с версии 2.80 Ошибка в TList.Assign:
procedure TList.Assign(SrcList: PList);
....
begin
...
else
{$ENDIF}
begin
Capacity := SrcList.fCount;
Move( SrcList.FItems[ 0 ], FItems[ 0 ], Sizeof( Pointer ) * SrcList. fCount );
{сейчас выделеного нет, сответственно перемещается кол-во элементов старого списка}
end;
end;
fCount := SrcList.fCount;
end;

Владимир, Вы бы поаккуратнее с такими базовыми вещами как списки и т.д. Если где-то в контролах ошибка, это не так критично, видно сразу, да и не так страшно. А то мне сегодня пришлось ночью на работу ехать - вечером поставил новую версию KOL, скомпилил программу, выложил пользователям, а ночью полный швах произошел... Конечно сам дурак, тестировать нужно.

Кстати, большой спасиб за TLIST_FAST. Большой прирост в скорости, особенно под WinCE, раза в 2-3.

← →
mdw © (2007-10-11 14:57) [11]

После изменения реализации прозрачности, заметил что при назначении Caption у LabelEffect в рантайм в ASM_VERSION не происходит перерисовка. Раньше, видимо, перисовывалось за счет излишних перерисовок контролов. Не перерисовывается и при Transparent = False. В PAS_VERSION все нормально. Где-то оконные процедуры разнятся для pas и asm? Пока поставил Invalidate в
function WndProcLabelEffect( Self_: PControl; var Msg: TMsg; var Rslt: Integer ): Boolean;
...
WM_SETTEXT:
begin
Self_.fCaption := PKOLChar( Msg.lParam );
Self_.Invalidate;
Result := True;
Rslt := 1;
Exit;
end;
...
В принципе, можно так и оставить, и не заморачиваться поиском разницы в ASM_VERSION и PAS_VERSION.

← →
jon (2007-10-11 15:41) [12]

Request(?):

Is this possible to add to kol.pas:

For a form, when CanResize is set to false
EnableMenuItem(GetSystemMenu(Applet.GetWindowHandle,False),SC_SIZE,MF_GRAY ED);

if Form.CanResize := True
EnableMenuItem(GetSystemMenu(Applet.GetWindowHandle,False),SC_SIZE,MF_ENAB LED);

Владимир, еще баг в TList, теперь для режима TLIST_FAST. Я приведу весь код, жирным, что поправил.
1. Внес Free_And_Nil( fBlockList ); внутрь скобок с проверкой на nil, т.к в Free_And_Nil ее нет.
2. Заменил PObj( fBlockList.Items[ i*2 ] ).Free; на FreeMem(fBlockList.Items[ i*2 ]);, т.к. там не объект лежит, а область памяти с указателями списка.

procedure TList.Clear;
{$IFDEF TLIST_FAST}
var i: Integer;
{$ENDIF}
begin
if fItems <> nil then
FreeMem( fItems );
fItems := nil;
fCount := 0;
fCapacity := 0;
{$IFDEF TLIST_FAST}
if fBlockList <> nil then begin
for i := 0 to fBlockList.Count div 2 - 1 do
FreeMem(fBlockList.Items[ i*2 ]);
// PObj( fBlockList.Items[ i*2 ] ).Free;
Free_And_Nil( fBlockList );
end;
fLastKnownBlockIdx := 0;
fLastKnownCountBefore := 0;
{$ENDIF}
end;

Владимир, еще баг в TList + TLIST_FAST.
Заключается в том, что при присвоении TList.Capacity значения больше 256 и последующем добавлении элементов, память под список оказывается не распределена. Если конкретно, то это происходит в TStrList.SetText. Например, попробуйте загрузить в TStrList файл с кол-вом строчек > 256 (StrList.LoadFromFile("большой файл")), в результате - 256 ошибка.

Владимир, я тут пишу Вам всякие багрепорты про TList, а может не нужно пока? Может Вы уже исправили все?

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

Репорты все нужны. У меня в проекте со строками нет работы, вот и не попалось. Тесты эти моменты тоже не зацепили. Сейчас сделаю обновление.

Почему-то не получается с налёту выполнить просьбу от Jon"а. Во-первых, это надо бы для формы, а не для Applet"а. Во-вторых, почему-то не работает. Наверное надо делать, когда форма уже на экране. Ещё маленько попробую.

Версия 2.81 Найти похожие ветки