Авто индексация?

[Select]

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

[Artem.spb]

что такое новый индекс?
И что за связи в коде по индексу БОЛЬШОГО массива?
У вас в массиве 1000 элементов и вы получаете к ним доступ по константам?

[dadreamer]

[quote=="Select"]Существует ли возможность в настройках отключить для такой манипуляции авто индексацию новых элементов?[/quote]
Ничего подобного я в настройках никогда не встречал. Уверен, что решение гораздо проще, чем кажется. Покажите свою программу (фрагмент программы с описанной проблемой) и опишите конкретно на примере, что нужно получить и что реально получается.

[ujin]

Массив это упорядоченный набор элементов одинакового типа. Расположение элементов в массиве само собой не меняется.
Если Вы как бы закрепили каждое место в исходном массиве за определенным значением Вам необходимо и добавлять элементы согласно их предполагаемому местоположению, т. е по именованному индексу. Индекс может быть в виде ENUM, RING, текстовый массив с перечнем индексов.
Есть готовое решение CVT (Current Value Table).

[Select]

Речь идет о присвоении уникального имени каждому вновь вводимому элементу.
Так получилось что изначально была в алгоритме допущена ошибка порядка опроса состояний в стрингах, причем довольно большой группы ( около 160 с lical Variabl, хорошо если бы они не были бы внутри циклов в связке с передней панелью, но это есть.
Таким образом это как падающее домино. Одно тянет за собой другое и сплошное садомазо.

Если я хочу перенести много логики из другого все элементы кода для замены существующего с большим количеством блоков, каждый из них, включая в себя элементы передней панели получит от новые имена, при этом предыдущая часть блок диаграмм подлежит удалению, 50%, происходит картина "мама не горюй" и все из за того что не предоставляет функцию временного отключения авто индексации (я это называю так).
У меня заняло 4 дня на такой процесс, из них только день на исправление передней панели, там тоже все неоднозначно, но терпимо (более 200 элементов) день на возврат имен и дизайн панели управления и день на дебагинг, т.к. Local Variable около 200 все рухнули.
Сейчас это уже не актуально и в будущем вряд-ли это понадобится, я очень хочу в это верить .
Вот вид спереди, чтоб было понятно о чем идет речь.

[Kosist]

По теме - если под "автоиндексацией" Вы имеете ввиду присваиванее индекса к именам контролов/индикаторов, то если это произошло, можно все исправить скриптингом. Вытянете ссылки на нужный тип элементов - отфильтруете нужный "диапазон" имен, и переименуете как нужно. Главное, чтобы скриптинг был исполнен из другой виайки, а не с той, с которой манипулируете.
Ну а вообще, автоиндексация в - это нечно кардинально другое
Не совсем по теме. Траблы у Вас были, ибо никто не слушается NI когда они говорят что локальные переменные - это зло. Вот если бы тоже самое делали при помощи ссылок и узлов свойств, проблем бы было меньше.
Ну, и со скрина непонятно как устроена лицевая панель - но хочется верить, что у Вас там не отдельные контролы, а кластеры (как минимум группа из тех, которые находятся в одном ряде). Если же нет - то тогда понятно почему нужно было 4 дня на "линкинг" лицевой панели...

[dadreamer]

Есть такой хороший инструмент - TRef Get All FP References.vi или его скриптовый аналог Traverse for GObjects.vi: http://labviewportal.org/viewtopic.php?p=63648#p63648 На этапе инициализации программы можно обойти все контролы и индикаторы и сохранить рефы и индексы (ControlIndex) в отдельное хранилище. Для этой цели лучше всего подходит Variant с атрибутами или контейнер Map из последних версий . Хотя можно для простоты использовать и 2-3 отдельных массива. С помощью сопоставления Label - Ref, Label - Idx можно всегда и везде получить как текущее значение объекта, так и все его свойства. Единственное, что требуется - лэйблы объектов должны быть уникальными. Даже при перемещении кода из одной SubVI в другую ничего не поломается, если речь о вашей собственной программе. Другое дело, если код копируется из какого-то другого проекта. Тогда да, придётся причесать, не все и не всегда программируют по правилам. А так, >160 локальных переменных - это перебор. Старайтесь их использовать пореже. Кластеры-Тайпдефы иногда неплохо выручают.

[ujin]

Речь идет о присвоении уникального имени каждому вновь вводимому элементу.

Вариант с enum индексом - простейшая автоиндексация.
Имеем на входе 2 массива значений и имен и получаем таблицу индексов. Если имена в процессе работы не меняются, можно получение индексной таблицы вынести в инициализацию.

Еще простой вариант с автоиндексацией обмен в формате JSON. Сразу и имена и значения.
Фактически предыдущий вариант тот же JSON разделенный на 2 таблицы: имена и значения.
Если индикаторы объединять в кластеры, то имя переменной согласуется с типом LTREE в базах данных и системой классификации и кодирования на базе IEC 81346.
Имена не пробовал автоматически сформировать из кластера, нужно с рекурсией немного разобраться, если будет кластер в кластере.

[Select]

dadreamer,
Да, много sub vi, в которых нужно передавать и принимать от них данные. С кластерами не работаю т.к. получаются невероятно большой кабельный распределительный ящик в котором будет не просто докопаться до нужной точки.

[Select]

В том -то и проблема что экспортируемые лэйблы объектов целиком одинаковые. Того того что скрыто на tab Control 3 раза больше. Убираю то, что подлежит замене перед вставкой того же количества кода с аналогичным кодом, сыпется передняя панель и все связи
ujin
Мне не понятен ход мысли. Т.е. перед вставкой мне нужно весь код привести в тот вид, который у Вас, или это совсем не о том?