Для того чтобы пользователю заблокировать использование команды LOCK можно использоввать несколько всариантов:
1) Заблокировать использование этой команды через ыключение режима DAC (отключить возможность изменение атрибута LOCK для элементов: ALL ) - для обычных пользователей, и разрешить использование этой команды для администраторов проекта. В этом случае главным "блокировщиком" выступает администратор проекта.
2) Блокировать выполнение этой команды через командную строку (необходимо разрабатывать анализатор командной строки для cadcbth.callback = ваш анализатор , или собственное окно команд). Так же в данном случае необходимо убрать все "лишние " пункты из меню (LOCK, LOCK hIER).
3) Самый оптимальный и самый на мой взгляд замороченный метод. Разработка собственной подсистемы блокировки. Объясняю почему. При блокирование элемента через команду LOCK (атрибут LOCK) блокировка получается даже для администратора. Блокирование происходит на более низком уровне системы. И это исключает применение рахличных процедур для блокированного элемента для администратора, и смежных пользователей, например если труба была заблокирована одним пользователем ранее чем вторым, а второй хочет к ней приконектиться, то он обламается! Для разработки собственной системы блокирования необходимо:
- создать UDA атрибут ( или несколько атрибутов)
- включить DAC. И разработать сценарии работы в модели с использованием состояний ваших собственных атрибутов блокирования
По вопросу передачи заданий. У нас задания передаются через специально закодированный SITE и ZONE. Эти ZONE и SITE программно исключены из проверки на коллизии и прочие мониторинги. Сами задания создаются как параметрические шаблоны оборудования (фундаменты например). Можно выделить определённые классы фундаметов и обобщить их в одном шаблоне. При модификации задания ( ZONE ) присваивается индекс #1, #2, #3..... При этом блокируется от зменения ZONE c которой будет делаться новая версия задания. Когда строителт получают задание они начинают выполнять расчёты и строят свой фундамент уже реальный под шаблон-задание оборудование которое сделал теплотехник например. Могу сказать что шаблон-задание, шаблон-реальный фундамент взаимосвязаны кодировкой. У нас в PDMS полностью заменена часть именования элеметов с уровня SITE до уровня FRMW на собственные алгоритмы. Это позволило сформировать определённыек цепочки именования элементов и исключить ошибки пользователей при формирование имён заданий и не только.
Для того чтобы пользователю заблокировать использование команды LOCK можно использоввать несколько всариантов:
1) Заблокировать использование этой команды через ыключение режима DAC (отключить возможность изменение атрибута LOCK для элементов: ALL ) - для обычных пользователей, и разрешить использование этой команды для администраторов проекта. В этом случае главным "блокировщиком" выступает администратор проекта.
2) Блокировать выполнение этой команды через командную строку (необходимо разрабатывать анализатор командной строки для cadcbth.callback = ваш анализатор , или собственное окно команд). Так же в данном случае необходимо убрать все "лишние " пункты из меню (LOCK, LOCK hIER).
3) Самый оптимальный и самый на мой взгляд замороченный метод. Разработка собственной подсистемы блокировки. Объясняю почему. При блокирование элемента через команду LOCK (атрибут LOCK) блокировка получается даже для администратора. Блокирование происходит на более низком уровне системы. И это исключает применение рахличных процедур для блокированного элемента для администратора, и смежных пользователей, например если труба была заблокирована одним пользователем ранее чем вторым, а второй хочет к ней приконектиться, то он обламается! Для разработки собственной системы блокирования необходимо:
- создать UDA атрибут ( или несколько атрибутов)
- включить DAC. И разработать сценарии работы в модели с использованием состояний ваших собственных атрибутов блокирования
По вопросу передачи заданий. У нас задания передаются через специально закодированный SITE и ZONE. Эти ZONE и SITE программно исключены из проверки на коллизии и прочие мониторинги. Сами задания создаются как параметрические шаблоны оборудования (фундаменты например). Можно выделить определённые классы фундаметов и обобщить их в одном шаблоне. При модификации задания ( ZONE ) присваивается индекс #1, #2, #3..... При этом блокируется от зменения ZONE c которой будет делаться новая версия задания. Когда строителт получают задание они начинают выполнять расчёты и строят свой фундамент уже реальный под шаблон-задание оборудование которое сделал теплотехник например. Могу сказать что шаблон-задание, шаблон-реальный фундамент взаимосвязаны кодировкой. У нас в PDMS полностью заменена часть именования элеметов с уровня SITE до уровня FRMW на собственные алгоритмы. Это позволило сформировать определённыек цепочки именования элементов и исключить ошибки пользователей при формирование имён заданий и не только.
