![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Версия 2.78 [Delphi, KOL/MCK, Windows]
Vladimir Kladov © (2007-08-17 20:02:00)
Новости от 17 августа 2007 (KOL & MCK v2.78)
[-] AutoPopupMenu исправлен (не вызывался, если был назначен родителю
контрола). Примечание: исправлен не для случая NEW_MENU_ACCELL, там
проблема остаётся.
[-] Компилирование кода с включённым симвлом NEW_MENU_ACCELL
исправлено. (Хотя правильная работа с самим символом под сомнением).
[-] Исправлен двойной вызов акселератора меню при установке
Form.KeyPreview = true.
[+] Добавлен символ TOOLBAR_DOT_NOAUTOSIZE_BUTTON который
предотвращает установку флага TBSTYLE_AUTOSIZE кнопкам тулбара при
наличии префикса '.' в заголовке (в этом случае префикс удаляется).
Это изменение не влияет существенно, т.к. ширина кноки может быть
установлена свойством TBButtonWidth как обычно, в том числе и для
кнопок со стилем TBSTYLE_AUTOSIZE.
[*] Небольшие изменения в TBitmap.LoadFromStreamEx: с новым симолом
FILL_BROKEN_BITMAP обрезанный файл дополняется нулями при загрузке
(обычно - черный цвет), для предотвращения мусорных пикслей в верхней
части такой картинки. Раньше, такие битмапы просто не грузились.
[-] Использование символа USE_MENU_CURCTL исправлено до
компилируемости (т.к. некоторое время назад поле было переименовано:
FParent -> FParentMenu).
[-] MCK CanResize устанавливается в генерируемом коде после установки
размеров формы.
[+] ADD KOLDirDialogEx обновлен: с несколькими новыми символами
условной компиляции он может быть оснащен панелью ссылок, ускоряющих
переход в дереве директорий. Изменение обеспечено как для стандартного
вида, так и для интерфейса в стиле GRush (с символом USE_GRUSH). Так
же, новый символ DIRDLGEX_OPTIONAL, позволяет использовать оба вида
диалога выбора директорий - стандартный и DirDialogEx - в дном
приложении..
[+] GRAPH Animation и KOLGif обновлены: теперь они обеспечивают
кэширование масштабированных кадров для ускорения вывода (опционально,
при наличии соответствующего символа условной компиляции). Так же,
добавлено свойство MinDelay.
[+] Добавлен пакет spellCheck : модуль и демо-проект по использованию
MS Word для проверки орфографии. Вариант для VCL так же имеется в
архиве.
Vladimir Kladov (2007-09-06 15:30:00) [1]Мне было не до шуток, и я по-быстрому убрад Align и сделал своим кодом. Потом я пытался восстановить ситуацию, но ничего не получилось. Так что ждём пока не выскочит еще у кого-нибудь.
Galkov (2007-09-06 14:28:00) [2]
> У меня тут что-то такое проскакивало: если форма открыта сразу маленького размера,
> и выравниваемый родитель не виден, то начинаются глюки с выравниванием
Владимир, если до сих пор проскакивает, или снова начнет - логично намылить (или выложить где ни то) минимизированный проект.
Мне предпочтительней "чистый KOL", но и другие "воспроизводимые" варианты - не есть проблема.
Надо ведь: или - что-то делать, или - что-то решать :)
Vladimir Kladov (2007-09-03 23:21:00) [3]я тут посмотрел: если убрать Result := true; , то кнопка выравнивается вправо, и эффект сохраняется и на 95 и на 98. Значит, можно убрать. Видимо, когда писал так, была причина. Align с тех пор много раз исправлялся, а в NEW_ALIGN вообще не тестировалось. Уже сейчас сложно догадаться, что была за причина поставить там предотвращение дальнейшей обработки.
Galkov (2007-09-03 17:51:00) [4][41] - это номер поста (Ваш - 44-й)
Там ничего военного - цитата из KOL.WndProcToolbarCtrl, и MSDN.WM_WINDOWPOSCHANGED
Vladimir Kladov (2007-09-03 17:44:00) [5]Я не знаю, что такое [41], о котором тут много упоминалось, но с тулбаром могу сказать. Эта сво... пардон, этот контрол не имеет ширины и не может быть выровнен по-человечески. Вместо этого у него есть выравнивание по верхнему краю родительского окна, обеспечиваемое операционкой. И бесконечная вправо ширина. Вот такие вот ноги у этой проблем с этим контролом.
Galkov (2007-09-03 16:39:00) [6]Ну ладно, здесь уже про другое писать вроде не будут, поэтому помусолить NEW_ALIGN попробую...
Да и поститься не могу с адекватной частотой - похоже, мой IP сидит в банах у мастеров Дельфи (других проблем мне конечно мало :evil: )
2 MTsv DN
> Да я не разбирался в коде KOL.PAS по этому поводу
А чего там разбираться, база-то - предельно проста.
Собственно, вся она и написана в [41].
Разве что добавить можно, что обработка сидит на WM_SIZE - независимо от NEW или OLD
Именно поэтому, я позволю себе выразить сомнения в справедливости Ваших слов:
> тем более что при OLD_ALIGN все работает нормально...
Не может ВСЕ работать нормально даже теоретически, при изменении размеров именно ToolBar. Обоснование - в [41]
Но OLD может сработать при resize НЕ ToolBar, а MainForm.
Причина:
MainForm получает таки WM_SIZE, а далее выравнивание происходит с очень большой избыточностью. Эта избыточность может спасти против контролов, которые позволяют себе вольности не возвращать WM_SIZE
Подробнее:
В процедуре AlignChildrenProc - подумали, посчитали, и зарешали как-то поменять размеры контролу. При этом нормальный контрол (в смысле - не наш ToolBar) снова получит нотификацию WM_SIZE и начнет новый рекурсивный процесс выравнивания. Причем, начиная не с себя, а со своего парента.
И так на каждом контроле.
И завершающий удар - для каждого контрола, меняющего размер, вызывается сама ф-я AlignChildrenProc рекурсивно (предыдущих вызовов Global_Align с парента было мало, оказывается).
Что и помогает с ToolBar, но только если изменения порождены не в нем (тогда вообще ничего не будет), а в каком-то из родителей. Или в каком-то из детишков...
Прочувствовавши объем происходящего, как-то вспоминается топик с параллельного форума: " Русский код, бессмысленный и беспощадный"
Ясный перец, убрал я всю эту "беспощадность" в NEW_ALIGN
И мне даже кажется, что в этом основное его достоинство (ну не считая того, что некоторые вещи он таки надежно делает, а отличии от OLD)
А размеры - да вряд ли они стали меньше...
Ну, разве что, за счет добавления ASM-версии (для OLD нет ASM-версии) - стало около 600 байт.
Но, в отличие от Владимира, мне представляется, как и Вам, что вопрос о привязанных детишках в ToolBar-е - имеет право на жизнь.
НО опять же, совершенно категорично (по крайней мере, пока в постановку задачи для ALIGN входит обработка именно WM_SIZE) - это проблема ToolBar, а вовсе не NEW_ALIGN
Ну никак нельзя строить вышеупомянутую "беспощадность" в кодах, лишь по той причине, что Автору некого контрола пришло в голову решение заблокировать его WM_SIZE.
А предложений по фиксингу ToolBar дать не могу, поскольку не достиг еще понимания причин произведенных действий.
Вроде видно же (фрагмент там же, в [41]), что это сделано специально, даже эмулирована обработка onResize из-за этого...
Вопрос - зачем...
Если без этого не обойтись, то надо продолжать "эмуляцию", и то же делать с Global_Align, видимо.
Здесь логичнее выслушать Автора этих кодов, а потом уже принимать решение.
Пардон, это профессиональная привычка такая - нельзя делать выводов из незнания...
Vladimir Kladov (2007-09-01 09:36:00) [7]Принял, сейчас буду смотреть и готовить обновление.
Если old_align и работает нечаянно правильнее в каком-то экзотическом случае, это еще не повод отказываться от new_align, кода в нем все-таки меньше. Гораздо хуже ситуация, когда выравнивание неправильно происходит в обычном случае. У меня тут что-то такое проскакивало: если форма отурыта сразу маленького размера, и выравниваемый родитель не виден то начинаются глюки с выравниванием. Пока у себя поборол, вообще отказавшись от выравнивания (размещая контролы своим кодом), но это не дело, конечно. И если old_align справляется, то придётся тогда к нему все-таки возвратиться.
Anchors и Align вообще-то несовместимы, по крайней мере, что было мне прислано, я там вообще не вижу смысла в такой конструкции: одновременно прицеплять якоря и выравнивать контрол caBottom. (А в VCL я вообще anchor's стараюсь не пользовать, глючно очень. После сдвига размера в меньшую строну контрол может так уехать, что потом и не вернётся на родное мето).
MTsv DN (2007-08-31 20:26:00) [8]2 Kladov
Вам очередное письмо... Опять на два ящика...извиняюсь...
MTsv DN (2007-08-31 18:46:00) [9]2 Galkov
Да я не разбирался в коде KOL.PAS по этому поводу. Просто "вылезло", по мне кажется "косяк", тем более, что при OLD_ALIGN все работает нормально...
mdw (2007-08-31 17:50:00) [10]Функци RegKeySetStr и RegKeySetStrEx + UNICODE_CTRLSобрезают строку на половину. Нужно умножать на размет KOLChar. Вот исправленный вариант:
function RegKeySetStr( Key: HKey; const ValueName: KOLString; const Value: KOLString ): Boolean;
begin
Result := (Key <> 0) and (RegSetValueEx( Key, PKOLChar( ValueName ), 0,
REG_SZ, PKOLChar(Value),
SizeOf( KOLChar ) *( Length( Value ) + 1 ) ) = ERROR_SUCCESS);
end;
function RegKeySetStrEx( Key: HKey; const ValueName: KOLString; const Value: KOLString;
expand: boolean): Boolean;
var dwType: DWORD;
begin
dwType := REG_SZ;
if expand then
dwType := REG_EXPAND_SZ;
Result := (Key <> 0) and (RegSetValueEx(Key, PKOLChar(ValueName), 0, dwType,
PKOLChar(Value), SizeOf( KOLChar ) *( Length( Value ) + 1 )) = ERROR_SUCCESS);
end;
vampir_infernal (2007-08-31 16:01:00) [11]//BUGREPORT
При установленных директивах UNICODE_CTRLS и DEBUG_CREATEWINDOW модуль KOL.pas не компилируется. Исправления:
(9920)function SysErrorMessage(ErrorCode: Integer): string; ---> function SysErrorMessage(ErrorCode: Integer): KOLstring;
(13506)function SysErrorMessage(ErrorCode: Integer): string; ---> function SysErrorMessage(ErrorCode: Integer): KOLstring;
(31885)MessageBox(0,PChar(SysErrorMessage(GetLastError)),'Error creating window',mb_iconhand); ----> MessageBox(0, PKOLChar(SysErrorMessage(GetLastError)),'Error creating window',mb_iconhand);
Galkov (2007-08-31 15:53:00) [12]2 MTsv DN
А как там Alignвообще будет работать, если егойный аттач блокирует WM_SIZE
function WndProcToolbarCtrl(Self_: PControl; var Msg: TMsg; var Rslt: Integer): Boolean;
....
if Msg.message = WM_WINDOWPOSCHANGED then
begin
if Assigned( Self_.fOnResize ) then
Self_.fOnResize( Self_ );
Result := TRUE;
Rslt := 0;
end
....
MSDN:
> By default, the DefWindowProc function sends the WM_SIZE and WM_MOVE messages to the window. The WM_SIZE and WM_MOVE
> messages are not sent if an application handles the WM_WINDOWPOSCHANGED message without calling DefWindowProc
Вроде и не должен...
MTsv DN (2007-08-31 12:02:00) [13]Еще "косяк" один. При NEW_ALIGN (который по умолчанию) не происходит выравнивание, если Parent тулбар, т.е. код:
BitBtn1.Align := caRight;
BitBtn1.Parent := ToolBar1;
единожды выравнивает кнопку на тулбаре по правой стороне при устновке Parent'а, а при ресайзе окна выравнивания не происходит...
Vladimir Kladov (2007-08-28 21:18:00) [14]Так, пока с обновлением KOL притормаживаем-с, уже извините. Но хочется подождать до какого-то решения пары недавно заданных вопросов. Пока выложил обновление для KOLGraphic и KOLGif (mmx-оптимизация, safe-загрузка, частичная коррекция сбойных изображений при загрузке).
Vladimir Kladov (2007-08-26 19:56:00) [15]Вчера неожиданно установилась погода (позор гидромету) и пришлось отложить обновления и ехать на дачу делать дела. Обновления - завтра.
Andrey_rus (2007-08-25 02:23:00) [16]> GRAPHCTL_XPSTYLES
> 13 кил кода впридачу
Ужас.
> а вот RICHEDIT_XPBORDER сильно
> пригодился бы
Я бы даже сказал - Жизнено.
Vladimir Kladov (2007-08-24 17:02:00) [17]Аж 4. Я забыл сказать что vk@ работает нормально, и не надо дублировать на zoomer@. Завтра буду обновлять, никуда не поеду, дождь.
MTsv DN (2007-08-24 09:17:00) [18]> он у меня и так местами патчится :)
;)
> просто темы и без графических контролов были вполне себе ничего - кнопки округлые, групбоксы цветные, округлые. hottrack везде. что еще надо ? :)
Были "косяки". Например, вложенные группбоксы, не отрисовывались панели и битбаттоны, ну и табы конечно...
2 Кладов
Вам письмо.
GMax (2007-08-24 00:33:00) [19]MTsv DN © [27]
он у меня и так местами патчится :)
просто темы и без графических контролов были вполне себе ничего - кнопки округлые, групбоксы цветные, округлые. hottrack везде. что еще надо ? :)
а с GRAPHCTRL все панели белыми делаются - так вся прога белая становится, там для корректного красивого ресайза все на панелях лежит...
mdw (2007-08-22 18:58:00) [20]
> Кстати, MTsv DN, обрати внимание на [18].
Я уже видел. Обновлю, как только определимся с http://www.delphimaster.ru/cgi-bin/forum.pl?id=1187786759&n=10.