Версия 2.54

← →
Vladimir Kladov (2007-02-25 20:14) [0]

Новости от 25 февраля 2007 (KOL & MCK v2.54)

[-]
ASM
Метод TBitmap.Convert2Mask (asm-версия) исправлен для случая 256 цветов (pf8bit).

[-]
MCK
Удалены дублирующие присваивания свойству Name (для символа USE_NAMES) для некоторых объектов (наследников TKOLObject). Присваивание свойству Name для TKOLDataModule исправлено (объект сохраняется в списке самого объекта, а не в Applet, т.к. он разрушается после разрушения объекта Applet и финальная очистка имени приводила к краху приложения на завершении).

Не в ту тему сначала отправил.

← →
MTsv DN © (2007-02-26 14:31) [1]

Обновление доступно на http://www.kolnmck.ru

← →
AndreyRus (2007-02-28 13:41) [2]

Ошибка работы обработчика события завершения работы операционной системы не исправлена? :)

← →
Vladimir Kladov (2007-02-28 20:08) [3]

Нет ошибки. Если вы считаете, что вам нужна такая обработка, устанавливаете соответствующий обработчик. Всем делать этот обработчик - противоречит принципу "только минимум необходимого кода".

← →
AndreyRus (2007-03-01 13:53) [4]

Я предполагаю, что на эти грабли будут наступать очень многие, особенно те, кто ранее использовал VCL, где обработчик формы - onDestroy срабатывал и при обычном завершении работы приложения (alt+F4) и при завершении работы операционной системы (WM_QueryEndSession). И это логичное и правильное поведение обработчика - onDestroy. Я совершенно случайно обнаружил эту особенность поведения КОЛ. Хорошо, что в обработчике не использовалось критического finally. А ведь это могло привести к большим неприятностям...

> Всем делать этот обработчик - противоречит принципу "только минимум необходимого кода".
Не думаю, что обработчик события "WM_QueryEndSession" и последующий вызов onDestroy добавит много кода, вероятнее всего лишь десяток байт :)

← →
ANTPro © (2007-03-01 14:47) [5]

> [4] AndreyRus (01.03.07 13:53)
> и при завершении работы операционной системы (WM_QueryEndSession)
> . И это логичное и правильное поведение обработчика - onDestroy

+1

← →
Vladimir Kladov (2007-03-01 17:35) [6]

У Applet"а есть OnQueryEndSession. Ставите свой обработчик, и какие проблемы. Далеко не все приложения по завершении работы системы обязательно должны контролировать этот факт, и что-то при этом специальное делать.

← →
homm © (2007-03-01 22:15) [7]

> Далеко не все приложения по завершении работы системы обязательно
> должны контролировать этот факт, и что-то при этом специальное делать.
Насколько я понимаю речь как раз о том что нужно делать что-то не спецально, а как раз стандартно. Что-бы поставив обработчик OnDestroy программист мог быть уверен что он сработает при любой ситуации, когда программа коректно выгружается. Чем завершение работы хуже сочетания alt+f4???

← →
AndreyRus (2007-03-01 22:48) [8]

> Чем завершение работы хуже сочетания alt+f4???

+1

← →
Vladimir Kladov (2007-03-02 07:57) [9]

Процедура обработки WM_QUERYENDSESSION занимает 134 байта. Этим и хуже. По крайней мере половина программ работают не с документом, который редактируют, а просто исполняют какой-нибудь сервис, например, сидя в трее. И им напрочь не надо ничего особого делать по завершении работы. Если надо, ставите обработчик, и в нем Form.Close - самый простой путь получить свои OnDestroy, OnClose и т.д.

← →
Vladimyr © (2007-03-05 22:27) [10]

+1 :)

← →
Barloggg (2007-03-13 11:04) [11]

гм. а чего это событие onSbScroll срабатывает дважды при движении ползунка на TScrollBar?

← →
Vladimir Kladov (2007-03-13 17:37) [12]

Хоть 20. Ваш код не должен зависеть от количества таких вызовов. Например, OnMouseMove срабатывает регулярно, даже если мышь никуда не движется. У вас не вызывает это отрицательных эмоций?

← →
Barloggg (2007-03-13 18:03) [13]

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

а еще забавен тот факт что правильное значение SbPosition иногда приходит именно со вторым сообщением (когда ползунок упирается в планку).
а это знаете ли шкала масштаба. а картинку масштабировать бывает напряжно почем зря.
теперь везде стоят флажки, но недоумение все равно осталось.

это типа винда перестраховывается? :)

← →
AndreyRus (2007-03-15 15:59) [14]

> Процедура обработки WM_QUERYENDSESSION занимает 134 байта.

А чего так много... Это ведь просто сравнение и переход. Должно быть байтов 10.

← →
Vladimir Kladov (2007-03-15 17:22) [15]

Защитный диапазон ставится в несколько строк кода и один таймер. Если для вас действительно это актуально.

OnMouseMove срабатывает регулярно, если курсор находится в окне. Так работает Windows. Можете просто завернуть мышь в тряпочку, перевернуть вверх ногами и положить на кусочек поролона, обработчик будет срабатывать.

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

← →
Vladimir Kladov (2007-03-15 17:30) [16]

> Процедура обработки WM_QUERYENDSESSION занимает 134 байта.
А чего так много... Это ведь просто сравнение и переход. Должно быть байтов 10.

Код открыт, смотрите, что там еще делается.

← →
D[u]fa © (2007-03-15 18:28) [17]

Vladimir Kladov, так может добавить их? =)
10 байт не так много ведь..

← →
AndreyRus (2007-03-15 18:53) [18]

> Код открыт, смотрите, что там еще делается.

Посмотрел. На мой взгляд - это неправильный подход с точки зрения статистики использования обработчика "WM_QUERYENDSESSION". Он нужен далеко не всем, а вот вызов деструктора программы при завершения работы операционной системы нужен очень даже часто. Очень многие разработчики программ уповают на то, что если они назначили обработчик уничтожения программы - "onDestroy", то он должен вызываться при всех возможных способах завершения программы, кроме жеского "терминирования" процесса диспечером задач.

← →
Vladimir Kladov (2007-03-16 20:40) [19]

Вопрос - зачем. Чтобы ресурсы освоюодить? Система завершается, все ресурсы и так будут освобождены, даже в 9х. В NT так вообще достаточно завершить приложение, и все ресурсы освободятся максимально быстро и эффективно. Документ сохранить? Далеко не всем программам это нужно. А если нужно, я уже решение указал. Назначаете обработчик, который даже ничего не делает. И все.

Если 10 байт нужны 10% программ, то по правилам KOL, за добавление этих 10 байт отвечает программист. Чтобы остальные 90% программ были на 10 байт короче.

← →
AndreyRus (2007-03-16 21:45) [20]

> Если 10 байт нужны 10% программ, то по правилам KOL, за
> добавление этих 10 байт отвечает программист.

Далеко не 10%-ам, IMHO, больше половины. Например, операции изменения файла (шифрование, сжатие). Файловая система, это вам, не сочтите за наглость, не SQL сервер. Автоматические транзакции отсутствуют. Последствия... катастрофические. А ведь это изменение в КОL прошло практически незамеченным. Разработчики будьте внимательны! Уважаемый Владимир! Мне кажется, что нарушение идеологии OOП в ущерб размеру программ недопустимо. Энтропия не пройдет!

← →
Galkov © (2007-03-16 22:27) [21]

> что нарушение идеологии OOП в ущерб размеру программ недопустимо

С этого момента, по-подробнее, пожалуйста :))

← →
AndreyRus (2007-03-16 23:56) [22]

> С этого момента, по-подробнее, пожалуйста :))

По настоящему, впервые ООП поразило меня в "Turbo Vision", где назначив обрабочик закрытия окна, я не беспокоился о том, как будет закрыто окно (крысой или клавой). ;)

← →
Galkov © (2007-03-17 09:45) [23]

Ах вот оно что такое ООП, оказывается !!!
Дать человеку возможность не думать...

← →
Vladimir Kladov (2007-03-17 15:36) [24]

Это ваше имхо. Из тем десятков программ, которые я накорябал за последние 8 лет, только одной потребовалось обработать завершение винды. Как раз чтобы сохранить "документ" (но ничего при этом не спрашивая у бедного пользователя, в файл типа Autosave. Вы только представьте себе, каково пользователю, с запущенными примерно 15 приложениями будет завершать сессию, если они все начнут что-то спрашивать...). И, кстати, обработка там идет в OnMessage, своя. Наверное OnQueryEndSession еще не существовало.

← →
AndreyRus (2007-03-17 17:41) [25]

> Galkov
> Ах вот оно что такое ООП, оказывается !!!Дать человеку возможность
> не думать...

Не уродствуйте! Не думать... это как? ООП позволяет меньше задумываться о проблемах поведения кода в зависимости от окружающей среды, например OS. Слова инкапсуляция, полиморфизм и наследование вам должны ведь быть знакомы?

> И, кстати, обработка там идет в OnMessage, своя.
> Наверное OnQueryEndSession еще не существовало.

OnQueryEndSession вообще не нужен в KOL! Его реализация очень проста даже для новичка в KOL&VCL и вот он действительно не нужен (+1xx байт).
Но вот обработка родственных событий Windows обязательно должна присутсвовать в логике работы любой программы при ее разрушении.
Владимир, хотите я навскидку назову десяток типов задач (программ) надежность работы которых, при сокращении KOL на эти злосчасные десять байт (сравнение&переход), будет уменьшена ровно на количество (выключений&перезагрузкок, в том числе и аварийных&гибернаций&переходов в режим энергосбережения).

← →
Vladimir Kladov (2007-03-17 18:55) [26]

KOL существует потому, что VCL не дает такой возможности - отказаться от кода, который в данном конкретном приложении не нужен. Даже если бы только 1 приложение из 100 было таким, которое не нуждается в анализе завершения сессии, я был бы вынужден предоставить такую возможность. Единственный способ это сделать - переложить это окончательное решение на программиста. И точка.

← →
AndreyRus (2007-03-17 19:36) [27]

> Даже если бы только 1 приложение из 100 было таким, которое
> не нуждается в анализе завершения сессии, я был бы вынужден
> предоставить такую возможность.

Это неправильный подход, правильный - если больше половине программ это нужно и это можно реализовать "малой кровью", значит лучше так тому и быть. IMHO.

> Единственный способ это сделать - переложить это окончательное
> решение на программиста.

Что влечет за собой неоправданные расходы на изучение особенностей Вашей библиотеки. Уверен, увеличение программ на 10 байт - не повод для появления новой.

← →
Vladimir Kladov (2007-03-18 07:06) [28]

Что влечет за собой неоправданные расходы на изучение особенностей Вашей библиотеки.
Любая библиотека требует изучения. Нежелание читать мануалы и комментарии меня волнует меньше всего. Кто не желает, может и дальше пользоваться VCL, если думает, что им можно пользоваться без изучения VCL.

Есть другое ИМХО :))

KOL тоже не всегда свободен от "подумать за программиста"

Ну, скажем, упомянутый недавно здесь на форуме WM_MOUSEWHEEL.
В KOL уже принято решение за программиста, что обязательно будет вызвано DefWindowProc

Ну и неправильно это, ИМХО (вот оно, другое :))
- даже если иное потребует лишних 10 байт кода
- даже если мало кто знает, чем отличается вызов от невызова
- и потребует дополнительного изучения библиотеки

ЗЫ: это просто пример, на котором интересно посмотреть отношение Автора к аналогичным вопросам.

← →
Vladimir Kladov (2007-03-18 08:49) [30]

OnMessage - и вы можете перехватить и не допустить дальнейшего исполнения ЛЮБОГО сообщения.

Ну, тут технических проблем нет.
Кроме одной: задачи перестают быть "локальными", если несколько динамических объектов цепляются на один и тот же OnMessage. Именно динамических, и именно несколько – проблема при уничтожении динамического объекта, непонятно как удалить именно свой "перехват".

Но главное таки, это то, что OnMessage - все-таки "универсальное" решение.
А то самое "имхо" состояло в том, если делать "персональное" решение, то правильней без "избыточного интеллекта", заключающегося в ограничении возможностей, предоставляемых WinApi.

И, безусловно, без отрицания полезности и такого "персонального" решения
В общем, именно ИМХО :)
И конечно WM_MOUSEWHEEL - это только пример. Можно и еще привести.

← →
GMax (2007-03-19 00:25) [32]

честно говоря, я вообще не понимаю борьбы за 10 байт в данном конкретном случае, тем более, что эти десять байт наверняка растворятся в каком-нибудь alignment"е и на конечный размер exe-шника никак не повлияют.
а вот логике это будет соответствовать. всё-таки Destroy происходит, значит и событие должно быть.

Вот и я про то же... надо было тесты провести, добавить и проверить размер)

← →
Vladimir Kladov (2007-03-19 16:30) [34]

1. я ни с кем не борюсь. В своей правоте уверен, и все уже и так сделал, как считаю нужным и правильным.
2. речь идет не о 10 а о 1хх байтов. Кому непонятно, из чего они складываются, код открыт, смотрите, изучайте.
3. тесты были проведены, и это сокращение было проделано заодно с кучей прочих не так давно. Размер минимального приложения тогда как раз и сократился с 14К до 11.5К. ЭКОНОМЬТЕ БАЙТЫ, КИЛОБАЙТЫ САМИ СЕБЯ СБЕРЕГУТ.

← →
GMax (2007-03-19 23:26) [35]

ну если уж на то пошло, может тогда все-таки дать честную _стандартную_ возможность программисту добиться нужного функционала, как обычно, через IFDEF ?
понятно, что через onMessage можно всё, но ведь и на WinApi можно тоже, однако мы KOL пользуемся ;-)

← →
Vladimir Kladov (2007-03-20 15:39) [36]

Ну а разница-то какая того, что есть - по сравнению с IFDEF? Все равно решение принимает программист. И в обоих случаях, чтобы принять такое решение, он должен быть в курсе, что для этого сделать.

← →
имя (2007-08-08 21:30) [37]

Удалено модератором

← →
имя (2007-10-03 10:12) [38]

Удалено модератором

← →
имя (2007-10-03 10:12) [39]

Удалено модератором

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