Dima T КонецЦикламодальная форма mainform
вот я и спаршиваю как в таком случае лучше организовать выход?
Для тех кто в танке. Одно из двух:
1. Убрать READ EVENTS
2. Сделать форму немодальной

Для тех, кто не в танке:
Не убирая Read Events и оставив форму модальной.
Задача:
1) существует ДЕРЕВО форм: родительская и ей порожденные (и ими порожденные). При этом, расчитываем на то, что какие-то порожденные формы могут просто минимизироваться, не закрываясь (или просто быть в фоне).
2) необходимо организовать:
а) корректное закрытие форм таким образом, чтобы при закрытии формы, кроме нее закрывались и все, ей порожденные
б) корректное общение между формами без Public и прочих рекомендованных маразмов - неудобно
в) невоможность запуска 2-го экземпляра одной и той же формы - свернув формочку, пользователь, обычно забывает про это и лезет запускать ее повторно.

Решение - коротко.
Делаем класс на основе формы. Добавляем ему 2 проперти: pParent (.null.) и pChildFrm[1] (.f.)
Вызов этого удовольствия делаем, передавая ему параметры массивом, первым элементом которого является this формы-родителя.
При инициализации (Init) класса:
а) сохраняем this родителя в pParent
б) проверяем весь массив pChildFrm родителя (а доступ у нас спокойный - pParent (this родителя))
на наличие Caption порождаемой формы. Если есть, активизируем
this.pchildfrm .WindowState= 0
this.pchildfrm.show
и возвращаем .f. в Init-е), если нет - расширяем pChildFrm родителя и вносим туда this порождаемой формы
Кстати, получили нормальный обмен данными между формами:
Порождаемая - родителю: this.pParent. ...=что угодно
родитель - порождаемой: this.pChilFrm[?]. ...=что угодно
Ликвидация методом Release
а) выставить в .null. себя в pChildFrm родителя и поджать этот pChildFrm
б) послать release всем своим pChildFrm:
For i=1 To Alen(this.pchildfrm)
this.pchildfrm[1].release
EndFor
Обратите внимание на это: this.pchildfrm[1].release
Дело в том, что порожденные формы на Release делают то же самое. Т.е., после release 1-й порожденной формы она, в том числе, высталяет себя в .null. и поджимает pchildfrm. Таким образом, после каждого вызова this.pchildfrm[1].release, pchildfrm сокращается и на место 1-й становится следующая.
Запуск главной формы стандартный:
DO form form1 Name Form1
Read Events
Закрытие ее тоже простое. Оно у меня на кнопке (и в меню)
This.parent.Visible= .F.
......
Clear Events
This.Parent.Release

Проблем аж никаких. Все формы - на основе вышеописанного класса, все - модальные.

2 MiklS
1. Основные+вспомогательные (калькулятор, календарь, прочая дребедень...) - уже сколько?
2. Учитывая, что гридом я последний раз пользовался еще в 2.0 (там правда его, как такового, не было - организовывался на browse), что работаю я на SQL-сервера, как минимум, добавляется еще одна форма - изменения данных.
3. А чего я должен пользователя ограничивать? Он хочет одновременно иметь 10 окон - флаг ему в руки. Кстати, при специфике работы моих кадров, иметь одновременно 4..6 основных окошек - очень удобно... Мое дело - сделать так, чтобы это все правильно работало при пользователе-идиоте. Так, чтобы все вовремя обновлялось, чтобы при попытке открытия уже открытой формочки, она вела себя правильно, чтобы все дочерние формочки закрывались при закрытии родительской.
Пока не жалуются - уже 5 лет классу пошло. Особой беготни тоже не видать. А класс этот я уже практически всюду сую, даже если 2-3 открытые формочки - все равно удобно.
Но это вопросы такие... Пользователю должно быть удобно - вот наш с Вами принцип. Можно мило поболтать о взаимодействии форм, о корректном закрытии - о внутренней нашей с Вами кухне. А пользователю это до... Если Вы считаете, что существует жесткая, везде одинаковая связь между кол-вом окошек и удобством пользователя, я с Вами не соглашусь. Предпочитаю Oper-у Internet Explorer-у.
С уважением, всегда рад...

2 MiklS
Сорри, не заметил сразу...
MiklS Если например пользователь открыл форму заполнения таблицы наименований товара, то он не должен иметь возможность сделать ещё что то, пока он её не закроет
??? Одно заполнение формы - один товар из одной партии - я правильно Вас понял? И почему он не должен иметь возможности, не закрывая эту формочку, работать с этим товаром, после того, как уже занес его? ИМХО, один из самых безопасных вариантов. ИМХО, что-то у Вас не так, если в этих условиях можно что-то наворочать... (Варианты: прямое редактирование рабочих таблиц - прямо из формы, без кнопочки "ОК"("ЗАНЕСТИ", или как там?); вешать рабочие таблицы непосредственно на комбобоксы; играться с private data sessions, некорректные обновления данных и пр. - много вариантов есть...) По крайней мере, у меня, примерно в аналогичной ситуации (занесение нового прибора учета) - все тип-топ, можно сразу с ним работать, не закрывая эту формочку - висит она себе автономно , и все...

Да, согласен с Вами, сколько лет прошло, а все равно на 800х600 все пишешь... У меня дисплей домашний wide 1680х1050, видели бы Вы эту 800х600 на нем - кур я м на смех...
Что же касается окошек - нерабочие можно закрывать, а можно и сворачивать. Или вообще бросать...
Подвесить одновременно несколько окошек - очень удобно - тот же справочник, к примеру. Нет у тебя прибора - не закрываешь свое основное окно, а поднимаешь справочник, добавляешь - и работаешь дальше себе. Попробуйте сами. Я сам очень долго писал по этому принципу - минимум открытых окон, не закроешь предыдущее - не попадешь дальше, а попробовал другой - кое-где очень удобно. (ИМХО).