Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Версия 2.78 [Delphi, KOL/MCK, Windows]


Страницы:   1 2 3

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.


Страницы:   1 2 3

Наверх

Титульная страница Поиск, карта сайта Написать письмо