[P_S]

Посмотрел я, как мается protorgovec с вставкой текста в рамку, и захотелось мне написать образцово-показательную программу, а заодно и показать взаимоотношения свойств Alignment, InsertionPoint и TextAlignmentPoint. Идея была проста: задаём тексту свойство Alignment «acAlignmentMiddleCenter» с точкой привязки в центре прямоугольника; Rotation – по длинной стороне прямоугольника; а далее, если метод IntersectWith возвращает точки пересечения текста с полилинией, задаём тексту Alignment «acAlignmentFit» и используем полученные точки пересечения в качестве InsertionPoint и TextAlignmentPoint.
Вот тут-то и оказалось, что в случае, когда стороны прямоугольника (lwpolyline, closed) развёрнуты относительно осей WCS, возвращаемые методом IntersectWith с опцией acExtendNone, отличаются от ожидаемых. Ставлю QTEXTMODE = 1, чтобы проанализировать геометрию пересечений, и вижу, что точки пересечения определяются по странному алгоритму (картинка прилагается). Пока видел это только с текстом (если заменить рамку текста полилинией – никаких неожиданностей.

Offtop: Что курят программисты Autodesk?
У меня – Civil 3D 2012 (лицензионный). Если это баг, то повторяется ли он в других версиях?
Offtop: Или баг у меня в голове после выходных (хорошо посидели)?

[Кулик Алексей aka kpblc]

Насколько я понимаю, для текста через аналог vla-getboundingbox виртуально строится описываемый прямоугольник, и разыскиываются пересечения именно этого прямоугольника с нужным контуром.

----- добавлено через ~6 мин. -----
Как вариант (пишу насухую)

Код:

[Выделить все]

(vl-load-com)
;; txt - полученный vla-указатель на текст
(vla-getboundingbox txt 'minp 'maxp)
(command "_.rectang" "_none" (vlax-safearray->list minp) "_none" (vlax-safearray->list maxp))

И посмотри, какие точки ты получишь.

[P_S]

Ну да, алгоритм именно такой, но зачем же они это сделали? То же самое, как я понял, учудили и с блоками. Если функция не возвращает нужный результат, это и называется багом. Может, давно уже пора bug report послать?