forum.clarionlife.net

Не знаю, поможет ли. В mdi окне отработка события openWindow происходит после того, как сделаны все запуски из фрейма. Без разницы, через run или even:accepted. Поскольку управление окнам строится на глобальных структурах (у меня во всяком случае), то это приводит к багу, напоминающему Ваш. У себя я получил корректный запуск нескольких mdi окон через пользовательское событие. То есть во фрейме на событии OpenWindow шлем post(5002). На этом событии по счетчику стартуем нужное mdi окно. В mdi окне на событии openWindow шлем во фрейм post(5002,,1). Во фрейме на событии 5002 увеличиваем счетчик и стартуем очередное mdi окно. То есть во фрейме можно организовать локальную очередь запускаемых автоматически при входе в программу тредов. А во все дочернии mdi окна шаблоном прописать отправку пользовательского события на фрейм, сигнализируя, что тред инициализировался. Как-то так, у меня работает...

То, что я написал в предыдущем посте, позволяет упорядочить запускаемые mdi окна в порядке их запуска. При обычных start второе запущенное окно может инициализироваться до первого и т.п. Причем раз на раз не приходится. Скорее всего, проблема в TabBar тоже с этим связана.

Нашел по ходу еще странный баг, который присутствует и в c6, и в c10. Есть глобальная нетредная строковая переменная. Если присвоить ей значение до open(window), то после открытия окна она может очищаться. Причем именно в режиме последовательного запуска нескольких mdi окон из фрейма при старте программы. При запуске одного из меню (как обычно) все нормально. Если перенести присвоение этой переменной после open(window), то все нормально.

В общем, после этих поправок все заработало, как надо. И в c6, и в c10...

Игорь, давай тестовый пример. Может оказаться дело в билде Клариона, в оси и т.д.

1. Сделал новое приложение для теста - всё работает штатно (проблемы нет).
2. Перенёс в него окна из рабочей программы - всё работает штатно (проблемы нет).
3. Сделал все настройки, Extensions как в рабочих программах - - всё работает штатно (проблемы нет).

Ничего не понимаю.

Остаётся только применить принцип "Бритвы Оккама" отсекая всё в рабочих приложениях.
Что бы найти причину - это займёт некоторое время ...

Я её поймал ! Если кому интересно, выполните:

1. Распаковать пример, загрузить в C10 (с конвертацией) и собрать.
(постарался сделать минимальный пример штатными средствами, что бы не замылить проблему)
2. Запустить пример, открыть меню и в нём открыть ещё пару окон.
3. Наблюдаем глюк описанный в первом сообщении этой темы.
4. Закрываем все MDI окна, заново открываем несколько MDI окон - всё как и должно быть.

Причина проблемы в ошибочно установленной опции:


Дело-то пахнет грубой ошибкой Runtime C10 ...

Да. Устойчиво. Насчёт ошибки вопрос ещё. Странный вызов source процедуры. Получается, она висит и мешает нормальным тредам?

Абсолютно нормальный вызов процедуры ... Для запуска безоконного потока не требуется AppFrame.
Этот поток не висит, он пустой и моментально завершается ....

Никто не запрещает, например, создавать безоконное приложение, которое будет запускать потоки с какой-то
обработкой, сама отслеживать их выполнение и т.д. Можно даже запустить такое приложение как службу Windows ...

А вот то, что запущенный совсем в другом окне поток нарушает работу еще не запущенного AppFrame - это проблема !

И что-то мне подсказывает, что это ключ к решению старой проблемы, о которой я говорил вот здесь:
https://forum.clarionlife.net/viewtopic ... 9&start=60

Ммм... Игорь, если Вы запускаете в отдельном потоке безоконную процедуру, то должны самостоятельно в ней инициализировать поток и завершить его при выходе. В языке есть специальные операторы для этого. Когда в потоке запускается оконная процедура, кларионовский рантайм все делает автоматически с открытием и закрытием окна. Я безоконные потоки сейчас не использую, но когда-то разбирался с этим вопросом. Остальное поищите в документации...

Не так написал, дело не в открытии/закрытии окна, а в наличии accept. Давно уже было, склероз... Посмотрите на SUSPEND и RESUME.

finsoftrz писал(а): 08 Декабрь 2017, 17:12Не так написал, дело не в открытии/закрытии окна, а в наличии accept.

К сожалению, нет ... Убрал из примера полностью notMDI окно (вместе с ACCEPT) - проблема осталась ...
Что касается "SUSPEND и RESUME" - это потрясающе интереснесная тема, но к сожалению совсем из другой сказки.
Или удивите меня ! Уберите пожалуйста проблему в моём примере с помощью SUSPEND и RESUME ...
(пример прилагаю)

Увы, я не использую abc. Они у меня даже не установлены...
Если в source процедуре просто воткнуть скобки из SUSPEND и RESUME, не помогает?

Или в source процедуре есть свой accept? Я помню, что если просто стартануть source процедуру в которой нет accept, в отдельном треде (типа start(myproc,25000)), а потом ее завершить без использования SUSPEND и RESUME, то некорректно получалось.

finsoftrz писал(а): 08 Декабрь 2017, 18:26Увы, я не использую abc. Они у меня даже не установлены...

Понял ! Это уже деловой разговор ... Давненько я не брал в руки шашек ...
Сделал пример на Legacy, там всего-то 3 пустых процедуры. Проблемы - те же (RTL ведь один и тот же).
Будет возможность - посмотрите пожалуйста. Буду благодарен за любой совет по существу вопроса.

К сожалению, этого тоже нет...

finsoftrz писал(а): 07 Декабрь 2017, 13:29На этом событии по счетчику стартуем нужное mdi окно. В mdi окне на событии openWindow шлем во фрейм post(5002,,1). Во фрейме на событии 5002 увеличиваем счетчик и стартуем очередное mdi окно.

Кстати, интересный приход ...

Ведь если можно предопределить порядок открытия нескольких MDI окон при открытии AppFrame,
то значит можно связать порядковый номер открытого MDI окна с номером его потока.
И мы точно знаем когда открыто последнее MDI окно ....
И как следствие - после завершения открытия всех MDI окон, можно сделать активным окно с нужным порядковым номером.

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