Когда же исправите импорт переменных (чтоб без дублирования), а с обновлением по имени адресов и описаний?
Дайте надежду, что это хотя бы у вас в TODO!
P.S. крик души после экспорт/импорта/переназначений адресов вручную при агрегации с внешней диспетчеризацией
Данная задача действительно есть в TODO, ожидается, что к концу года это будет реализовано. Сейчас прорабатываем требования. Пока что планируем доработать импорт переменных, сделав выбор из нескольких вариантов при совпадении имен:Сообщение от kaftanati
1. Дублировать переменные с совпадающими именами
2. Пропустить переменные с совпадающими именами
3. Заменить переменные с совпадающими именами
К п.3 пока больше всего вопросов, так как не очень ясны сценарии, где это может пригодится. Я так понимаю, вы хотели бы это видеть при импорте сетевых переменных. А при импорте стандартных это может пригодиться?
Менеджер по продукту | Owen Logic
Поясню по п.3 - почему именно он самый важный:
1. Создается программа с картой регистров (локальных/сетевых, не суть).
2. Привязывается к блокам/выходам, на холсте.
3. Потом, требуется подвинуть часть регистров из-за добавления новых/удаления старых - для задач диспетчеризации/панели/внешние источники данных, тоже не суть.
4. И встает вопрос, как обновить адреса для имеющихся параметров (или только описание/пределы) - если при импорте внешней карты они дублируются.
5. А все привязки на старых регистрах.
6. И не выпускает с редактора параметров, пока не уберешь дубли. Только удалять/переадресовывать тут же.
Получается, что в текущей реализации воспользоваться импортом (с пользой) можно только один раз - при импорте из внешнего источника в пустую программу, чтобы не возникло конфликтов адресов/имен и привязок.
Возможно эта проблема у большинства пользователей не встает, но при сложных распределенных системах, когда количество ПР в одном проекте измеряется десятками, а карты регистров из внешнего единого источника - это важный функционал в разработке.
Спасибо за ответ и очень прошу не откладывать с реализацией (готов тестировать хоть прям сейчас в формате бета-версий).
P.S. А вот п.1 и п.2 как раз не представляю, когда нужны. Не сталкивался
Да, соглашусь во всём с kaftanati - именно эта реализация и нужна.
Впервые такой импорт встретил в панелях оператора Weintek - сразу увидел, как это удобно.
Мне кажется, что механизм импорта одинаков и для стандартных и для сетевых переменных.
Где может пригодиться - массовый перенос из одной логической папки в другую, смена уставок, смена энергонезависимости и других атрибутов, применение собственной сортировки переменных в логической папке (т.к. вновь добавленная переменная оказывается внизу, а хотелось бы для удобства разместить её среди связанных логикой).
Чтобы сделать удобным встроенный редактор переменных - понадобится воспроизвести часть функций Excel и удобной надстройки над ним Ёxcel - таких как протягивание с нумерацией, массовые операции копирования (столбцами и строками), дополнения текстом начала или конца содержимого множества ячеек, поиска и замены.
Для сетевых переменных возможность будет востребована в сценарии - во время выполнения проекта или зарезервировал много переменных или отказался от некоторых - в адресации появились пропуски, которые мешают групповому чтению. Неиспользованные переменные можно удалить, а адреса пересчитать (очень просто в Excel) и импортировать со сплошным использованием.
При видеоинтервью я может быть явно не озвучил причину, но всячески подчёркивал, что переменные буду объявлять (импортировать) лишь после завершения всех остальных работ (создания необходимых макросов и размещения всех ФБ на холсте) - т.е. переменные это самый конец работы. И причина этому - одноразовый импорт.
Правда, это нужная возможность - обновление свойств сетевых и стандартных переменных при импорте. Затрудняюсь сказать, как быть при смене типа - наверное, если переменная не использована - обновить вместе с типом, иначе - предупредить и игнорировать обновление.
Ваши права
Ответить с цитированием