of63
Действительно, при o.Release уничтожает и элемент в коллекции. Оказывается, написано в хелпе про Release-метод. Перевод путаный, если не знать о чем речь, то непонятно что сначала удалять: то ли ссылку в коллекции, то ли сам обьект. Поскольку не использовал коллекции, то и не нарывался... Бум знать.
В хелпе:

Часть текста скрыта

Закрыть

Все верно.
В хелпе речь идет о "коллекции форм объекта _SCREEN", т.е. о коллекции _SCREEN.FORMS и об удалении форм из этой коллекции, которая специфична тем, что не имеет обычных для коллекций методов ADD() и REMOVE().

Аспид
Но по факту, для 1:много действительно многовато переделок. Достаточно фундаментальных.
Надо править слишком глубоко, а это всегда чревато. )))
1:1 решил. Получилось складненько и внятно.

Про то и речь

Igor Korolyov

Аспид
Но по факту, для 1:много действительно многовато переделок. Достаточно фундаментальных.
Надо править слишком глубоко, а это всегда чревато. )))
1:1 решил. Получилось складненько и внятно.

Про то и речь

И что было ясно с самого начала.
Непонятно, зачем нужно было городить эту "этажерку", если можно использовать класс Collection и цикл FOR EACH ...ENDFOR.

Ниче так и не ясно, и желаемого видеоэффекта (цепочки-задачи, где фокус) так и не понял. Эти циклы (1:много ?) почему оказались проблемные - не ясно. Пока реальный проект в руки не возьмешь, то все кажется банальным. А ведь каждый проект несчастен по своему )

of63
Ниче так и не ясно, и желаемого видеоэффекта (цепочки-задачи, где фокус) так и не понял. Эти циклы (1:много ?) почему оказались проблемные - не ясно. Пока реальный проект в руки не возьмешь, то все кажется банальным. А ведь каждый проект несчастен по своему )

А зачем нужно создавать такие "цепочки", это занятие для новичков.
Сделать видимыми формы можно в цикле. Их можно выложить "каскадом" или "черепицей".
Нужные формы можно пометить в свойствах формы. В качестве метки я предложил Аспиду формы раскрашивать (уж больно он любит раскраски, словно ребенок).
Определенную последовательность имен форм через разделители можно сохранять тоже в свойствах.
Также для этой цели можно использовать меню "Окна", ini-файлы и др.
Что касается проектов, то в данном случае сохранение открытых форм как объектов в Collection или в массиве это типовая задача для любого проекта.

Igor Korolyov
Про то и речь

Не Игорь, если решать не абстрактно (для все, и навсегда), а конкретно.
То не особо и сильно гиморно.
Просто, видимо, юзеры не пользуются почти возможностью вызова множества форм. (потому что, там изначальный косяк с псевдо- модальностью)
А потому и нет нужды решать задачу. Потому отложил)
Был бы год 2000й, решил бы ради интереса, на будущее)

Аспид
Проблема, когда из основной задачи, запускается несколько форм.
Тогда в fedit видимо нужна коллекция...
Пока на этом остановился, дальше и не пойму что с ней делать)

Решений несколько:

1. Если Дочерняя форма может существовать без родительской (каждая форма имеет свою сессию данных, например: форма списка документов - форма редактирования документа), в этом случае: в дочернюю форму передаю PK-документа, hnd окна родительской формы, таким образом отвязываюсь от "висящих" ссылок, профит:
-) можно "убить" родителя без закрытия дочерней формы.
-) можно из одной родительской вызвать неограниченное кол-во дочерних (например форм редактирования), более того для одного документа можно иметь несколько форм редактирования.

hnd окна родительской формы нужен для того, что бы найти родителя, например для того, что бы обновить данные в родительской форме после редактирования.

2. Если Дочерняя форма не может существовать без родительской (контекст/сессия данных должна быть общая), то через свойство (не коллекция) вяжу по CreateObject('ChildForm').

У самой ChildForm так же могут быть вызовы 2-х типов.

Пашь, у нас разный подход.
Мне хотелось абстрактное решение, которое бы годилось для всех и всегда.
Уже писал, конкретную ситуацию, всегда не сложно разрулить.

Поэтому однозначно, любая форма - независима. (на самом деле это не форма, а некая связка объектов, у нас термин - домен)
И всегда, в своей сессии. ВРУ. Есть формы редактирования, именно формы, которые в той же сессии, и даже принадлежат этой же связке, домену.
Вызов другого объекта, достаточно сложен. Интерфейс такой LPARAMETERS tContext, toCtrl,tTip
Где toCtrl - ссылка на вызвавший домен.

PaulWist
-) можно "убить" родителя без закрытия дочерней формы.

Я такого не могу, для меня это вредно.

PaulWist
-) можно из одной родительской вызвать неограниченное кол-во дочерних (например форм редактирования), более того для одного документа можно иметь несколько форм редактирования.

Это как раз и было основным предметом обсуждения.)))
Это специфичные формы, у которых есть свой, дополнительный тулбар.

А о чем это мы?)))

Аспид

PaulWist
-) можно из одной родительской вызвать неограниченное кол-во дочерних (например форм редактирования), более того для одного документа можно иметь несколько форм редактирования.

Это как раз и было основным предметом обсуждения.)))
Это специфичные формы, у которых есть свой, дополнительный тулбар.

А-а-а, если разговор про нескольких однотипных форм управляемых одним и тем же тулбаром (именно тулбар как глобальный обьект, типа "Создать запись/документ/справочник", "Редактировать запись/документ/справочник"), то у меня сделано так (могу в деталях забыть):

-) При Activate формы, она запоминает состояние тулбара и выставляет Enabled/Disabled/Visible кнопкам/объектам "общего" тулбара для себя.

-) При LostFocus, Resize форма запоминает состояние тулбара, что бы при Activate "выставить" тулбар в то состояние когда форма была активной.

-) В QueryUnload форма восстанавливает состояние тулбара до своего Activate, это нужно если в главном окне не осталось активных окон данного класса.

Не Пашь. Проблема описана в 3 сообщении.
Есть несколько приложений, они сведены в одно... и т.д.
Все написал раньше. Всю задачу.
Восстановление, имеется ввиду визуальное

Не понимаю зачем чего-то в этом случае "запоминать" и тем более "восстанавливать". Если не осталось активных окон, то тулбар либо убирается, либо полностью блокируется. Иначе что делать от кнопки будут? Куда "добавлять", что "удалять" А так - да, по Activate тулбар привязывается к активной форме и адаптируется к её состоянию (какие кнопки доступны, какие нет). По Deactivate отвязывается и, соответственно, всё блокируется.

Igor Korolyov
Не понимаю зачем чего-то в этом случае "запоминать" и тем более "восстанавливать".

В 4м сообщении, в этой теме описал причину вопроса. Просто в мозгах неукладка была) Теперь все уложилось.

Тулбар тут вообще не причем.
Он есть на все приложение.
И есть объекты, которые отвечают за свою область. Они по определению синглтон. И вот они из общего тулбара вызываются.
Некоторые объекты, вызывают свой тулбар.
ЗЫ. Пардон. Невнимателен был) Ты Паше отвечал)





Исправлено 1 раз(а). Последнее : Аспид, 25.10.17 14:17

Igor Korolyov
Не понимаю зачем чего-то в этом случае "запоминать" и тем более "восстанавливать". Если не осталось активных окон, то тулбар либо убирается, либо полностью блокируется. Иначе что делать от кнопки будут? Куда "добавлять", что "удалять" .

Говорю же: "если правильно помню", оказалось не фига не помню (действительно предыдущее состояние форма не запоминает, тупо перерисовывает тулбар под себя, а в QueryUnloan дисейблит тулбар, а уж если есть активная форма она под себя перерисует)

QueryUnload? Так что все формы модальные что-ли Или это про код "последнего отвязывания" У меня активно задействованы Got/LostFocus для "подхвата" тулбара - при том не только формы, но и специальных контейнеров. Т.е. "контекстом" в котором тулбар хулиганит является не только форма, но и иногда её отдельная часть (те же мастер-дитэйл формы). Соответственно отслеживается активация/деактивация и этих контейнеров. Тулбар связан с формой/контейнером через класс-посредник (по сути именно посредник то и знает какой тулбар нужен, и как на его кнопки реагировать), соответственно поиск/создание тулбара в Init этого посредника, а "окончательное отвязывание" в Destroy. Собственно же привязка/отвязка (надо ж тулбару сообщить, методы какого объекта ему дёргать при нажатии кнопок, ну и какими "свойствами" определяется доступность этих кнопок) в своих методах activate/deactivate...
Правда ноги у системы растут со времён 7-го и даже частично 6-го фокса, потому многих полезных фишек сильно упрощающих жизнь там, увы, не сделано... Тех же BINDEVENTS сейчас напихал бы немеряно, а то приходится через SetAllX "рассылать спам" - т.е. уведомления об изменении состояний и т.п.

Igor Korolyov
QueryUnload? Так что все формы модальные что-ли Или это про код "последнего отвязывания" ...

Неа, формы "нормальные".

Угу, "захлопывание двери"

Igor Korolyov
Правда ноги у системы растут со времён 7-го и даже частично 6-го фокса ...

У моей "ноги" от 5-ки

7-ка, 6-ка, 5-ка - нашли чем хвастаться.
На 9-ку пора переходить.