Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

распознание выполнения события формы

Страницы: 1 2 >
вопрос © (2005-03-06 14:54:00)
Народ, кто-нить знает как можно из компонента узнать, что в форме, на которой он лежит выполнилось событие OnShortCut, не прописывая никаких кодов в обработчик этого события.

Набережных С. (2005-03-07 22:32:00) [1]

> jack128 © (07.03.05 22:11) [24]

А тем, что про TApplicationEvents в хелпе написано, что он предназначен для того, чтобы присваивать обработчики событий невизуального Application из IDE. Это его назначение, для этого он сделан, больше ни для чего. Именно это его функция. Вот если ты создашь компонент, назначением которого будет подменять чужие оконные процедуры, то это будет вполне нормальный компонент. А если это побочный эффект, то даже описав его в хелпе, ты лишишь возможности программиста использовать совместно с ним другие компоненты, с совершенно с другой функциональностью, но тоже подменяющие оконную процедуру - их авторы придерживаются тех же воззрений, что и ты. Чем они хуже тебя?

Все, это последний пост. Я действительно устал, да и говорить, на мой взгляд, тут больше не о чем.

Palladin (2005-03-07 22:16:00) [2]
Эээ... сначала не читал, но с описанным сталкивался, создавал класс (не компонент, я их не перевариваю почемуто) со стеком обработчиков... при присваивании все это дело сохранялось и возникала цепочка вызовов...
Единственный момент, это создавалось для конкретной задачи и конкретного класса. Точнее динамической объектной иерархии... Именно для этого очередь обработчиков и создавалась...

jack128 (2005-03-07 22:11:00) [3]
Набережных С. © (07.03.05 22:04) [23]
Беда в том, что компоненты A и В созданы разными производителями.

Так почему же TApplicationEvents хорош то?? Ведь вполне может существовать другой компонент, который подменяет cобытия TApplication и он точно так же не будет работать при использовании совместно с TApplicationEvents. Или все его приемущество в том, что он _стандартный_и о нем знают все разработчики компонентов?
Набережных С. © (07.03.05 22:04) [23]
а я старый дурак, что ввязался в этот спор
что ж ты так? объясни подрастающему поколению в чем оно не право?

Набережных С. (2005-03-07 22:04:00) [4]

> jack128 © (07.03.05 21:51) [22]

Да я-то предполагаю...О-хо-хо...Беда в том, что компоненты A и В созданы разными производителями. Оба они живут весело и счастливо, но один в Самаре, а другой в Париже...Какой список?

> Например, я решил эту задачу с помощью подмены процедур

Ну, а другой SuperControl тоже решил свою задачу подобным образом, подменив оконную процедуру твоего TMySuperWinControl своей, наплевав глубоко на то кто там у кого родитель. Зачем ему понадобилось? А я откуда знаю? Tго производитель ни со мной, ни с тобой не знаком.

Все, я устал. Ты прав, а я старый дурак, что ввязался в этот спор:(

jack128 (2005-03-07 21:51:00) [5]
Набережных С. © (07.03.05 20:55) [21]
Объясни, что здесь не правильно
А ты не предполагаешь, что компонент можно реализовать так, чтобы полобных коллизий не возникало?
Например, хранить список подменённых процедур в списке(TList).

Да и в конце концов возможна такая ситуация, что таких ошибок не может быть в принципе. Например мне нужен такой TMySuperWinControl, который бы получал извещения обо всех сообщения своих детей. Например, я решил эту задачу с помощью подмены процедур. Когда контрол встовляется в список Controls моего TMySuperWinControl, я подменяю его WindowProc, когда удаляется - возвращаю обратно. Так как у Control'a не может быть двух родителей, то коллизий описанных тобой тоже быть не может.

Набережных С. (2005-03-07 20:55:00) [6]

> Создаем TApplicationEvents. Назначаем ему события.
> Подменяем событие Application

Вручную, собственными руками.
Или назначаем обработчик Application.On... в одном модуле, а потом делаем то же самое в другом. Ситуация один в один. Ничем не отличается, ни малейшим образом. Я уже писал в [15], что такое не лечится.

> Если просто создать и уничтожить , то ничего не произойдет.
> Нужно вручную лесть в оконные процедуры, вот тогда произойдет.

Создаем один компонент(А), который запоминает WindowProc(1) целевого объекта и подставляет свою(2). Создаем второй объект(В), который так-же запоминает оконную процедуру, но уже(2), и подставляет свою(3). Уничтожаем первый компонент(А), он при этом восстанавливает "исходную" процедуру(1). Объект (В) остался не при делах. Уничтожаем (В). Он восстанавливает (2) уже несуществуещего объекта (А), затерев "родную" (1) целевого объекта. Программист не сделал ничего противозаконного, просто создал и уничтожил пару чужих компонентов. Не притронулся даже ни к чьей процедуре, но поимел конкретные проблемы. За что?
Объясни, что здесь не правильно или неочевидно?

jack128 (2005-03-07 20:35:00) [7]
jack128 © (07.03.05 20:30) [19]
принципиальнаясорри.

jack128 (2005-03-07 20:30:00) [8]
Набережных С. © (07.03.05 19:43) [17]
С TApplicationEvents нужно явно напортачить, собственными руками. Компонент, подъменяющий WindowProc достаточно просто создать и уничтожить.
Создаем TApplicationEvents. Назначаем ему события.
Подменяем событие Application
Получаем неработающий TApplicationEvent

Или

Создаем компонент, назначаем ему какие то свойства, в результате которых происходит подмена оконных процедур у контрола.
Заменяем вручную оконную процедуру у конторола
Получаем неработающий компонент.

Где пренципиальная разница в этих двух сценариях, из - за которой TApplicationEvent ты считаешь хорошим компонентом, а "мой" - плохим?

Набережных С. © (07.03.05 19:43) [17]
Компонент, подъменяющий WindowProc достаточно просто создать и уничтожить
Если просто создать и уничтожить , то ничего не произойдет. Нужно вручную лесть в оконные процедуры, вот тогда произойдет.

Набережных С. (2005-03-07 19:56:00) [9]
Дело не в подмене чего-то, не в перекрытии каких-то методов, а в последствии таких действий, в предсказуемости и очевидности этих последствий, либо в отсутствии таковой. Нет, не знаю, что тут может быть не понятно:(

Набережных С. (2005-03-07 19:43:00) [10]

> jack128 © (07.03.05 19:27) [16]

[15] не разъяснило? С TApplicationEvents нужно явно напортачить, собственными руками. Компонент, подъменяющий WindowProc достаточно просто создать и уничтожить. Не убеждает? Тогда я пас:(

jack128 (2005-03-07 19:27:00) [11]
Набережных С. © (07.03.05 18:06) [15]
о чем тут спорить?
спорить то не о чем.

Мне просто непонятна логика, по которой один компонент, подменяющий события(TApplicationEvents) был отнесен к хорошо написанным компонентам, а другой компонент, подменяющий события (WindowProc - это ведь событие) к плохо написанным...

Набережных С. (2005-03-07 18:06:00) [12]

> jack128 © (07.03.05 17:31) [14]

Неужели не понятно? Вот программист бросает на форму TApplicationEvents, кликает в инспекторе, заполняет заготовку обработчика в модуле. А строкой ниже уже кодом переназначает только что назначенный через TApplicationEvents обработчик. Один и тот же человек. Так что-ли? Такое уже не лечится. Пользователь компонента может вообще не заглядывать в исходники компонента, ему время дорого, для того и компоненты. У него может просто не быть исходников. Написать в хелпе? А если это делают несколько компонент от разных производителей? В общем, дело этики и профессионализма автора компонента, о чем тут спорить? Думаю, Юрий Зотов может это лучше меня изложить.

jack128 (2005-03-07 17:31:00) [13]
Набережных С. © (07.03.05 15:41) [12]
Он предназначен для авторов программ, а не для авторов компонентов.
В продолжение разговора из прошлой ветки.

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

Erik1 (2005-03-07 16:56:00) [14]
И чем тебе ответы в преведущей ветки неподошли? Я уже написал как такое коректно без хуков реализовать.

Набережных С. (2005-03-07 15:41:00) [15]
Имхо, как раз TApplicationEvents реализован вполне нормально. Он предназначен для авторов программ, а не для авторов компонентов. И предполагает, что программист, назначив обработчик через этот компонент, не станет делать того же в коде. Другое дело - компонент. Использующий его вправе ожидать от него корректного поведения, не мешаещего вполне нормальному коду приложения или работе того же TApplicationEvents.

GuAV (2005-03-07 14:38:00) [16]
ИМХО не только для "батонокидателей со стажем". C ним удобнее назначить несколько обрбаботчиков, например на OnIddle или OnMessage.

Германн (2005-03-07 03:50:00) [17]
2 jack128 © (07.03.05 03:14) [9]
Увы, не знал.
Но в Д4, точно. Такого компонента нет в стандартной поставке!

Сейчас проверил. В Д6 - действительно такой компонент есть!

jack128 (2005-03-07 03:14:00) [18]
Германн © (07.03.05 2:56) [8]
Токмо, конечно, Вы имели в виду не VCL, а "стороннюю библиотеку RX? Она же теперь JEDI!
причем тут RX? Покрайней мере начиная с D5(а может и раньше) этот компонент идет в стандартной поставке Дельфи

Германн (2005-03-07 02:56:00) [19]
2 jack128 © (07.03.05 02:21) [7]
> Юрий Зотов © (06.03.05 22:14) [4]
>кстати, нечто похоже есть в VCL. Это компонент >TApplicationEvents

Ну тут "и да и нет". Имхо, компонент TApplicationEvents создан для "батонокидателей со стажем". Точнее для тех из них, которые уже научились создавать обработчики через ObjectInspector. :)

Токмо, конечно, Вы имели в виду не VCL, а "стороннюю библиотеку RX? Она же теперь JEDI!

jack128 (2005-03-07 02:21:00) [20]
вопрос (06.03.05 14:54)
а тебе одной ветки уже мало показалось? http://www.delphimaster.ru/cgi-bin/forum.pl?id=1109775581&n=12

Юрий Зотов © (06.03.05 22:14) [4]
кстати, нечто похоже есть в VCL. Это компонент TApplicationEvents

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

Наверх

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