К списку форумов К списку вопросов
[Delphi]TActionList и свой компонент
Hook
05.07.2004 - 10:40
Пишу свой компонент, связанный с TActionList. Возник такой вопрос - как одследить в своем компоненте изменения в TActionList? По таймеру опрашивать как-то ломает ;) Event OnUpdate тоже не совсем то, так как связанных компонентов может быть много, а событие это одно.
Буду рад любым соображениям.
Тупой ламер
1 - 05.07.2004 - 11:03
у любого TControl есть процедура ActionChange, есть функция GetActionLinkClass...
как правило - их хватает
или нужно что-то ооочень необычное? :-)
Hook
2 - 05.07.2004 - 11:06
Спасибо, щас покопаю в эту сторону...
Hook
3 - 05.07.2004 - 11:10
Нет, тут не совсем то... мне нужно одследить изменение всего TActionList(т.е любого из его свойств или Action-ов) а не какого-то Action-а отдельно.
x77
4 - 07.07.2004 - 00:28
для сравнения, посмотри, как работает виртуальный метод TCustomActionList.Change. событие OnChange также присутствует, кто мешает просто вешаться на него?
Hook
5 - 07.07.2004 - 11:22
Посмотрел, как это может тут пригодиться - не понял ;)
x77
6 - 07.07.2004 - 11:49
такого рода вещи делаются по аналогии DataLink'ов в наследниках TDataSet. а в Change, если мне память не изменяет, реализован сходный механизм, только работающий для TAction, а не для связанных с ними компонентов.
.
я, честно говоря, не совсем впиливаю, почему речь идёт об ActionList, а не об Action непосредственно. компонент-то связан с чем? неужто с самим списком? будем считать, что да, типа, есть некий тулбар, ему указывается список экшенов, а он выстраивает по нему кнопки. причём тулбаров может быть много. и при добавлении/удалении/изменении экшена требуется обновить все, связанные с ним тулбары. сорри, за полёт фантазии, но ты делаешь акцент именно на ActionList, а я как-то не могу сходу представить, нахрена он нужен нескольким компонентам. итак.
.
смысл в том, чтобы унаследоваться от TCustomActionList, добавить в него некий ComponentLink, в котором будут храниться связки TActionList<==>TComponent(s). при присваивании своему компоненту ActionList'а, ты передаёшь ему Self, который засовывается в ComponentLink. у твоего компонента должно быть какое-то свойство типа ActionChange: TNotifyEvent. при занесении в линки нового Self'а, ты вешаешь ему на этот евент свою процедуру для обновления компонента. теперь переопределяешь TCustomActionList.Change, в котором при каждом изменении для всех связанных компонентов будет вызываться ActionChange, обновляющий компонент.
.
думаю, идея понятна. если же речь идёт об Action's, то там имеет смысл посмотреть предков самой TAction, т.к. они и так автоматом обновляют все связанные с собой компоненты при измении себя, любимых.
Hook
7 - 07.07.2004 - 13:13
>>будем считать, что да, типа, есть некий тулбар
Грубо говоря можно сказать и так.
>>смысл в том, чтобы унаследоваться от TCustomActionList... и далее
Об этом я уже думал, наверное это действительно единственный выход :(
Хотя как варипнт - действительно в своем компоненте дублировать список акшинов с последующим отслеживанием их изменений. Но - удаление и добавление экшенов таким способом одследить не получиться.
x77
8 - 07.07.2004 - 13:38
исходя из того, что багланд в таких ситуациях всегда вводит доп. линковочный класс, можно полагать, что это действительно единственный метод. единственное, что ещё могу предложить, это повесить обработчик на TActionList.OnChange, в котором ты будешь просто тупо находить все свои компоненты (по хитрому имени, по Tag'у, как угодно) и вызывать их методы обновления. единственное достоинство подобного варварства - простота реализации. которая иногда не на последнем месте ;)
Hook
9 - 07.07.2004 - 14:17
А что, замечательная идея!! :)
x77
10 - 07.07.2004 - 14:22
этим ты заставляешь любого прога дописывать свой код, если он использует твои компоненты. а это не есть хорошо. если же прога пишется для себя - то какие проблемы :)
Hook
11 - 07.07.2004 - 14:34
Пока компонент для себя, но скоро выложу во всеобщее пользование - вдруг кому пригодиться.. наверное придеться переделовать саму идеологию работы, так как тащить к компоненту еще и объект связи - слишком.
x77
12 - 07.07.2004 - 14:53
думаю, что тащить изменённый ActionList придётся в любом случае, потому что я не представляю, как независимо от него организовать обновление...
.
кстати, такая мысль: почему бы в новом ActionList просто не слать WM_MESSAGE какой-нить? броадкастом? который будет благополучно отлавливаться компонентами, так, по идее, проще, хотя будет медленнее при высоком загрузе. а отловить мессагу в компоненте, сидя в той же нити, не проблема. тогда объектов связи не предвидится, но может тормозить.

К списку вопросов на форуме Программирование

>>