Форум: "Основная";
Текущий архив: 2005.10.02;
Скачать: [xml.tar.bz2];
ВнизКак отловить запуск и завершение. Найти похожие ветки
← →
V-A-V (2005-09-07 10:35) [0]Народ подскажите как мне отловить запуск моего приложения, но только после того как все формы создались, и завершение работы приложения, но только когда еще формы не убиты.
← →
Digitman © (2005-09-07 10:44) [1]это зачем ?
и кто должен заниматься "ловлей" ? другое твое приложение или кто ?
← →
V-A-V (2005-09-07 10:49) [2]Задача стоит в том, чтобы при запуске приложение восстанавливало некие свои настрой, а перед завершением сохраняло их.
← →
Digitman © (2005-09-07 11:00) [3]а при чем здесь тогда "ловля" ?
и какие именно "настройки" требуется сохранять/восстанавливать ?
← →
V-A-V (2005-09-07 11:45) [4]Настройки различные. Допустим какие-то св-ва контролов...
← →
Silver... © (2005-09-07 12:04) [5]
OnCreate
OnShow
OnClose
OnDestroy
← →
Digitman © (2005-09-07 12:07) [6]это можно сделать, например, так:
1. в dpr
procedure MyExitProc;
begin
WriteSettings(..);
end;
begin
ExitProcessProc := @MyExitProc;
Application.Initialize;
...
Application.Run;
end;
2. в модуле главной формы
...
initialization
ReadSettings(..);
← →
V-A-V (2005-09-07 12:18) [7]Ладно опишу задачу конкретнее. Я написал свой компонент, который вешается на OnShow и OnDestroy формы и обходя все компоненты, отлавливает гриды и сохраняет(загружает) настройки гридов в файл.
Так вот хотелось-бы, чтобы не на каждую форму бросать этот компонент, а использовать один на все приложение, чтобы он при запуске (завершении) отлавливал все гриды и сохранял (восстанавливал) их настройки....
← →
Digitman © (2005-09-07 12:53) [8]
> Ладно опишу задачу конкретнее
ну спасибо за одолжение !)
> сохраняет(загружает) .. гридов в файл
сделай по-иному : в процедуре ReadSettings() считывай настройки из файла в память, а в WriteSettings() записывай настройки из памяти в файл
а в своем компоненте лови свои гриды и читай/записывай их настройки в той самой памяти, с которой работают упомянутые процедуры
← →
Silver... © (2005-09-07 13:08) [9]Когда-то я занималя этим вопросом. Так и не доработал как хотел (времени небыло), итог в каждой форме вызов нужной Proc :((.
Думал сделать иначе: Ловить Момент создания/удаления Формы Ток глобально (в одном месте)- тут ставить/запоминать настройки.
Вот тока загвоздка в :"Ловить Момент создания/удаления Формы глобально"
Я так понимаю вApplication
инкрементируется декрементируетсяFormCount
в этот момент но как ловить?
если кто знает напишите и мне: 2_s_i_l_v_e_r@mail.ru (без "_")
← →
Anatoly Podgoretsky © (2005-09-07 13:30) [10]Не надо глобально, надо в момент создания и уничтожения конкретной формы и только для этой формы.
← →
V-A-V (2005-09-07 13:41) [11]> Не надо глобально, надо в момент создания и уничтожения конкретной формы и только для этой формы.
а как узнать, что она только что создалась и как узнать, что она собралась убиваться и все это глобально?
← →
Digitman © (2005-09-07 14:46) [12]о нужном моменте в своей "жизни" форма должна известить сама.
сделай класс TMyForm (наследника TForm), перекрой там методы AfterConstruction и BeforeDestruction, в телах перекрытых тобой методов посылай окну Application.Handle предопределенное тобой сообщение с параметром-ссылкой на объект-форму, которая посылает сообщение
все формы приложения отныне наследуй от TMyForm.
в обработчике Application.OnMessage лови это сообщение и твори с формой, переданной параметром сообщения, все что твоей душе угодно
← →
Юрий Зотов © (2005-09-07 15:01) [13]> V-A-V (07.09.05 12:18) [7]
> Я написал свой компонент, который вешается на OnShow и
> OnDestroy формы и...
... и теперь пользователь этого компонента, не подозревая о таком коварстве, назначил свои обработчики OnShow и OnDestroy формы.
Что произойдет?
← →
V-A-V © (2005-09-07 15:43) [14]> ... и теперь пользователь этого компонента, не подозревая о таком коварстве, назначил свои обработчики OnShow и OnDestroy формы.
а произойдет то что пользователь напишет в этих обработчиках, если правильно "вешаться" на них, обрабатывать и возвращать назад.
← →
Anatoly Podgoretsky © (2005-09-07 15:49) [15]V-A-V © (07.09.05 15:43) [14]
Ну ну, ты видел реализацию свойства OnShow?
← →
V-A-V © (2005-09-07 15:55) [16]> Ну ну, ты видел реализацию свойства OnShow?
Да, конечно.
Сначала сохраняешь ссылку на него, затем отрабатываешь свое и восстанавливаешь чужое, при этом отрабатывая его.
И все это нужно только один раз.
← →
Digitman © (2005-09-07 16:02) [17]
> V-A-V © (07.09.05 15:55) [16]
ты вот, я смотрю, умный такой, а пользователь твоего компонента запросто может оказаться не таким умным - он попросту начхает на твои правила, возьмет да и установит в ран-тайм свой обработчик события и ничего "восстанавливать" даже и не почешется) .. и вся твоя "логика" при этом летит коту под хвост)
← →
Erik1 © (2005-09-07 16:27) [18]Да нехорошо на событиях висеть и как раз описаный подход с наследником спасает от этой проблемы. Даже компонент ненадо писать, хватит и обычного модуля.
← →
Silver... © (2005-09-07 18:44) [19]
> Digitman © (07.09.05 14:46) [12]
Помнится мне тоже такой совет давали когда боролся с этой проблемой. Но мне лично такой подход не понравился.
Да и повод был: Над проектом работал не только я некоторые модули делались людьми с которыми и поговорить/договориться небыло как. Как заставить их:
> все формы приложения отныне наследуй от TMyForm.
да и куча всего уже было сделано; заставить их переписывать
Хотелось Ловить сообщение или что нить иное о создании/убивание формы (не по таймеру проверять FormCount), тогда мудрить, договариваться и заставлять кого-нибудь отныне...
← →
Юрий Зотов © (2005-09-07 22:28) [20]> V-A-V © (07.09.05 15:43) [14]
> если правильно "вешаться" на них, обрабатывать и возвращать
> назад.
А вот этого-то как раз и не получится. Юзер назначает свои обработчики в run-time (притом вполне законно, ничего неправильного в этом нет, ничто не мешает и не запрещает ему так сделать) - и привет горячий. Приплыл Ваш компонент.
← →
Юрий Зотов © (2005-09-07 23:28) [21]> V-A-V
Если на форме лежит Ваш компонент и еще другие, то:
1. Как только форма при своем уничтожении начнет удалять первый же из этих компонентов, она оповестит об этом остальные компоненты - в том числе, и Ваш тоже. Значит, перекрыв в своем компоненте метод Notification, можно поймать начало разрушения формы.
2. Как только форма полностью загрузится из DFM, она начнет вызывать метод Loaded всех своих компонентов - в том числе, и Вашего тоже. Значит, перекрыв в своем компоненте метод Loaded, можно поймать окончание загрузки формы.
Но если Owner"ом Вашего компонента будет не форма, то ничего этого не произойдет. Поэтому все же лучше сделать не компонент, а форму. В ней надо перекрыть методы DoCreate и DoDestroy (или AfterConstruction и BeforeDestruction), а саму форму поместить в репозиторий и просто наследовать другие формы от нее. Вот это будет вполне надежное решение.
← →
V-A-V © (2005-09-08 07:46) [22]Спасибо всем за исчерпывающую информацию.
Убедили Вы меня, в написании наследника, но только я думаю надо писать не наследника формы, а в моем случае, наследника грида, это будет актуальнее.
← →
Digitman © (2005-09-08 08:24) [23]
> надо писать не наследника формы, а в моем случае, наследника
> грида
а завтра тебе захочется сохранять/восстанавливать настройки еще каких-нть компонентов кроме грида ...
что, опять будешь изобретать их наследников ?
← →
V-A-V © (2005-09-08 08:45) [24]>а завтра тебе захочется сохранять/восстанавливать настройки еще каких-нть компонентов кроме грида ...
что, опять будешь изобретать их наследников ?
Нет не захочется. Для этого есть неплохие сохранители из RxLib...
← →
Digitman © (2005-09-08 08:48) [25]
> V-A-V © (08.09.05 08:45) [24]
> Для этого есть неплохие сохранители из RxLib
да причем здесь "сохранители"-то ?!
речь-то идет о получении управления в моменты окончания создания формы и перед ее разрушением ..
Страницы: 1 вся ветка
Форум: "Основная";
Текущий архив: 2005.10.02;
Скачать: [xml.tar.bz2];
Память: 0.51 MB
Время: 0.004 c