-
Новости от 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 Если специальный комментарий перед директивой uses в файле DPR проекта, MCK более не трогает его.
Это может быть необходимо, если вы хотите разместить ссылки на
какие-либо модули до ссылки на модуль KOL.pas в списке uses проекта.
[*] Изменения в visual_xp_styles.inc:
- рисование прозрачной панели;
- рисование фокусной рамки для чек-боксов;
- рисование многострочных кнопок;
[+] В файле KOLDEF.inc, добавлено определение для BDS
2006, и оно может быть отменено символом NO_STRIP_RELOC (это
необходимо при создании DLL).
-
Владимир, Вам письмо.
-
ничего нет.
-
отправлял на vk@kolmck.net
-
Вот такие "добрые" люди как вы, пишут мой адрес в прямом эфире, а потом мне идут десятки спам-сообщений. И я еще даже не знаю, сколько писем режется на сервере, до того, как я увижу список. Вы хотя бы тему писем внятно пишите чтобы среди спама можно было разглядеть, что это письмо нормальное.
-
Извиняюсь
-
2 Kladov В файле KOLadd.pas второй uses можно весь закомментировать, ни один модуль не используется, но подключается (ShlObj, CommCtrl, ActiveX...) Итог: -1кБ.
-
Владимир, в том же KOLAdd.pas можно перенести упоминание модуля ToGrush во вторую секцию uses, так как в разделе интерфейса ничего из ToGrush не упоминается.
-
цель можно узнать? Просто в начале оно как-то удобнее, мне кажется.
-
Дело конечно Ваше, но я считаю, что если модуль используется только в секции реализации, то он должен быть прописан во второй секции uses. Я считаю, что такое описание соответствует "правильному", "понятному" оформлению кода, то есть когда модули прописаны там, где они используются, а не в одной секции все разом. Некоторые анализаторы кода типа Icarus даже выделяют такое, имхо, "не правильное" оформление, и советуют перенести упоминание во вторую секцию. На работоспособность\размер программ это никак не влияет.
-
Начиная с версии 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.
-
После изменения реализации прозрачности, заметил что при назначении 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.
-
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'а. Во-вторых, почему-то не работает. Наверное надо делать, когда форма уже на экране. Ещё маленько попробую.
|