[Кудахтыч]

Есть вертикальный луч, он пересекает от 0 до нескольких полилиний, можно ли без цикла перебора большого количества (иногда несколько тысяч) полилиний как то определить количество пересекаемых лучом полилиний?
Как сделать в цикле я знаю: через проверку массива intPointsPD = APolyline.IntersectWith(ARay, acExtendNone), но для этого придётся ждать очень долго, тем более, что надо делать это ещё и с многими лучами, короче очень долго выходит с циклом по полилиниям.

[trir]

используй деревья

[Do$]

Если луч вертикальный, то можно воспользоваться методом множественного выбора объектов с опцией "секущая рамка". Высота рамки - весь чертёж, ширина - самая минимальная. Фильтр выбора настроить таким образом, чтобы в него попадали только полилинии. Только учтите, что этот метод работает только с теми объектами, которые в данный момент видимы на экране.

[Boxa]

Do$, по же самое написал в соседней теме... =о) Забавно.

[Do$]

Даже, есть более подходящий метод - SelectByPolygon с опцией Fence

Сообщение от Boxa Do$, по же самое написал в соседней теме... =о) Забавно.

Ну значит автор точно увидит это

[Кудахтыч]

Сообщение от trir используй деревья

А как использовать деревья в VBA?

----- добавлено через ~12 мин. -----
[quote=Do$;1780909]Даже, есть более подходящий метод - SelectByPolygon с опцией Fence

Можно конешь выбором с рамкой делать, но этож уже костыль на костыле получится.

[Сергей812]

Сообщение от Кудахтыч но для этого придётся ждать очень долго, тем более, что надо делать это ещё и с многими лучами, короче очень долго выходит с циклом по полилиниям.

вам уже Boxa писал в другой ветке:

Сообщение от Boxa отказаться от COM вообще и от VBA в частности... что позволит существенно ускорить работу программы.

хотите сделать систему, работающую c тысячами объектов без заметных лагов - либо придется городить костыль на костыле, либо уходите с ActiveX/VBA/Interop в NetApi/ObjectARX.

[Do$]

Сообщение от Кудахтыч Можно конешь выбором с рамкой делать, но этож уже костыль на костыле получится.

Fence - это не рамка, а секущая линия. Видео работы аналогичной команды: https://autode.sk/2TnEoOu
По-моему - это как раз то, что требуется для решения озвученной задачи. Не понимаю в чём костыльность.

[Кудахтыч]

Сообщение от Сергей812 хотите сделать систему, работающую c тысячами объектов без заметных лагов - либо придется городить костыль на костыле, либо уходите с ActiveX/VBA/Interop в NetApi/ObjectARX.

Ладно попробую SelectByPolygon с опцией Fence, раз там линия а не прямоугольник выбора.

Сообщение от Сергей812 хотите сделать систему, работающую c тысячами объектов без заметных лагов - либо придется городить костыль на костыле, либо уходите с ActiveX/VBA/Interop в NetApi/ObjectARX.

Я не программист, а проектировщик, и мне некогда изучать Lisp/C++/.Net/ObjectARX и т.д. Так бы я ваще утонул в дебрях более продвинутых языков и проекты было бы не когда делать, да и VBA среда есть не только в Автокаде, но и в МС Офис, а это удобно. Проги делаю делаю себе для автоматизации мелких задач, мне за них никто не платит, смысла так уж напрягаться пока не вижу.

[doctorraz]

Сообщение от Кудахтыч VBA среда есть не только в Автокаде, но и в МС Офис, а это удобно

удобно , но еще и более медленно..
в свое время специально тестировал скорость выполнения VB из внешнего приложения ехе, excel и встроенного в АК vba, так вот vba из под ак самый быстрый из перечисленных, на некоторых операциях на порядок.

[Сергей812]

Сообщение от Кудахтыч Я не программист, а проектировщик, и мне некогда изучать Lisp/C++/.Net/ObjectARX и т.д. Так бы я ваще утонул в дебрях более продвинутых языков и проекты было бы не когда делать,

здесь на форуме почти нет программистов по роду основной деятельности) Да и по образованию тоже врятли)

Сообщение от Кудахтыч да и VBA среда есть не только в Автокаде

По умолчанию с 2013 акада отсутствует, насколько помню. И запустить проект *.dvb без установки VBA enabler невозможно в принципе в отличие от других языков разработки. А для версий х64 до 2014 акада еще есть подводный камень.

Сообщение от doctorraz в свое время специально тестировал скорость выполнения VB из внешнего приложения ехе, excel и встроенного в АК vba, так вот vba из под ак самый быстрый из перечисленных, на некоторых операциях на порядок.

Interop из сборки *.dll работал на порядок быстрее внешнего приложения через COM. А быстродействие .Net на порядок-другой выше Interop. Все равно надо думать над структурой программой - но выгадывать каждое лишнее обращение к чертежу уже не требуется обычно.

[Boxa]

Сообщение от Кудахтыч Я не программист, а проектировщик, и мне некогда изучать Lisp/C++/.Net/ObjectARX и т.д. Так бы я ваще утонул в дебрях более продвинутых языков и проекты было бы не когда делать, да и VBA среда есть не только в Автокаде, но и в МС Офис, а это удобно. Проги делаю делаю себе для автоматизации мелких задач, мне за них никто не платит, смысла так уж напрягаться пока не вижу.

Работаю конструктором КЖ, однако в свое время прошел путь от QBasic - VB6 - VBA - VB.NET, сейчас пишу на C# ... прошел этот путь не потому, что мне очень хотелось, а потому, что не было времени на поиск костылей, обходных путей и прочих выкрутасов VBA.
И если уж на то пошло, то на .NET можно писать и под Офис и под Акад и под Ревит и под Теклу и Олплан и под чёрта в ступе, а среда разработки не только на пару порядков удобнее, но и вообще бесплатная.

[doctorraz]

Offtop: Дык никто ж не спорит, что СИ и NET круче и быстрее, только вот заставить себя это изучать при отсутствии насущной необходимости (и так что надо работает)

Мужик пилит бревно тупой пилой...
ему говорят, -Ты чооо, пилу поточи легче и быстрее будет!
а он... -Некогда мне точить, мне пилить надо ..

вот так и я ... да и не только я

[trir]

начинать надо с Препараты
а продолжить Ласло

[Кудахтыч]

Сообщение от trir начинать надо с Препараты а продолжить Ласло

Вычислять пересечения линий и плоскостей я умею, дело в быстроте разработки и исполнении кода.

[Сергей812]

Сообщение от Кудахтыч дело в быстроте разработки и исполнении кода.

ну когда со среды разработки VBA, которая остановилась в своем развитии чуть ли не 20 лет назад, пересаживаешься даже на бесплатную версию студии - тогда и понимаешь: что такое удобство и скорость разработки кода.

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

Offtop: ... но не удобство тестирования

[trir]

но не удобство тестирования

просто надо минимизировать взаимодействие с AutoCAD'ом

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

Это уже оффтоп будет, продолжать разговор по этой теме Может, создам топик - на предмет обучения чайников в .NET Ну или имеющийся продолжу )))

[Boxa]

Сообщение от Кулик Алексей aka kpblc Offtop: ... но не удобство тестирования

кому как... последние версии студии позволяют писать и править код во время отладки, так что разница с VBA IDE в этом плане вообще минимальна. С другой стороны, при определенном подходе, отладка занимает не так уж и много времени и не так уж и часто нужна при решении типовых задач....

[trir]

Вычислять пересечения линий и плоскостей я умею, дело в быстроте разработки и исполнении кода.

в этих книжках как раз это и описано - как быстро обрабатывать геометрию

[CalcProg]

офтоп
История программных революций от Microsoft,
вкратце.
Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION NFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они! Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC, решившая все наши проблемы ещё раз. Но OLE не собиралась сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов,
исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочёт, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!). Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они таки представили концепцию «System File Protection», исключающую DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие. Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но всё это почило раньше, чем все поняли, что это было. К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернетом. Недавно они пришли к пониманию, что у интернета есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET, похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень чётко понимать — .NET исключает DLL Hell. В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование… примерно на год.
----- добавлено через ~11 мин. -----
быстро обрабатываются только проидексированные массивы. тоесть массив перед этим нужно прошерстить по ряду характерных признаков либо сразу при добавлении в массив присваивать соответствующие индексы.