Версия 2.78

← →
Vladimir Kladov (2007-08-17 20:02) [0]

Новости от 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 так же имеется в архиве.

← →
iNSiDE © (2007-08-18 00:37) [1]

Этого файла нет на kolmck.net. Ссылка есть, а файла нет

← →
Vladimir Kladov (2007-08-18 08:16) [2]

Какого? http://www.kolmck.net/upd/kolmck277to278.zip - уже есть. Опять t не пропечаталась.

← →
iNSiDE © (2007-08-18 13:11) [3]

Да, уже есть). Вчера не было,я сразу и писанул...

← →
iNSiDE © (2007-08-18 23:30) [4]

Решил я поразбираться с KOL и MCK, я не эксперт, я вообще ламер... Но вообщем цитирую справку:

III. НАЧАЛО НОВОГО ЗЕРКАЛЬНОГО ПРОЕКТА

.....

6. В Delphi5 (только), необходимо теперь прописать в опциях САМОГО ПРОЕКТА путь к сервисным модулям:
Project | Options | Directories/Conditionals | Search path
и вписать сюда: $(Delphi)\Source\ToolsApi
(возможно ввести этот путь в список Library path в Tools | Environment options | Library один раз, чтобы больше не заботиться об этом).
.....

Дело в том что в Delphi 7 мне тоже потребовалось вписать сие туда, так как был не найден файл exptintf.dcu. Это при том, что когда я ставил КОЛ годик назад у меня все было без малейших проблем... Так задумано (тогда поправьте в справке), или я криворукий (это однозначно конечно ;) )?

← →
=BuckLr= (2007-08-19 00:14) [5]

> не найден файл exptintf.dcu

типичная проблема, которая лечится билдом. Пути тут ни при чём, выкинь их из library...

← →
iNSiDE © (2007-08-19 10:49) [6]

Спасибо, выкину...

← →
Lex1 (2007-08-21 11:44) [7]

Vladimir Kladov
«Добавлен пакет spellCheck»
Что-то он ничего не проверяет. Компилируется без ошибок, но нажатие на Check только запускает невидимый winword (каждое нажатие). OfficeXP, если что.

«Thirst published:»
Это ирония или опечатка? ;)

← →
mdw © (2007-08-21 11:46) [8]

Доступно на
http://www.kolnmck.ru

← →
Vladimir Kladov (2007-08-21 17:55) [9]

у меня spellCheck работает. MS Office 97.

← →
Stan (2007-08-21 18:37) [10]

Владимир к Вам просьба, - Вы не могли бы писать слова без пробелов между буквами. Ведь неудобно же читать. А?

← →
Vladimir Kladov (2007-08-21 19:10) [11]

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

← →
MTsv DN © (2007-08-21 19:31) [12]

+1

Правильно. Клава меньше снашиваться будет :-D

← →
homm © (2007-08-21 19:32) [13]

Плюсодин :)

← →
Vladimir Kladov (2007-08-21 20:42) [14]

Вообще, я не понял, где я напихал столько много проблов чтобы действительно стало неудобно читать мои посты. Пробелы, по-моему, могут только улучшить читабельность, но не ухудшить ее. Пробелы которые вставляются автоформатером в новостях, нужны для выравнивания текста по правому краю, и вряд ли ухудшают чтение. А в последнее время, да, я стал больше делать опечаток: мне вернули из ремонта ноутбук, а у него клавиши мельче, пальцы мимо попадают, и некоторые символы плохо пропечатываются уже, надо клаву разбирать и чистить, давно не делал (особенно "."-"?"-"/" достаёт, нужно особенно сильно нажимать, чтобы появилась).

← →
homm © (2007-08-21 21:08) [15]

Извиняюсь, что сюда, думаю так быстрее ответ получить.

Владимир, Вы писали: В новой версии достаточно создать и запустить KOLDirDlgEx с символом USE_GRUSH (нужен ToGRush), и поводить мышкой по кнопкам.

Я кидаю на форму KOLOpenDirDialog, ставлю у него AltDialig = TRUE, пишу ODD.Execute, запускаю, вижу явно не то, что было на скриншоте. Здесь просто дерево папок, и 2 кнопки, ок, отмена. Не тот компонент? Не те опции? Не туда смотрю?

← →
Vladimir Kladov (2007-08-21 21:16) [16]

А забыл: надо опцию DIRDLGEX_LINKSPAGE и LinksPageOn := true;

А мыло? Разве медленнее.

← →
GMax (2007-08-21 21:23) [17]

>>>Символ RICHEDIT_XPBORDER удалён и его функцию выполняет GRAPHCTL_XPSTYLES.

а вот это зря по-моему...

← →
homm © (2007-08-21 21:35) [18]

> А мыло? Разве медленнее.
Для меня — точно да :)

Что-то я вообще туплю. KOLDirDlgEx — модуль был в сборке на kolnmck (качал отдельно KOL и MCK), но в нем нет ни DIRDLGEX_LINKSPAGE, ни LinksPageOn (проверил поиском). Думаю, может MTsv DN забыл обновить в отдельных сборках, пошел на Ваш сайт, там не нашел отдельного DirDlgEx.

← →
Vladimir Kladov (2007-08-21 21:40) [19]

У меня на kolmck.net в архиве koladd.zip лежит, на первой странице есть. Если не вру, прямой линк: http://kolmck.net/KOLadd.zip

...Зря, конечно. Я это MTsvDN говорил. visual_xp_styles еще привирают маленько, в Zoomer я их вставить не смогЮ там привирает еще не маленько, даже с новыми исправлениями которые еще только будут в 2.79.

← →
homm © (2007-08-21 21:47) [20]

Да что за напасть :(
procedure TOpenDirDialogEx.RemoveLinkClick(Sender: PMenu; Item: Integer); Pn := Sender.CurCtl;

[Error] KOLDirDlgEx.pas(915): Undeclared identifier: "CurCtl"

← →
Vladimir Kladov (2007-08-21 21:52) [21]

Ну так там же в самом начале написано, что Also USE_MENU_CURCTL symbol must be added!

← →
homm © (2007-08-21 21:58) [22]

> DIRDLGEX_LINKSPAGE и LinksPageOn

Page -> Panel

ODD.LinksPanelOn; ODD.Execute;
Ничего, все тот-же диалог с двумя кнопками.

← →
homm © (2007-08-21 22:08) [23]

Сделал так:
var s: PStrList; begin s := NewStrList(); s.Add("C:\"); s.Add("d:\"); s.Add("e:\"); ODD.LinksPanelOn; ODD.AddLinks(s); ODD.Execute; S.Free;

Появилась кнпочка сострелочкой плево, по нажатию на которую ничего не происходит.

← →
Vladimir Kladov (2007-08-21 22:19) [24]

LinksPanelOn := true;

Я выслал мылом проект. Мне завтра на работу рано вставать, я пошёл баиньки.

← →
homm © (2007-08-21 22:38) [25]

NewPanelWithSingleButtonToolbar
Очень странная, надо сказать функция. Надло же экономить системные рессурсы, а здесь 3 окна создаеться, там где можно одни обойтись. Впрочем вникать в каких извращенных ситуациях она нужна, мне не охото :)

В ней есть строка PGRushControl( Bar.Children[0] ).All_ColorOuter := AParent.Color;
В двух словах
Закоментируйте ее.

Более пордробно
Я еше в первом письме сказал, что похоже на совпадения одного из цветов заливки с ColorOuter. Уж так устроенны граш, что этот цвет береться за прозрачный при блитинге. Я там же еще сказал, что не похоже что увас там прозрачность, потому глюк может быть в другом, но я же не знал, что там 3 контролла один на другом.

«В GRush Глюков нет!»
© Впервые использовано в личной переписке с ANTPro :)

← →
GMax (2007-08-22 00:24) [26]

>>>Символ RICHEDIT_XPBORDER удалён и его функцию выполняет GRAPHCTL_XPSTYLES.

дело даже не в самих GRAPHCTL_XPSTYLES, а в отсутствии выбора :)
мне как раз всё остальное не надо, особенно белые табы, да еще и 13 кил кода впридачу, а вот RICHEDIT_XPBORDER сильно пригодился бы

← →
MTsv DN © (2007-08-22 09:39) [27]

> Я это MTsvDN говорил.
Я лишь предложил. По мне, если уж подключать поддержку тем, то одной директивой. В принципе, можно вообще на каждый контрол сделать свою директиву.

> дело даже не в самих GRAPHCTL_XPSTYLES, а в отсутствии выбора
> :)
> мне как раз всё остальное не надо, особенно белые табы,
> да еще и 13 кил кода впридачу, а вот RICHEDIT_XPBORDER сильно
> пригодился бы
Ну, не знаю. Открытый код, комменты и всякое такое прочее...возьмите и подкорректируйте KOL.PAS под свои нужды...тем более делов, несколько слов заменить. Лично я постоянно при выходе новой версии кое-где правлю код, под свои проекты. А причину, по которой предложил убрать RICHEDIT_XPBORDER, читайте выше...

← →
Vladimir Kladov (2007-08-22 15:15) [28]

Вот оно что. А почему же отказ от SystemGradientFill устранил проблему. Я этот OuterColor присвоил, когда боролся с уголками, хотя, похоже, так и не помогло: мне надо было получить определённый цвет уголков, чтобы на кнопках которые лежат на тёмном фоне, уголки тоже были тёмные, а не светлые. Потом я просто сделал светлую панель, чтобы не мучиться, а присваивание не убрал, слишком много параметров все не запомнить зачем какое.

← →
Andrey_rus © (2007-08-22 15:22) [29]

>>Символ RICHEDIT_XPBORDER удалён и его функцию выполняет
> GRAPHCTL_XPSTYLES.а вот это зря по-моему...
Солидарен. А много добавляет код и данные при использовании GRAPHCTL_XPSTYLES?

← →
homm © (2007-08-22 18:38) [30]

> А почему же отказ от SystemGradientFill устранил проблему.

«Не верь глазам своим»© :)
На самом деле эта переменная не только за градиент отвечает, она отвечает за обе функции, импортируемые из библиотеки msimg32.dll.

procedure myDrawTransparent(Bitmap: PBitmap; DC: HDC; X: Integer; Y: Integer; Color: TColor); var bW, bH: integer; begin bW := Bitmap.Width; bH := Bitmap.Height; Color := Color2RGB(Color); if UseSystemGradient then SysTransparentBlt(DC, X, Y, bW, bH, Bitmap.Canvas.Handle, 0, 0, bW, bH, Color) else Bitmap.DrawTransparent(DC, X, Y, Color); end;

> мне надо было получить определённый цвет уголков
Для этого не обязательно делать компонент прозрачным, если цвет и так один и тот же.

← →
homm © (2007-08-22 18:39) [31]

Кстати, MTsv DN, обрати внимание на [18].

← →
MTsv DN © (2007-08-22 18:55) [32]

2 homm
Я читал...только, если я за компом хотя бы раз в неделю, сейчас, бываю, это уже хорошо. Все предложения на мыло mdw.

← →
mdw © (2007-08-22 18:58) [33]

> Кстати, MTsv DN, обрати внимание на [18].

Я уже видел. Обновлю, как только определимся с http://delphimaster.net/view/11-1187786759/ .

← →
GMax (2007-08-24 00:33) [34]

MTsv DN © [27]
он у меня и так местами патчится :)

просто темы и без графических контролов были вполне себе ничего - кнопки округлые, групбоксы цветные, округлые. hottrack везде. что еще надо ? :)

а с GRAPHCTRL все панели белыми делаются - так вся прога белая становится, там для корректного красивого ресайза все на панелях лежит...

← →
MTsv DN © (2007-08-24 09:17) [35]

> он у меня и так местами патчится :)
;)

> просто темы и без графических контролов были вполне себе ничего - кнопки округлые, групбоксы цветные, округлые. hottrack везде. что еще надо ? :)
Были "косяки". Например, вложенные группбоксы, не отрисовывались панели и битбаттоны, ну и табы конечно...

2 Кладов
Вам письмо.

← →
Vladimir Kladov (2007-08-24 17:02) [36]

Аж 4. Я забыл сказать что vk@ работает нормально, и не надо дублировать на zoomer@. Завтра буду обновлять, никуда не поеду, дождь.

> GRAPHCTL_XPSTYLES
> 13 кил кода впридачу
Ужас.

> а вот RICHEDIT_XPBORDER сильно
> пригодился бы
Я бы даже сказал - Жизнено.

← →
Vladimir Kladov (2007-08-26 19:56) [38]

Вчера неожиданно установилась погода (позор гидромету) и пришлось отложить обновления и ехать на дачу делать дела. Обновления - завтра.

← →
Vladimir Kladov (2007-08-28 21:18) [39]

Так, пока с обновлением KOL притормаживаем-с, уже извините. Но хочется подождать до какого-то решения пары недавно заданных вопросов. Пока выложил обновление для KOLGraphic и KOLGif (mmx-оптимизация, safe-загрузка, частичная коррекция сбойных изображений при загрузке).

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

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

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

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

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

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

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

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

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

Ну ладно, здесь уже про другое писать вроде не будут, поэтому помусолить 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 Найти похожие ветки