Господа, снова к вам.
Осваиваю, наконец, работу с классами и работу с несколькими экз форм.
При клике на Кн. Открыть форму открываю ее экземпляр.


В Form_Open открываемой формы открываю класс для работы такой формы

вот тут у меня возникла идея, чтобы в поднятый из экземпляра формы класс передавать "родительские формы", как бы цепочку до самого начала. Решил сделать на коллекции. т.е. будет последовательное добавление экз форм в коллекцию в цепочке. после изменения в каком то экземпляре - вниз по цепочке обновить зависимые данные
Создал начальную коллекцию и при старте "основной" формы саму себя добавляю в коллекцию
и передаю "начальный набор форм(ы)" коллекцией в класс открытого экземпляра:
MyProject.MyClsProject.PreviosForms = myCol

В классе есть своя private коллекция.



Передается коллекция "родительских форм" нормально. После отработки PreviosForms в коллекции класса 2 формы. Основная и сама она(для возможной передаче следующей форме)
одна беда. После возврата кода в начальную форму - в:
MyProject.visible = True
В основной форме в НАЧАЛЬНОЙ КОЛЛЕКЦИИ myCol -УЖЕ ДВЕ 2 ФОРМЫ, как и в коллекции класса.

Собственно. Что я делаю не так? Почему в Первую(начальную) коллекцию попадает/присваивается набор из класса, в который передавалась эта коллекция?

Брал инф. старое обсуждение и здесь
И параллельно обращаюсь еще к nord-woolf, Программист-Любитель, Вакшуль Сергей и др. участникам) с вопросом.
А как вы обновляете формы по цепочке после изменений в экземпляре.

Predeclared,

Спасибо за пример.
Не знал, что обращение к свойству класса, поднимает его экзмпляр
Set AltService = AlterationService.Instance

В вашем примере еще пока не разобрался до конца. Для меня новый принцип работы...
Вижу, что идет обновление всех ЭКЗЕМПЛЯРОВ одной формы.
Я же хотел настроить работу так, когда из форма1 открывается экз. формы2, потом из экз. формы2 открывается экз. формы3.
Получается цепочка:
Форма1 - экз Формы2 - экз Формы3
И вот при изменении в экз Формы3 - автоматом обновить измененные данные в экз Формы2 и Форма1.
По факту думал обозвать зависимые поля в экз Формы2 и Форма1 одинаково.
И потом (в случае с коллекцией) сделать циклом по коллекции в классе:
m_colPreviosForm(i).НазваниеПоля.Requery

Или я в принципе что то не так в уме складываю и ваш принцип укладывается в мою схему?

Тоже понял. Не помню только как точно называется))) дескриптор, что ли, окна..
Но тут же поднятый экземпляр сможет обратиться только к "пред окну", а "пред пред окно"?
или ловить событие по принципу Predeclared в этом "пред окне" и передавать дальше?.

Ведь цепочка может состоять и из 5 последовательно открытых инстансов разных форм.
Это я для понимания цепочку из 3 описал...


PredeclaredЯ выше словами описал как делать цепочки.
Да, поэкспериментировал, открывать из инстанса другую форму(экз). Нормально обновляются.

1. Кстати, я про это и думал, когда коллекцию придумывал... А так, цепочку прогнал сверху вниз. Нету экземпляра, ошибку обработал и дальше пошел и так до конца цепочки.
2. Не совсем понял. При пробе на вашей базе - обновляются все инстансы, не зависимо в каком экземпляре изменения сделал.
3. Тоже не понял. Посмотрите ваш вариант с моей пробой... Вроде все обновляет.
Другое дело, что источник один.... Кликните по Кнопке6 в открытой форме

Predeclared,

А, я по ходу начал понимать.
Получается, что при 100500 поднятых инстансах они все обновляются.
Пойду разбирать ваш принцип обновления. Пока понимаю больше интуитивно, чем знаниями.
Я так понимаю, если остальные молчат, то этот пример или самый распространённый или самый адекватный....

Predeclared,

В этом я с вами полностью согласен.
Простое описание:
Есть список проектов. Из нее вызываю др форму для редактирования какого то проекта.
В форме редактора проекта увидел, что фио менеджера написано с ошибкой. Вызываю форму редактирования менеджера и редактирую.
Так вот.
После закрытия формы редактирования менеджера должны обновиться данные менеджера в форме проекта и основной форме, где все проекты видны

Predeclared,

Сейчас это простенькая базка, на пяток форм. Просто на ней решил обкатывать работу классами, именно объектами, и сюда же работа с несколькими экземплярами объектов...

А вообще это наработка опыта для многопользовательских баз. С вариантом работы с sql серверами.
Скажем база, дающая больше свободы пользователю

Вакшуль Сергей,

Спасибо за ответ.
После вчерашнего общения более менее понимаю, что вы описали.

Есть над чем подумать...

А вот не подумайте, что уперся, но хочу вернуть внимание первому посту.
Почему при передаче классу коллекции


и отработке кода


в коллекции myCol, появляется вторая форма (экз формы из класса)

Использую ByVal. По моему он не возвращает результат в вызывающую функцию....

Как так то? Чего я не знаю?

убили...
PredeclaredПередавая ByVal ссылку на объектную переменную, создается копия переменной,
которая один фиг указывает на тот же адрес памяти, что и сама ссылка.
Таким образом, полученный процедурой ByVal аргумент ссылается на тот же самый объект.
и это был контрольный в голову
Король В.И. VB 6.0, VBA 6.0Что означает передача по ссылке или по значению, для аргументов тех типов, которые по своей природе являются ссылочными, например для объектных переменных?
.. : если объектная переменная передаётся по значению, то она не может быть изменена, т.е., даже если в теле процедуры присвоить ей ссылку на другой объект, по возвращении из процедуры, исходная переменная будет связана со старым объектом, на который она ссылалась до вызова.
Соответственно, при передаче по ссылке, можно связать эту переменную с новым объектом и по возвращении из процедуры, переменная будет ссылаться уже на новый объект.
При этом, надо отметить, что изменение свойств объекта, вне зависимости от того, как был он передан, происходит одинаково, в том смысле, что все модификации свойств объекта, сделанные в теле процедуры, фиксируются в исх.объекте.

По факту получается, что передавая коллекцию(как объект) в др функцию и присваивая ее другой(новой) коллекции мы получаем одну коллекцию, просто по схеме: коллекция - СсылкаНаНее1 - СсылкаНаНее2.

Пока у меня было время сегодня, игрался с коллекцией, что бы хоть за что то зацепиться, что бы объясняло такое поведение..
Пробовал ее и уничтожать перед манипуляцией с новой коллекций. И добавлять форму уже на совсем другом этапе работы с формой (что по моему разумению должно было разорвать связь обеих коллекций)....
Ничего не помогало...

А вообще чего хотел изначально.
Представляем себе некую форму2, которую открыли из другой формы1.
Так вот я хотел, что бы в форме2 сохранялась ссылка на форму1(из которой была открыта). Чтобы в последствии обновить форму1(поле в форме1) при изменении данных в форме2.
А т.к. цепочка открытия форм одна из другой может быть длинной, то решил хранить ссылки на формы в коллекции.
А первая коллекция - это что то типа приведения к одному формату перед передачей.
Просто так форму не передашь(в смысле тогда не будет единообразия механизма для всех форм). А передавая коллекцию я думал настроить универсальный механизм для передачи/приема набора с любым количеством форм в цепочке открытия форм.

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

Спасибо всем за участие.
Если вдруг кто то захочет что то добавить, буду благодарен.
А я пока буду думать какой способ выбрать для обновления.
Тотально тоже не хочется, в случае тяжелых форм это никому не понравится...

PredeclaredФорма2 (точнее говоря, сервисный класс, обслуживающий форму2), должна сгенерировать событие "Я_Имею_Таки_Что_Вам_Сказать".
Форма1 (точнее говоря, сервисный класс, обслуживающий форму1) имеет уши ссылку с подпиской на события на
Форму2 (точнее говоря, на сервисный класс, обслуживающий форму2), где в процедурах обработки этих событий
может реализовывать необходимый экшн.

Тоже да, благодаря вашему первому примеру научился подписываться на события из вне.

Но тут попадаем в ситуацию вероятного разрыва цепочки.
При попытке сделать "свободный функционал" модальность как то "не приветствуется.
Потому и думал, скидывать в следующий инстанс именно весь набор цепочки.
Т.е. у 2й формы их было бы 1шт в коллекции. У 10й - 9шт.
Тогда как раз и обходится вероятность разрыва цепочки закрытием "средней" формы.
Я, кстати, уже подумал грешным делом. А не сохранять ли в массив(и его передавать) дискрипторы, стрингом, открытых форм. Или будет та же песня, что и с коллекцией....
Тогда в AllForms их можно будет найти

Посмотрел ваш примерExAlt2
Единственное, про что не смог найти информации:


Me.ItemID - понимаю, что это обращение к самой себе. Но сейчас нигде не нашел информации по ItemID...гугл как то знает только Item))))

Упс.
PredeclaredВы же пытаетесь организовать обратное, таким образом, чтобы "дети" управляли "родителями".
А вот это ..., поворот на 180 градусов...
Спасибо за терпение.
Попробую сначала на бумаге это обрисовать....

А можно еще вопрос, пока в голове сомнения.
Я работаю с экземплярами форм так.

1. Поднимаю инстанс формы
2. В форме поднимаю класс для ее работы
3. В классе запихиваю форму во внешнюю Паблик коллекцию открытых форм(чтобы жила). Можно было и при поднятии инстанса это делать, но особой разницы не вижу. Просто все стараюсь запихнуть в класс, что бы меньше копипасте заниматься.
- Работаю с формой
- При закрытии формы
4. Удаляю форму из Паблик коллекции
5. Убиваю класс формы(из самого же этого класса)
6. На Class_Terminate класса убиваю ссылку на форму

Если не затруднит, подтвердить или опровергнуть адекватность по крайней мере действий при закрытии.
Никак не могу избавиться чувства какого то излишества.
А проверить правильности как то не очень получается.
Писал, писал....удалил...какая то каша в мыслях

Predeclared,


PredeclaredНо Вас же не очень огорчает, то, что в других цепочках не будет происходить обновление.
Пока еще не привык думать в нескольких плоскостях.
PredeclaredИз своего опыта работы могу сказать, что цепочки фактически никогда не рвутся,
если только специально не задаться целью это сделать. Они обычно короткие, два-три звена.
В какой то степени это объясняет ваш первый пример. Идет тотальное обновление.
И посидев, подумав...думаю вы правы. Среднестатистический оператор не будет открывать много разветвленных цепочек, так как будет понимать, что сам запутается...
Кстати, всплывает в памяти принцип работы виндовского проводника.
Открываем "Мой компьютер", и дальше идет последовательное открытие следующего диалога в старом окне. С указанием всей цепочки в строке адреса.
Не есть ли это некий "идеальный" вариант последовательного открытия следующей формы с скрытием предыдущей. Ну и в открытой форме что то типа адресной строки - та самая цепочка последовательности попадания в эту форму.
А в левой части - Тривьюшка со всей схемой открытых инстансов и цепочек...
Да... фантазия...
Но это уже какой то менеджер цепочек получается...
PredeclaredЭто имя контрола (и поля источника данных) формы frmAny.
Тупанул вчера уже к ночи
PredeclaredВроде как последовательность правильная, но, мне не нравится история с внешней коллекцией.
Вот пока не обратили внимания на это, даже не дернулось нигде внутри...
Я же "для первого опыта" для каждой формы сделал свою коллекцию. Думал, когда все уляжется в голове, переделаю на что то взрослое.
А тут и вправду, зачем отдельная коллекция на формы, если ее можно в классе хранить.
А ведь ссылка на класс хранится в форме.
Ссылка на форму хранится в этом же классе.
По моему это и есть тот самый Мюнхаузен.
Не. Все равно нужно же как то обращаться к конкретным формам из вне. А найти их можно только или в коллекции или по вашему принципу - в сервисном классе.
Мне пока легче так. Иначе запутаюсь. Потом уже в процессе эволюции...

А никто не делал такой "менеджер цепочек" именно в этом понимании. Не для конфигурирования, как у ПЛ (если ошибся, прошу прощения), а именно для удобства работы с программой?
Слева - все ветвления и цепочки из них, справа - окна цепочек с последними диалогами в них с возможностью переходов по цепочке в обе стороны с возможностью открыть (делать видимым) "средние звенья".
Как в семерке проводник по аналогии.

PredeclaredНет такой нужды.
Абсолютно.
Сначала призадумался, потом понял.
Вы же работаете по принципу: родительская форма слушает дочку
это все объясняет..
Даже, наверное, при работе без классов это тоже помогало бы.
Не нужно проверять открыта ли форма, перед обращением к ее контролам/свойствам.

теперь мой пробный код вероятно % на 30 уменьшу.

Predeclared , еще раз спасибо за терпение)) и участие.
ByVal, тут Бенедикт "более лучше" проходится по вопросу:
Пойду еще мал шаблоны себе поломаю....