DxfCode.ExtendedDataAsciiString?
Попробуй:Нет, не помогаетКод - C# [Выбрать]
Возможно, имеет смысл хранить координаты точки во внутренней системе координат блока?А вот это идея. Только координаты точки я не храню вообще - я храню вектор от второй точки к первой. Значит перед тем как трансформировать точку с помощью BlockTransform, нужно произвести трансформацию координат. Или после... Запутался)) Да, нужно тестировать
А почемуВот в этой теме (http://adn-cis.org/forum/index.php?topic=7808.0) написано чем ) Эти коды не меняются при изменении блока через палитру свойствЦитироватьDxfCode.ExtendedDataAsciiString?
http://help.autodesk.com/view/ACD/2016/RUS/?guid=GUID-A2A628B0-3699-4740-A215-C560E7242F63
Чем код 1012 не устроил-то?
Мне думается, что тут надо как-то грамотно использовать оба преобразования: из МСК в ОСК и обратно.Думаю, что ты прав. Сначала МСК->ОСК, затем добавляем вектор, а затем ОСК->МСК.
Вот в этой теме написано чем )
Для контроля положения второй точки я использовал расширенные данные, которые хранят вектор между второй точкой и первой.
Можно попробовать. По коду 1012 я буду получать вектор, указывающий направление второй точки. Но вопрос в том-же - точка по коду 1012 будет меняться с объектом при изменении из палитры свойств? Если 1011 не меняется. то я на 80% уверен, что и 1012 не будетЦитироватьВот в этой теме написано чем )
1011 и 1012 ... Разницу чувствуешь?
Но вопрос в том-же - точка по коду 1012 будет меняться с объектом при изменении из палитры свойств?
Если 1011 не меняется. то я на 80% уверен, что и 1012 не будетЯ уверен в этом на 99%
Не зря же значения динпараметров хранятся во внутренней системе измерений блока.Думаю, достаточно будет только трансформаций в методе GetParametersFromResBuf(), который я отобразил в вопросе темы. Как я понимаю, в BlockTransform хранится информация относительно координат блока, а не относительно WCS. Сейчас попробую идейку...
Тут получается так: если хранить точку (вектор) в МСК, то ее нужнопересчитыватьперезаписывать и в случае редактирования "ручкой" и в случае изменения блока (поворот, масштаб, зеркало). А если хранить в ОСК - то только при изменении "ручкой".
А затем, что когда я через палитру свойств задам блоку масштаб, то точка с кодом 1012 останется в своем старом состоянии. Она не изменится, хотя должна будетЦитироватьНо вопрос в том-же - точка по коду 1012 будет меняться с объектом при изменении из палитры свойств?
А зачем ей меняться?
bender, наверное, имел в виду следующее: зачем конвертировать вектор в строку, если есть специальные коды в РД для хранения координат? Только он не те коды указал. В данном случае, можно использовать 1010, 1020 и 1030Хорошее замечание и предложение. Хотя к вопросу не относится ))
В данном случае, можно использовать 1010, 1020 и 1030.Только 1010. 1020 и 1030 - это Y и Z в dxf-файле. А в Lisp/ARX/.NET всё объединено в точку в группу 1010.
Вроде вот так получается:А тем временем - плохой вариант :(Код - C# [Выбрать]Но еще тестировать нужно
Только 1010. 1020 и 1030 - это Y и Z в dxf-файле. А в Lisp/ARX/.NET всё объединено в точку в группу 1010.Возможно. Я не проверял :)
зачем конвертировать вектор в строку, если есть специальные коды в РД для хранения координат
Только он не те коды указал
А затем, что когда я через палитру свойств задам блоку масштаб, то точка с кодом 1012 останется в своем старом состоянии. Она не изменится, хотя должна будет
В какой системе координат у тебя точки (и соответственно вектор)?Точки в мировой системе координат. Вектор я получаю между двумя точками, поэтому логично предположить, что что он не зависит системы координат.
Нужно как-то учитывать это расстояние между началом координат и точкой вставки блока.Тогда скорее не расстояние, а вектор из blockReference.Position в начало координат.
Возможно, имеет смысл хранить координаты точки во внутренней системе координат блока?Протестировал идею. Вроде отлично работает. Максимально упростил проект: убрал из проекта Jigs, оставил только ручки и XData.
Только 1010. 1020 и 1030 - это Y и Z в dxf-файле. А в Lisp/ARX/.NET всё объединено в точку в группу 1010.Проверил - да, так и есть. Причем, код 1010 отказался принимать вектор, только точку. Пришлось преобразовывать туда-обратно.
Александр Пекшев aka Modis, зачем именно вектор? Его всегда можно получить через разницу точек. Но уже не нужно будет этих преобразований при чтении/записи XDataВсе началось с того, что нужно получать вторую точку всегда в актуальном месте. Т.е. при любом преобразовании блока (как ручками, так и обычными методами автокада) эта точка всегда должна быть в верном положении. В какой-то момент (причин честно уже не помню) я решил использовать именно вектор. Но на тот момент я не смотрел в сторону BlockTransform, да и как вы могли заметить - не совсем так располагались примитивы внутри блока. Сейчас уже после не одного десятка всяких попыток и вариантов я начинаю склоняться к тому, что при использовании BlockTransform в XData уже можно попробовать располагать саму точку. И читая ее оттуда, преобразовывать с помощью BlockTransform. Просто после многократных тестов выплывают проблемы в совершенно разных местах, вот и получается - пробую разные варианты и начинаю засорять проект "остатками" от прошлых вариантов