Задизейблить много кнопок за раз

[TeaPot]

Привет.
Такой вопрос: Нужно в определенный момент работы программы задизейблить много разных кнопок и панелей. Я делаю это созданием Property Node-ов, но беда в том, что это занимает огромный объем в программе (Понимаю, что она резиновая, но не эстетично). Сделать SubVI тоже не вариант, т.к. все эти ноды принимаются подпрограммой на входе, потому места занимает не меньше. Можно ли как-то решить проблему с этим?
Заранее спасибо.

[dadreamer]

 

[Kosist]

В 2016 и выше можно использовать вот этот тулкит - https://forums.ni.com/t5/UI-Interest-Gr ... -p/3539490. Тогда проперти ноды вообще не будут нужны...

[dadreamer]

Тогда проперти ноды вообще не будут нужны...

Но ведь внутри тулкита по-прежнему вызываются Property/Invoke Nodes и следовательно эти SubVI запускаются в UI-потоке?

[Artem.spb]

  Enable-Disable Buttons.vi

во внутреннем цикле незачем перебирать все значения, лучше остановиться, как только искомая строка найдена.

С полгода назад возникла у меня задача в проекте реализовать некий внутренний поиск по большим объёмам данных. Например, есть массив кластеров [имя элемента - его параметры]. И мне нужен элемент определённого имени. Если в лоб, то это перебор в цикле, что довольно долго.
В том проекте данных довольно много, поэтому я остановился на варианте SQLite, живущего в памяти, но тогда же открыл для себя мощь типа Variant.
В нём есть неограниченное количество атрибутов любого типа, чем и можно лихо воспользоваться.
Почитав этот пост, озадачился тестом.
И вот что получается
сам исходник

результат для 130 батонов.
variant имеет микроскопическое время доступа, никак не зависящее от индекса. В то же время, чем дольше от начала массива элемент, тем дольше его поиск.

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

Итог: время доступа к свойствам variant не зависит от количества этих свойств, а вот при переборе зависимость очевидна.

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

И если уж тестировать, то до конца.
Вот тесты, не зависящие от доступа к UI. В массиве 1000 элементов. поиск последних на 3 порядка дольше, чем извлечение оных из Variant

[dadreamer]

во внутреннем цикле незачем перебирать все значения, лучше остановиться, как только искомая строка найдена.

Да, согласен. Но лень исправлять пост.

Всё это, конечно, интересно. Я часто использую вариант для работы с контролами и индикаторами. В реальной программе можно не перебирать элементы панели каждый раз - можно единожды получить имена (лэйблы), рефы и индексы и загнать эту инфу в вариант (пара "имя - реф", пара "имя - индекс"). Дальше вариант разослать по определённым SubVI. Нужно что-то сделать с элементом - сразу берём из варианта реф или индекс и используем. Вся работа с Property и Invoke - в цикле UI, работа по индексам - хоть где.

В принципе, хранение инфы в атрибутах варианта - решение далеко не новое. По ссылкам можно найти объяснения, почему этот подход быстрее традиционных.
https://forums.ni.com/t5/LabVIEW-Develo ... -p/3478922
ftp://ftp.ni.com/pub/events/webcasts/va ... _table.pdf

[Usss]

 

а я блин значит изобрел свою vi, которая делает тоже самое, а тут понимаешь уже есть TRef Get All FP References.vi. и даже тулкитов ставить не надо. Мир так жесток!

[dadreamer]

Usss, есть ещё и его "собрат", который выполняет почти то же самое: viewtopic.php?p=63648#p63648 Однако, после его использования нужно закрывать референсы.

[Blackman]

Полезная инструкция с примерами:
Obtaining References to Objects in an Unknown Target VI Using VI Scripting
http://zone.ni.com/reference/en-XX/help ... eferences/

[Kosist]

Тогда проперти ноды вообще не будут нужны...

Но ведь внутри тулкита по-прежнему вызываются Property/Invoke Nodes и следовательно эти SubVI запускаются в UI-потоке?

Да, но с точки зрения кода решение более гибкое, т.к. если в коде вызывать функции тулкита, и применять к интерфейсу определенный стейт, то определение состояния контролов/индикаторов можно изменять, не меняя кода. Т.е. тулкит считывает конфигурацию с xml файла - а его можно менять отдельно от кода, что есть плюс (как по мне).
Плюс ко всему, тулкит использует плагины для применения состояния - плагин для текста Caption, плагин для Disable/Enable State, для цвета контролов, и т.д. И можно добавлять в xml файл дополнительные плагины, не изменяя код.
Да и в целом, код чище; плюс не нужно изобретать велосипед с обработкой всех ссылок контролов/индикаторов - все уже написано )))
Один минус - тулкит работает для версии > 2016...