Самым простым выходом будет добавить объектную переменную в основную форму и в собитии Load инициализировать ее, что-то вроде этого


где внедренный - подчиненная форма.
А дальше можешь ловить события подчиненной формы. Но, к сожалению, только стандартные события формы. Но можно, если подумать, и написать такое, что можно будет ловить ЛЮБЫЕ(зависит только от твоей фантазии) события. Например, событие нажатия кнопки в подчиненной форме. Если это тебе интересно я могу рассказать как это сделать.

to Hummer
А если подчиненная форма используется не только в одной форме а в 5.
И чего мне для в подчиненной SELECT CASE лепить для пяти случаев?
mahoune прав, нужно работать с событиями, а обрабатывать там где это действительно нужно.

to mahoune
Я же тебе написал как это сделать. Если что-то непонятно спроси, не стесняйся :)

to Hummer
> но мне такой подход облегчает жизнь - править код при необходимости нужно в одном месте, потому что когда есть 1600 форм очень затруднительно искать, где ещё она используется
Ага представил себе. Ты меняешь (добавляешь, удаляешь, переименовываешь и т.п) контролы которые у тебя завязаны в подчиненной. Чего ты будешь делать? Открывать подчиненную и опять искать в Case? А если у тебя поменялся алгоритм работы подчиненной формы и ты вспоминаешь какие же контролы на форме Parent, а если их много. Бррр. Все-таки лучше в подчиненной форме составить список форм в которых она используется.

to Hummer
>В Аксесе ХП подчинённая форма редактируется в том же окне, что и главная - ничего мне вспоминать не надо.

В том то и дело подчиненная форма одна, а родителей много. Поменял подчиненную форму и вперед искать всех родителей.

К тому же при твоем подходе страдает переносимость форм и кода, т.е у тебя формы слишком сильно завязаны с друг другом. Это не есть хорошо.
У себя же я могу написать определенный список событий которые генерит эта форма. И уже во всех главных формах работать с этой формой как с законченной компонентой (написал положил на сервер в SourceSafe). Вот тут то и есть выигрыш при написании программы несколькими людьми.

Ну вот, пришел Geo и все испортил :). С On Error Resume Next ты это неплохо придумал даже пока и возразить нечем, но mahoune просил чтобы было системно, а винды так не работают ;).

to Geo
Подожди! Поймаю я тебя еще на On Error :))

to Geo & all



При работе с объектом Err нужно быть крайне осторожным. В частности в приведенном примере необходимо добавить обработку событий в процедуру MyChildFormChanged(). Например On Error Goto 0.

to Hummer
Зачем???? Написал же - я изменяю Parent - и в ней же вижу подчинённую - там Case - по имени родителя (этого же) - правлю я его абсолютно так же, как правил бы и в родителе, а на все остальные родительские, где она используется мне пофиг - так как там ничего не поменялось:)

Как зачем case для семи форм, а если еще и нехилая логика то и растут вот потом процедуры на 20 листов. Чего же в этом хорошего. Хорошо если с этой подчиненной формой работаешь только ты, а если несколько человек, то тут всплывает вероятность ошибки. Поди потом разбери кто-чего нарисовал. При том же растет и размер формы. Зачем мне объект в оперативной памяти в котором я использую 1/7 часть кода?

Переносимость не страдает, уж поверьте, перенести могу одну главную и одну подчинённую и всё будет работать, так же как и в вашем случае

Ага удаляешь весь case и пишешь все по новой какая тут переносимость?

Ещё раз повторяю, весь код держится в подчинённой форме, потому что она грузится раньше

Какая, в данном случае, разница когда она грузиться? Мне непонятно.

А при подходе Geo - пишется и там и там - зачем так делать?[/src]
Затем, что мне, как программисту, гораздо проще работать с событийной моделью, а не валить все в одну кучу.