Версия 2.78

← →
MTsv DN © (2007-08-31 12:02) [40]

Еще "косяк" один. При NEW_ALIGN (который по умолчанию) не происходит выравнивание, если Parent тулбар, т.е. код:
BitBtn1.Align := caRight; BitBtn1.Parent := ToolBar1;
единожды выравнивает кнопку на тулбаре по правой стороне при устновке Parent"а, а при ресайзе окна выравнивания не происходит...

← →
Galkov © (2007-08-31 15:53) [41]

2MTsv 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

Вроде и не должен...

← →
vampir_infernal (2007-08-31 16:01) [42]

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

← →
mdw © (2007-08-31 17:50) [43]

Функци 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;

← →
MTsv DN © (2007-08-31 18:46) [44]

2 Galkov
Да я не разбирался в коде KOL.PAS по этому поводу. Просто "вылезло", по мне кажется "косяк", тем более, что при OLD_ALIGN все работает нормально...

← →
MTsv DN © (2007-08-31 20:26) [45]

2 Kladov
Вам очередное письмо... Опять на два ящика...извиняюсь...

← →
Vladimir Kladov (2007-09-01 09:36) [46]

Принял, сейчас буду смотреть и готовить обновление.

Если old_align и работает нечаянно правильнее в каком-то экзотическом случае, это еще не повод отказываться от new_align, кода в нем все-таки меньше. Гораздо хуже ситуация, когда выравнивание неправильно происходит в обычном случае. У меня тут что-то такое проскакивало: если форма отурыта сразу маленького размера, и выравниваемый родитель не виден то начинаются глюки с выравниванием. Пока у себя поборол, вообще отказавшись от выравнивания (размещая контролы своим кодом), но это не дело, конечно. И если old_align справляется, то придётся тогда к нему все-таки возвратиться.

Anchors и Align вообще-то несовместимы, по крайней мере, что было мне прислано, я там вообще не вижу смысла в такой конструкции: одновременно прицеплять якоря и выравнивать контрол caBottom. (А в VCL я вообще anchor"s стараюсь не пользовать, глючно очень. После сдвига размера в меньшую строну контрол может так уехать, что потом и не вернётся на родное мето).

← →
Galkov © (2007-09-03 16:39) [47]

Ну ладно, здесь уже про другое писать вроде не будут, поэтому помусолить NEW_ALIGN попробую...
Да и поститься не могу с адекватной частотой - похоже, мой IP сидит в банах у мастеров Дельфи (других проблем мне конечно мало :evil: )

2MTsv 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-03 17:44) [48]

Я не знаю, что такое [41], о котором тут много упоминалось, но с тулбаром могу сказать. Эта сво... пардон, этот контрол не имеет ширины и не может быть выровнен по-человечески. Вместо этого у него есть выравнивание по верхнему краю родительского окна, обеспечиваемое операционкой. И бесконечная вправо ширина. Вот такие вот ноги у этой проблем с этим контролом.

[41] - это номер поста (Ваш - 44-й)
Там ничего военного - цитата из KOL.WndProcToolbarCtrl, и MSDN.WM_WINDOWPOSCHANGED

← →
Vladimir Kladov (2007-09-03 23:21) [50]

я тут посмотрел: если убрать Result := true; , то кнопка выравнивается вправо, и эффект сохраняется и на 95 и на 98. Значит, можно убрать. Видимо, когда писал так, была причина. Align с тех пор много раз исправлялся, а в NEW_ALIGN вообще не тестировалось. Уже сейчас сложно догадаться, что была за причина поставить там предотвращение дальнейшей обработки.

> У меня тут что-то такое проскакивало: если форма открыта сразу маленького размера,
> и выравниваемый родитель не виден, то начинаются глюки с выравниванием

Владимир, если до сих пор проскакивает, или снова начнет - логично намылить (или выложить где ни то) минимизированный проект.
Мне предпочтительней "чистый KOL", но и другие "воспроизводимые" варианты - не есть проблема.

Надо ведь: или - что-то делать, или - что-то решать :)

← →
Vladimir Kladov (2007-09-06 15:30) [52]

Мне было не до шуток, и я по-быстрому убрад Align и сделал своим кодом. Потом я пытался восстановить ситуацию, но ничего не получилось. Так что ждём пока не выскочит еще у кого-нибудь.

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