Многооконность, проблемы

[Jakob Brontfeyn]

Уважаемые коллеги специалисты, есть одна проблема.
Мои приложения состоят из нескольких VI, работающих как самостоятельные окна,
что позволяет разместить их на мониторе так, как удобно пользователю,
а подключив второй монитор еще удобнее наблюдать и управлять экспериментом.
Все перед глазами, перейти на перелистывание в одном окне, ну просто никак невозможно.
Все окна разрешается сворачивать, но не разрешается изменять
размеры и закрывать, остановка делается сначала только кнопкой "стоп", потом можно
закрыть уже остановленный VI, или если надо запустить снова, не останавливая основной процесс експеримента.
Смотрите демопример.
Все вроде бы хорошо, но если нажать левой клавишей мыши (и правой кстати тоже)на символ сворачивания окна
в правом верхнем углу не коротким нажатием как все "нормальные" люди а держать, не отпуская,
даже выдвинув уже мышь куда то в сторону, то работа этого и других VI полностью замирает,
и если кто то в задумчивости, или по злому умыслу так проделывает, это приводит к вышибанию
мощного сложного оборудования, управляемого моими лабвью-приложениями. Ватчдогтаймер через 10 секунд,
воспринимает это, как потерю связи с PC или его отказ.
Не говоря уже о том, что нарушается даталогинг, работа ПИД-регуляторов, ну и все остальное, пусть даже, если
замирание меньше 10 секунд и Ватчдогтаймер успевает сброситъся.
Не лучше обстоит дело и, если щелкнутъ правой клавишей мыши по симвоку в левом верхнем углу окна, или
по уже, выше описанному, символу сворачивания в правом вернем углу.
Выскочит менюшка, где сворачивание окна идет без проблем, но стоит щелкнуть по функции перемещения окна,
полная катастрофа засвечивается крестик из 4 стрелок и все глухо висит, пока не щелкнешь куда нибудь
левой клавишей мыши. Не надо давать ответ на первый традиционный русский вопрос:"Кто виноват?",
скорей всего, больше NI, чем Микрософт, потому что с окнами, например експлоера, такого не происходит.
Дайте ответ на второй вопрос :"Что делать?" Просьба не предлагать радикальной хирургии, типа перехода на Линукс,
автономные RИО и тому подобное.
Может можно задать установки окна VI без титульной надписи, тогда его невозможно
ни свернуть-развернуть ни двигать средствами винды,
а выделить где то в уголке квадратик, заходить туда мышкой
двигать и сворачивать-разворачивать средствами лабвью, если это возможно.

P.S. В Windows Task-Manager похожая фигня

[Artem.spb]

win7 pro + LV12, описанные действия не приводят к катастрофе.
на лицевой панели перестаёт мигать лампочка, все остальные индикаторы продолжают работать, не говоря уже о диаграмме, т.е на мой взгляд в данной конфигурации прога не подвисает, но без железа естественно ничего не гарантирую.

далее, не понятно, что значит

остановка делается сначала только кнопкой "стоп", потом можно закрыть уже остановленный VI, или если надо запустить снова, не останавливая основной процесс експеримента. Смотрите демопример.

если комплекс продолжает работать, то зачем стопить один из его компонентов?
собственно в одним из подобным многооконных комплексов все окна у меня работали постоянно, но их можно было закрыть (скрыть), а открывались они из менюшки главного окна (которое постоянно открыто)
откр/закр окна так:

wind_CO.png (11.8 КБ) 7050 просмотров

как развлекаться с позицией окна - в приложении, там два варианта - кнопкой смещается на 10 точек вправо, в остальные стороны - по аналогии. если погладить картинку (белый квадрат), то окно двигается, но этот вариант заморочистей и окно дёргается. с другой стороны, такую зону можно расположить в главном окне, тогда дёргаться будет меньше.

ну и в довесок при закрытии окна (программы) полезно запоминать положения окон, чтоб при следующем запуске пользователю не приходилось всё снова растаскивать по своим углам

[Artem.spb]

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

[Jakob Brontfeyn]

Разные бывают, условия, эксперименты и пользователи, в моем случае
вся сила и удобство были в том,
чтобы манипулироватьокнами с VI, как стандартными окнами винды
размещать и сворачивать как удобно пользователю

[Jakob Brontfeyn]

Просьба передавать в LV 2009
ну и сюда можно заглянуть, так для развлечения
http://labviewportal.org/viewtopic.php? ... 608#p37801

[AndreyDmitriev]

Не надо давать ответ на первый традиционный русский вопрос:"Кто виноват?",
скорей всего, больше NI, чем Микрософт, потому что с окнами, например експлоера, такого не происходит.

Пожалуй больше таки Микрософт виноват - там навскидку вообще блокируются сообщения окну при зажимании кнопки минимизации. По идее в любой программе очередь сообщений должна вставать (впрочем, надо будет проверить).

Это присходит только в XP, в семёрке я этого не наблюдаю. От версии лабвью это не зависит - 2013 встаёт точно также.
Рецепты тут могут быть такие:
Перейти на Win 7.
Не использовать в циклах элементов, приводящих к переключению в UI поток. Если таких элементов в критичных циклах не использовать, то "встанет" только отображение, но сам цикл будет продолжать крутиться - соответственно таймаутов не возникнет. Так лучше поступать всегда, безотносительно проблемы, описанной выше.
Ну или сделать свою минимизацию/перемещение окон.

[Jakob Brontfeyn]

Извиняюсь Андрей, только что еще раз перепроверил на семерке, свой пример из форума, увы виснет.

"Не использовать в циклах элементов, приводящих к переключению в UI поток" не понял это предложение
Нельзя ли переделать мой пример в соответствии с этой концепцией

[mzu2006]

Я наблюдал такое в Windows с modern интерфейсом. Помогло переключение на классический.

[Artem.spb]

Разные бывают, условия, эксперименты и пользователи, в моем случае
вся сила и удобство были в том,
чтобы манипулироватьокнами с VI, как стандартными окнами винды
размещать и сворачивать как удобно пользователю

не вижу противоречий с моими рекомендациями - окон много так и остаётся, но все они управляются главным окном.
если ссылкой на параллельную темы вы хотели меня напугать, то вот вам мой ответ чемберлену :)

без графиков и всего прочего, т.к. оборудования дома на храню
а вот как оно выглядит в коде:

bl.png (8.54 КБ) 7007 просмотров

управление положением в девятке тут:

mw_v2 Folder2009.zip

(40.26 КБ) 164 скачивания

[Artem.spb]

"Не использовать в циклах элементов, приводящих к переключению в UI поток" не понял это предложение
Нельзя ли переделать мой пример в соответствии с этой концепцией

тут возможно придётся переделывать всю систему :)
как она устроена по скриншотам понять сложно, но раз вы вызываете независимо много vi, то вполне вероятно, что опрос приборов и рисование интерфейса у вас в одном цикле (о чём и говорится в том предложении)
чтоб мухи с котлетами друг другу не мешали, делается раздельно - в одном потоке (цикле, vi и т.п.) работа с приборами, в другом - рисование этого дела на экране.
куски общаются между собой событиями, очередями, по TCP в конце концов.
так же есть поверье, что этот параметр

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

[Jakob Brontfeyn]

Я наблюдал такое в Windows с modern интерфейсом. Помогло переключение на классический.

Я обязательно это тщательно перепроверю на ХP и семерке, но думаю, что ты не прав,
впрочем, если ты прав мне удасться часть удара отвести от себя в сторону Микрософта,
обвинив его в нетщательности тестирования новых разработок.
Проблема в том, что не хотят они с классическим интерфейсом винды работать.
Да что в такого слона как Микрософт бросаться горошиной, он ушибленное место,
не то что не почешет, а даже ничего не почувствует. А вот муравья, то бишь меня,
горошиной можно убить.

[Jakob Brontfeyn]

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

[AndreyDmitriev]

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

Артём, вы всегда сломя голову бросаетесь переделывать архитектуру при любой необъяснимой проблеме, не вникая в её суть?

Многооконность тут совершенно не при чём.
А суть в том, что отображение экранных элементов (а при некоторых условиях и циклы) в инструменте останавливаются при нажатии и удерживании кнопки минимизации окна. Единственное, что меня немного напрягает, так это то, что в Win7 я это воспроизвести не могу (точнее не так, как описывает автор - у меня только индикатор перестаёт мигать, причём только если он Modern), а автор - может. Кроме того, вызывание меню и выбор там пункта "переместить" также вообще не приводит к "зависанию", причём не приводит не только в win7, но и в XP. Чем-то условия наших тестов отличаются. Да, я пользуюсь Win7 Home Prof SP1 и WinXP Prof SP3.
Однако что воспроизводится стабильно, так это отсутствие обновления передней панели под XP.

Легко показать, что нажатие кнопки минимизации и её удержание в числе прочих эффектов просто блокирует поток UI - отсюда и проблемы с таймаутами.

Тут требуется, возможно, небольшое отступление про User Interface систему исполнения. Каждый инструмент в каждый данный момент времени исполняется в той или иной системе выполнения (Execution System). Предпочтительную систему исполнения можно выбрать в том окне, которое выше привёл Артём. При этом выбор этой системы не гарантируется, но при возможности будет использована именно заданная. Там всего шесть систем - user interface, standard, instrument I/O, data acquisition, other 1, other 2. По умолчанию для всех SubVI используется same as caller. Системы standard, instrument I/O, data acquisition, other 1, other 2 на самом деле ничем не отличаются друг от друга. Имена им даны просто для удобства пользования, но физически там отличий нет (то есть, скажем VISA будет работать одинаково хорошо и в standard, и в instrument I/O). По умолчанию используется Standard. Кроме того, надо понимать, что инструмент может переключаться из одной системы исполнения в другую и обратно при необходимости (именно поэтому там стоит Preferred...). Едем дальше. В рамках каждой системы исполнения LabVIEW выделяет несколько потоков. Их количество зависит от многих параметров - версии LabVIEW, конфигурации компьютера, некоторых настроек. Для простоты можно считать, что для последней версии LabVIEW на многоядерном компьютере нам для каждой системы исполнения выделяется количество потоков, равное количеству ядер - именно это даёт нам возможность параллельного исполнения. Особняком стоит система исполнения user interface - для неё нам выделен только один поток. Если мы используем узел свойств (Property Node), либо, скажем, вызов DLL в UI потоке, то в этом случае происходит переключение системы исполнения в User Interface, затем требуемый узел исполняется в потоке UI. Если этот поток занят, то мы ожидаем его освобождения и только после этого наш инструмент продолжит исполнение, а после окончания переключится обратно в систему исполнения, которая использовалась ранее. Предпочтительная система исполнения User Interface используется для того, чтобы избежать многочисленных переключений туда-сюда при наличии на блок-диаграмме часто используемых элементов, требующих переключения в User Interface, скажем, Property Nodes. Но главное не это, а то, что нам в этой системе исполнения предоставлен один-единственный поток. Ладно, перейдём от слов к делу.

Проще всего проиллюстрировать вышесказанное на простом примере с двумя циклами:

19-01-2014 11-25-54 - ui1.png (4.01 КБ) 6994 просмотра

Различие тут простое - во втором цикле используется Property Node. Теперь, если заблокировать UI поток (проще всего это сделать, вызвав, скажем диалоговое окно через MwssageBoxA в UI потоке)

19-01-2014 11-45-25 block ui.png (6.66 КБ) 6994 просмотра

, то мы увидим, что первый цикл продолжит свою работу, а второй - остановится. Если перейти на XP, и зажать там кнопку минимизации, то оба индикатора перестанут обновляться, однако после отпускания кнопки станет видно, что несмотря на необновляющийся индикатор, первый цикл продолжал свою работу, а второй - остановился. Это как раз то, чего надо избегать в во времякритичных циклах (окей, я в курсе, что Windows не есть ОСРВ) - не использовать любых элементов, вызывающих переключение в поток UI.
Проверить своё приложение проще простого - достаточно откуда-нибудь вызвать такой вот диалог - функциональность приложения не должна пострадать. Если же где-либо возникают таймауты, то имеет смысл проверить соответствующие циклы на наличие элементов, исполняющихся в UI потоке и разнести их в разные циклы. Где-то так.

[AndreyDmitriev]

думаю сейчас, как сделать красиво функцию "свернуть-развернуть" окно.
Смотрите полуфабрикатный пример.

Это радикальный способ, впрочем, пожалуй, единственно возможный. Надо сказать, что проблему с таймаутами можно решить и так, как я выше написал. Однако проблему с обновлением индикаторов на панели при удержании кнопки минимизации можно решить лишь заменой этой кнопки на свою - это так.
Для "свернуть-развернуть" проще всего FP.State использовать - тогда это ничем не будет отличаться от того, что делает операционная система. Ну ещё при изменении размеров придётся аккуратно менять положение кнопок - они должны быть справа. Проще всего разбить сверху заголовок сплиттерами - тогда они сами перемещаться будут (но в старых LabVIEW сплиттеров нет).

[IvanLis]

Никогда на столько не вникал во все тонкости, но в Linux мне заблокировать ничего не получилось