Наследование атрибутов библиотечного виджета
| Автор |
Сообщение |
|
Сообщение создано: 21. 05. 2009 [12:33]
|
|
fLegmatik
Азат Газизов
Создатель темы
Зарегистрирован(а) с: 19.02.2009
Сообщения: 16
|
Как известно из концепции среды визуализации, графические объекты в OpenSCADA хранятся в библиотеках виджетов и при необходимости вставляются в проект в необходимом количестве. Если вдруг потребуется изменить какой-либо элемент в составе виджета или какое-либо его свойство, все изменения тут же отразятся на дочерних виджетах в проектах. Это замечательно. Если же нам потребуется указать в проекте какое-либо особенное свойство у одного объекта, не затрагивая братьев-сестрёр (те, что "сын моего отца, но не я"), точно так же можно изменить любое поле, но уже не в библиотеке, а в самом проекте. Прекрасно! Теперь если мы поменяем это свойство у объекта в библиотеке, значение уникального сохранится. Всё логично.
Однако меня смущает то, что вкладки "Атрибуты", "Связи", "Обработка" выглядят абсолютно одинаково и для библиотечных виджетов, и для тех, что уже в проекте. Может возникнуть путаница в вопросе, наследуется ли рассматриваемое свойство проектного виджета от библиотечного или же является уникальным. Кроме того, не исключены случаи, когда скада-разработчик будет менять свойства библиотечного (проектного) виджета, думая, что он проектный (библиотечный).
Я предлагаю выводить те поля проектных виджетов, значения которых наследуются, серым цветом, а не чёрным. К тому же, при определённом старании скада-разработчик будет избегать серых полей, стараясь поместить всю неуникальную информацию в библиотеку.
Кроме того, если вышесказанное не лишено смысла, надо предусмотреть механизм, делающий поле проектного виджета наследуемым, на случай, если его значение будет по ошибке изменено.
Пишу этот пост по той причине, что, например, в демопроекте не сразу смог добиться отображения на кнопках вместо SO3, SO4, SO5 и т.д. названий своих объектов. Начал править /prj_AGLKS/pg_so/wdg_so3 и wdg_so4, поглядел -- названия поменялись. Вернулся в конфигуратор, но в ветку /wlb_Main/wdg_RootPgSo (выглядит так же, поэтому не заметил подвоха) -- удивился, почему там остались SO3, SO4. Но ничего, прописал заново, заодно все остальные кнопки, проверил -- все правильно отображается.
Пришла пора исправлять надпись на кнопке SO4, опять пошёл в wdg_RootPgSo , но надпись в визуализации не почувствовала моих изменений. Долго бродил по дереву и свойствам, пока не обнаружил, что старая запись осталась в /prj_AGLKS/pg_so/wdg_so4.
Ну ладно, это всего лишь 16 кнопок, а вот что делать, если такая путаница начнётся в сложной структуре со множеством вложенных друг в друга виджетов, я не знаю.
[Сообщение редактировалось 1 раз(а), в последний раз 22.05.2009 в 05:22.]
Окажу помощь в организации связи OpenSCADA <--modbus--> Овен ПЛК.
xmpp:ag@jabber.ufanet.ru
[Сообщение редактировалось 65535 раз(а), в последний раз 19.01.2038 в 03:14.]
|
|
Сообщение создано: 22. 05. 2009 [18:14]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
fLegmatik wrote:
Однако меня смущает то, что вкладки "Атрибуты", "Связи", "Обработка" выглядят абсолютно одинаково и для библиотечных виджетов, и для тех, что уже в проекте. Может возникнуть путаница в вопросе, наследуется ли рассматриваемое свойство проектного виджета от библиотечного или же является уникальным. Кроме того, не исключены случаи, когда скада-разработчик будет менять свойства библиотечного (проектного) виджета, думая, что он проектный (библиотечный).
Я предлагаю выводить те поля проектных виджетов, значения которых наследуются, серым цветом, а не чёрным. К тому же, при определённом старании скада-разработчик будет избегать серых полей, стараясь поместить всю неуникальную информацию в библиотеку.
Уже добавлено выделение уникальных атрибутов синим цветом текста.
fLegmatik wrote:
Кроме того, если вышесказанное не лишено смысла, надо предусмотреть механизм, делающий поле проектного виджета наследуемым, на случай, если его значение будет по ошибке изменено.
А это давно есть и называется "Очистить изменения визуалного элемента".
fLegmatik wrote:
Пишу этот пост по той причине, что, например, в демопроекте не сразу смог добиться отображения на кнопках вместо SO3, SO4, SO5 и т.д. названий своих объектов. Начал править /prj_AGLKS/pg_so/wdg_so3 и wdg_so4, поглядел --
Это в демо вообще грузится динамически из списка доступных групп сигнализации в дереве проекта. Отсутствующие кнопки, при этом, скрываются и ничего руками менять не нужно, на главной странице.
fLegmatik wrote:
Ну ладно, это всего лишь 16 кнопок, а вот что делать, если такая путаница начнётся в сложной структуре со множеством вложенных друг в друга виджетов, я не знаю.
Всё оно сложно чего не знаешь. А как знаешь, то всё просто. 
И тут всё достаточно прозрачно, только в виду значительной гибкости и вариантов формирования интерфейсов всего и не охватишь сразу.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 06. 2009 [09:08]
|
|
fLegmatik
Азат Газизов
Создатель темы
Зарегистрирован(а) с: 19.02.2009
Сообщения: 16
|
roman wrote:
А это давно есть и называется "Очистить изменения визуалного элемента".
В версии 0.6.3.1 не было. Поставил 0.6.3.3, теперь вижу.
Но это не совсем то. Я хочу сбросить к дефолтному один атрибут, а не все. Если сбросить все, по сути надо будет возвращать уже приданную объекту уникальность вновь.
roman wrote:
Уже добавлено выделение уникальных атрибутов синим цветом текста. Добавлено, но не везде. Лучше выделять синим не имя атрибута, а его значение! Дело в том, что у некоторых полей имя вообще не выводится. Пример: текст процедуры/программы на закладке "Обработка".
Или поля на этой закладке уже не именуются "атрибутами"? В любом случае выделять их тоже надо.
Окажу помощь в организации связи OpenSCADA <--modbus--> Овен ПЛК.
xmpp:ag@jabber.ufanet.ru
[Сообщение редактировалось 65535 раз(а), в последний раз 19.01.2038 в 03:14.]
|
|
Сообщение создано: 11. 06. 2009 [20:23]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
fLegmatik wrote:
В версии 0.6.3.1 не было. Поставил 0.6.3.3, теперь вижу.
Но это не совсем то. Я хочу сбросить к дефолтному один атрибут, а не все. Если сбросить все, по сути надо будет возвращать уже приданную объекту уникальность вновь.
Если объект разработан нормально то сбрасываться будет не многое. Впрочем попробую сделать индивидуальный сброс.
fLegmatik wrote:
Добавлено, но не везде. Лучше выделять синим не имя атрибута, а его значение!
Не лучше, вы типы значений видели какие бывают?
fLegmatik wrote:
Дело в том, что у некоторых полей имя вообще не выводится. Пример: текст процедуры/программы на закладке "Обработка".
Или поля на этой закладке уже не именуются "атрибутами"? В любом случае выделять их тоже надо.
А это не атрибут вообще и контроля для него нет.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 19. 06. 2009 [15:28]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
roman wrote:
fLegmatik wrote:
В версии 0.6.3.1 не было. Поставил 0.6.3.3, теперь вижу.
Но это не совсем то. Я хочу сбросить к дефолтному один атрибут, а не все. Если сбросить все, по сути надо будет возвращать уже приданную объекту уникальность вновь.
Если объект разработан нормально то сбрасываться будет не многое. Впрочем попробую сделать индивидуальный сброс.
Добавил
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 23. 11. 2015 [09:43]
|
|
dorn
Максим Алексеев
Зарегистрирован(а) с: 24.10.2015
Сообщения: 17
|
Добрый день, Роман.
А можно добавить подобный сброс для связей?
Сейчас, если изменить связь, то потом уже не удаётся наследовать значение связи от родительского объекта.
Приходится удалять в базе вручную SQL запросами.
|
|
Сообщение создано: 23. 11. 2015 [10:36]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"dorn" wrote:
А можно добавить подобный сброс для связей?
Связи это тоже изменения поэтому сбрасываются они все вместе.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 23. 11. 2015 [10:49]
|
|
dorn
Максим Алексеев
Зарегистрирован(а) с: 24.10.2015
Сообщения: 17
|
Я имел ввиду сброс для отдельно взятой связи.
|
|
Сообщение создано: 23. 11. 2015 [11:02]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"dorn" wrote:
Я имел ввиду сброс для отдельно взятой связи.
Сбросом отдельно взятого атрибута, соответственно.
Learn, learn and learn better than work, work and work.
|
|
|
