|
||
| Правила | Регистрация | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны | Справка по форуму | Файлообменник | |
|
Поиск в этой теме |
|
||||
Регистрация: 10.08.2013
Сообщений: 11,004
|
skkkk,
1. Где фильтрация по расширенным данным? 2. если на алгоритм работы какой то программы влияет внешний вид блоков - то тут уже не пользователей ограничивать надо, имхо..)) |
|||
|
||||
Регистрация: 20.03.2008
Сообщений: 2,653
|
Ну так ведь у меня нет данных по этим данным расширенным. Потому я там оставил комментарий в коде:
----- добавлено через ~5 мин. ----- Код, разумеется, в качестве готовой, рабочей программы не годится. Кроме того, нужно еще учитывать возможность контекстного редактирования блока, обработка которой также не прописана в коде. Это просто черновик своего рода. |
|||
|
||||
Регистрация: 10.08.2013
Сообщений: 11,004
|
так ранее и писал
а потом понял - что это будет работать, если супер-сознательные пользователи, всегда выделяющие блок перед вызовом команды редактирования блока. Т.е. что-то из области фантастики) |
|||
|
||||
Регистрация: 20.03.2008
Сообщений: 2,653
|
Сколько знаю пользователей, все редактируют блоки по двойному клику на блок с последующим нажатием "ОК". Кто и зачем станет набирать команду в строку? Ну, допустим, кто-то хочет редактировать блок иначе, и знает про кнопку _BEDIT. Нужно в общем, подумать, как фильтровать, но это не самое важное в данном случае, на мой взгляд.
Тут я бы в первую очередь озадачился подходом в принципе. Исходных данных для полноценной думы маловато. Расширенные данные (РД) вносятся куда? Во вхождение блока или в его описание? По какому принципу программа должна понять, какой именно блок можно редактировать, а какой - нет? Очевидно, если РД добавлены в одни вхождения, а в другие - нет, то редактирование описания при двойном клике на вхождение без РД изменит и одноименные блоки с РД - и тогда вся затея накрывается медным тазом. Если же РД добавляются к описанию, так почему бы тогда не запретить редактирование просто перечня блоков по их именам? Допускаю, что во избежание вероятного их переименования, ОК. В любом случае, проверить при срабатывании реактора наличие РД у описания блока проблем не составит. И повторюсь: в данном случае у меня лично большие сомнения вызывает необходимость использования реакторов. А код я выложил больше в качестве результатов своего баловства, причем, в качестве намёка о серьезности намерений там перед ним соответствующий смайлик разместил. Однако, в случае, если все же есть объективная причина использовать реакторы, то можно и попробовать - главный вопрос темы (запретить редактирование блока с помощью редакторов) решён. Пусть и не вполне красиво (в идеале-то было бы вообще не допустить редактирования), но и лучше, чем в исходной задаче: не через _UNDO, а через моментальное закрытие редактора блоков в случае, если редактирование данного блока "запрещено". |
|||
|
||||
Регистрация: 26.06.2007
Воронеж
Сообщений: 151
|
skkkk, в функцию действия не посылается объект (блок), для которого вызывается редактирование, поэтому в ней (в этой функции) не получится проверить нужное условие: есть ли у блока расширенные данные или нет.
Расширенные данные вносятся заранее (при вставке блоков) во вхождения блоков. Соответственно, если у редактируемого блока есть эти РД (допустим, (1000 . "UGO") приложения "myapp"), то нельзя давать изменять его в редакторе блоков. Одинаковых (на вид и имя) блоков, где бы у части из них не было РД, нет. Тема так называется, потому что первое, что пришло мне на ум при размышлении над задачей с таким условием (при этом не внося изменения ни в блоки, ни в словари) — это работа с реакторами. Последний раз редактировалось Tonic, 30.01.2020 в 17:53. |
|||
|
||||
Регистрация: 20.03.2008
Сообщений: 2,653
|
А что же мешает его послать? Можете более детально изложить суть задачи? Ну и снять-таки возникшие в процессе обсуждения вопросы:
1. Допустимо ли отказаться от внедрения реакторов всем пользователям, вместо этого изменив всем операцию при двукратном нажатии на блок? 2. Куда вносятся расширенные данные? Во вхождение блока (то есть в конкретный его экземпляр) или в его описание? 3. Каков формат и состав этих РД? Ну и файл бы приложить не мешало. Последний раз редактировалось skkkk, 30.01.2020 в 17:58. |
|||
|
||||
Регистрация: 26.06.2007
Воронеж
Сообщений: 151
|
1. Допустимо. Только почему речь о двукратном нажатии? У меня при этом появляется окно "Редактор атрибутов блока", а речь о "Редакторе блоков" (вызывается из контекстного меню).
2. Расширенные данные вносятся во все вхождения блоков (эти блоки вставляются программно, поэтому с этим проблем нет). 3. У всех "наших" блоков есть группа 1000 со значением "UGO", имя приложения для РД у них тоже одинаковое. Суть задачи: сделать так, чтобы при открытии чертежа с "нашими" блоками их нельзя было отредактировать (например, изменить текст внутри блока). При этом допускается, что заранее в acaddoc была прописана функция, которая бы помогала в этой защите. Условие проверки я пишу такое: Код:
|
|||
|
||||
идущий по граблям Регистрация: 26.05.2005
Сообщений: 5,091
|
Для режима контекстного редактирования блока (который все равно придется обрабатывать) есть системная переменная REFEDITNAME, которая как раз показывает имя редактируемого блока. Для редактора блоков подобной переменной нет .
Хотя имя редактируемого блока и показывается в окне редактора, но запрятано глубже, и может даже недоступно через системные переменные или ActiveX |
|||
|
||||
Регистрация: 10.08.2013
Сообщений: 11,004
|
Цитата:
|
|||
|
||||
Регистрация: 20.03.2008
Сообщений: 2,653
|
Цитата:
Ну так и в это контекстное меню можно добавить свою функцию (команду). Цитата:
Ну, тогда в данном случае можно попробовать переопределить стандартные команды BEDIT и -BEDIT (пояснения в комментариях в коде): Код:
Код:
Только надо не забыть перезагрузить Автокад, чтоб переопределение BEDIT, произошедшее после загрузки предыдущего лиспа, отменилось Код:
Но реактор в данном случае менее предпочтителен, на мой взгляд. Других вариантов, кроме как открыть блок и закрыть его без изменений, похоже, нет, а это на загруженных чертежах будет нервировать, ибо будет небыстро. kp+, имя редактируемого блока нам, в общем-то и не нужно, потому что РД добавляются ко вхождению, а не к описанию (судя по тому, как Tonic их считывает). |
|||
|
||||
Регистрация: 26.06.2007
Воронеж
Сообщений: 151
|
skkkk, спасибо, это хороший и простой способ — переопределение команды. Минус в том, что нужно будет отредактировать имя команды для макроса контекстного меню. При этом если программу "защиты блоков" (для переопределения команды) не вызывать, команда в макросе так и останется "bedit", что будет означать появление лишнего окна (вместо _-bedit, как там написано изначально).
Ну или зашить в начало кода функции переопределения C:BEDIT изменение макроса контекстного меню (наверняка такая функция в autolisp/ActiveX есть), а в конце работы функции C:BEDIT снова восстанавливать значение в "^C^C_-bedit". |
|||
|
||||
Регистрация: 20.03.2008
Сообщений: 2,653
|
Что-то не очень я понял, о чем речь и в чем минус. Что плохого в том, чтоб изменить один раз вручную макрос для контекстного меню, если понадобится?
Я проверял на 2011-м и 2015-м - все работало без лишнего окна. В новых версиях, возможно, по-другому себя ведет, не знаю. Не помню уже, менял ли я там что-то в макросах, контекстными меню объектов мы не пользуемся, но у меня там стоит (в конце - пробел): Код:
Как в лиспе изменять макрос контекстного меню, я не в курсе - никогда не было такой нужды. Создал в свое время, давно все макросы, (уже лет 10 они сами макросы у нас не меняются - только коды исполняемых ими лиспов), а потом на новые машины (или новые системы после ремонта) делал всегда импорт адаптаций. И зачем макрос менять обратно потом? В самом лиспе переопределены обе команды: и BEDIT, и -BEDIT, - и обе они выполняют одну и ту же функцию, поэтому неважно, что из этого прописано в макросе на контекстном меню. Главное, чтобы в макросе точки не было, чтоб переопределенная команда вызывалась макросом. Чтобы этот код работал всегда, можно добавить в acaddoc.lsp строку загрузки лисп-файла из #30. Если файл обозвать "BEDIT.lsp" (предварительно положив его в папку, прописанную в путях доступа), то строка будет такой: Код:
Код:
Во всех случаях переопределение будет активно при любом запуске Автокада и обычные блоки даст редактировать, а РД-шные - не даст. Последний раз редактировалось skkkk, 31.01.2020 в 02:24. |
|||
|
||||
Регистрация: 26.06.2007
Воронеж
Сообщений: 151
|
Про "минус" я имел в виду следующее: если пользователь решит вдруг удалить лишний код из acaddoc.lsp (или сам файл — ну мало ли), или код вообще будет подгружаться не из acaddoc, а автоматически из "Загруженных приложений" в папке "Доверенные местоположения" (и пользователь удалит эти пути), тогда программа для переопределения вызываться не будет, но команда макроса при этом останется вручную изменённой — "bedit" вместо "^C^C_-bedit" (по умолчанию), а в этом случае редактор блоков вызывается не так, как нужно (вызывается окно "Редактирование переопределения блоков" вместо редактора блоков).
|
|||
|
||||
идущий по граблям Регистрация: 26.05.2005
Сообщений: 5,091
|
Вроде об этом уже писали выше - если пользователь умеет осознанно редактировать acaddoc.lsp, то с большой вероятностью самодельные защиты против него бессильны. Не разберется с ними сам - спросит на форуме Будет смешнее всего, если в этой самой теме
Только организационные меры, только хардкор. Offtop: Вы, кстати, так и не обозначили конечную цель и "целевую аудиторию" Вашей защиты блоков от редактирования. Что в тех блоках такого ценного, требующего защиты? И неужели среди сотрудников Вашей организации есть такие идиоты, которым нельзя просто сказать - "блоки такие-то редактировать не следует"? |
|||
|
||||
Регистрация: 20.03.2008
Сообщений: 2,653
|
Цитата:
|
|||
|
||||
Регистрация: 26.06.2007
Воронеж
Сообщений: 151
|
skkkk, без изменения макроса не получается: при выборе редактирования блока из контекстного меню вызывается команда "_-bedit", захода в тело функции переопределения не происходит. Пробовал также "на всякий случай" прописывать (помимо кода, представленного в сообщении 30)
Код:
kp+, да ничего особо ценного там нет, просто определённые блоки учитываются при расчёте спецификации, и поступила задача, чтобы раз люди пользуются автоматизацией, не переделывали блоки под свои нужды. В общем, всё это не слишком продумано, учитывая тысячу путей для обхода этих ограничений. |
|||
|
||||
Регистрация: 10.08.2013
Сообщений: 11,004
|
так почему просто данные для расчета спецификации не прописать в XData? И пускай правят блоки, а если снесут и XData - то и защита от редактирования работать не будет.
|
|||
|
Опции темы | Поиск в этой теме |
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Лисп для редактирования объектов блока. Можно ли без захода в редактор? | RrRR | LISP | 5 | 06.08.2018 19:08 |
Вставка блока. Окно редактирования атрибута. | JKF | AutoCAD | 4 | 13.03.2018 13:14 |
Имеется ли возможность ссылаться изнутри при создании блока на его же будущий номер ObjId ? | Tyhig | AutoCAD | 6 | 14.08.2017 17:56 |
Вставка блока с помощью иконки | RomanS | Программирование | 50 | 02.04.2010 11:33 |
Перевод имени блока в имя переменной и обратно | Supermax | Программирование | 11 | 14.12.2009 23:26 |