![]() |
![]() |
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 какой-нить? броадкастом? который будет благополучно отлавливаться компонентами, так, по идее, проще, хотя будет медленнее при высоком загрузе. а отловить мессагу в компоненте, сидя в той же нити, не проблема. тогда объектов связи не предвидится, но может тормозить. |