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

← →
вопрос (2005-03-06 14:54) [0]

Народ, кто-нить знает как можно из компонента узнать, что в форме, на которой он лежит выполнилось событие OnShortCut, не прописывая никаких кодов в обработчик этого события.

← →
вопрос (2005-03-06 16:51) [1]

может какие нибудь мало-мальские предложения есть?

← →
DrPass © (2005-03-06 18:12) [2]

Подменить настоящий обработчик обработчиком из компоненты, а из него вызывать настоящий (плохой метод, если ты собрался распространять свой компонент).

← →
Дмитрий Мыльников (2005-03-06 22:03) [3]

Ну почему плохой. На самом деле единственный, если речь идёт именно о событиях Delphi. О событиях, которые посылает Windows, можно попытаться узнать через перехват нужного сообщения, а вот события, которые работают через функции обратного вызова, можно только подставив свою функцию, запомнив во внутренней переменной старое значение. Если там что-то было, то нужно не забыть его вызвать (в начале или в конце определяется логикой работы).
Большинство серьёзных компонентов, те же DevExpress используют подобную технику (посмотрите в исходниках сами, если не верите).

← →
Юрий Зотов © (2005-03-06 22:14) [4]

> Дмитрий Мыльников (06.03.05 22:03) [3]

> Большинство серьёзных компонентов, те же DevExpress
> используют подобную технику...

Позвольте утверждать обратное - ни один серьёзный компонент (и уж тем более DevExpress) подобную технику НЕ использует. Потому что стоит мне в своей программе написать что-то вроде
OnSomeEvent := MyEventHandler
и компонент работать перестанет.

Есть железный закон - компонент не имеет права использовать события, доступные юзеру. Это азбука, которую обязан знать каждый разработчик компонентов. Тем более, серьезный.

Поэтому смотреть в исходники DevExpress даже нет необходимости.

← →
Дмитрий Мыльников (2005-03-07 01:34) [5]

Если вы написали подобный код, и не сохранили тарый вызов, который там может уже быть, то вы сами себе "злобный баклан" :).

Жаль, что прямо сейчас под рукой нет исходников DevExpress, а то я бы с ходу дал пару цитат оттуда, поскольку как раз пару дней назад разбирался с тем, как у них реализованы некоторые механизмы.

Кстати, а какой "более правильный способ" для перехвата событий? Я что-то от вас его не услышал. Глядишь и мы тоже немного приобщимся к сообществу профессиональных разработчиков компонентов.

← →
Юрий Зотов © (2005-03-07 01:53) [6]

> Дмитрий Мыльников (07.03.05 01:34) [5]

1. Когда Вы в следующий раз будете назначать любой обработчик любого события любого компонента (в том числе, через Object Inspector), не забудьте сохранить "старый вызов, который там может уже быть".
2. Жду цитат из Dx.
3. Более правильный способ определяется задачей. Например, хук.
4. Этот вопрос уже давно обсуждается в "компонентах". Повторяться здесь не считаю нужным.
5. Смею надеяться, что к сообществу профессиональных разработчиков компонентов я уже давно приобщился. Во всяком случае, не я один так считаю.

← →
jack128 © (2005-03-07 02:21) [7]

вопрос (06.03.05 14:54)
а тебе одной ветки уже мало показалось? http://delphimaster.net/view/5-1109775581/

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

← →
Германн © (2005-03-07 02:56) [8]

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 03:14) [9]

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

← →
Германн © (2005-03-07 03:50) [10]

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

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

← →
GuAV © (2005-03-07 14:38) [11]

ИМХО не только для "батонокидателей со стажем". C ним удобнее назначить несколько обрбаботчиков, например на OnIddle или OnMessage.

← →
Набережных С. © (2005-03-07 15:41) [12]

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

← →
Erik1 © (2005-03-07 16:56) [13]

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

← →
jack128 © (2005-03-07 17:31) [14]

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

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

← →
Набережных С. © (2005-03-07 18:06) [15]

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

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

← →
jack128 © (2005-03-07 19:27) [16]

Набережных С. © (07.03.05 18:06) [15]
о чем тут спорить?
спорить то не о чем.

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

← →
Набережных С. © (2005-03-07 19:43) [17]

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

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

← →
Набережных С. © (2005-03-07 19:56) [18]

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

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

Или

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эээ... сначала не читал, но с описанным сталкивался, создавал класс (не компонент, я их не перевариваю почемуто) со стеком обработчиков... при присваивании все это дело сохранялось и возникала цепочка вызовов...
Единственный момент, это создавалось для конкретной задачи и конкретного класса. Точнее динамической объектной иерархии... Именно для этого очередь обработчиков и создавалась...

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

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

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

распознание выполнения события формы Найти похожие ветки