Начну, пожалуй с «Ускорить черчение» (http://dwg.ru/b/topomap/78). Сама по себе идея (цитирую):
"использование единственного внешнего текстового файла самой простой формы и структуры. В этом файле описываются нужные общие параметры черчения, чертежей и AutoCAD, указания на все необходимые ресурсные файлы – файлы с описаниями блоков, слоев, типов линий, стилей текстов, размеров, мультивыносок, мультилиний, штриховок, листов"
Решение само по себе неплохое, но:
- Возникает вопрос с кодировкой файла. AutoLISP по умолчанию умеет обрабатывать файлы только в кодировке Windows-1251, а в какой кодировке будут создаваться файлы «в сторонних текстовых редакторах» — вопрос.
- Обязательно использование программного решения. Следовательно, структура такого файла определена достаточно жестко и изменению по первой хотелке — нереальна. Хотя бы потому, что обрабатывать файл придется программно, а там вольности особо не позволяются.
- Объем данных внутри такого файла при подобном описании превышает все мыслимые пределы. Описание, например, размерного стиля (включая подстили), может влегкую занять до 70 параметров. Сюда же — моментально — добавляем описание текстового стиля (мелочь, всего-то строк 10, но про нее забыть нельзя)
- Если предоставить пользователям свободу в изменении этого файла, то можно распрощаться с идеей стандартизации работы. Сразу и навсегда.
Идем дальше.
"Описания типов объектов состоят из их идентификаторов - названий типов объектов, наборов их графических свойств – типов примитивов, цветов, слоев, весов, стилей текстов, высот текстов и т.п., названий блоков, их масштабов, углов разворота и т.п. и т.д."
Отлично. Если забыть про тот факт, что той же самой LWPOLYLINE может быть отрисован контур вентиляционного отверстия, стол, контур комнаты, ось дороги и до фига чего еще. Следовательно, получается, что потребуются инструменты, которые будут указывать, что создавать, в какой последовательности, что рисовать и что делать при завершении работы команды. То есть хоть какой-то, но интерфейс. Дополнительная работа для пользователя, а в худшем случае — для программиста, которого подпишут на эту задачу.
"Кроме этого описания типов объектов содержат названия «таблиц» (XRecord, Object Data), в которых необходимо сохранять идентификаторы типов объектов, а так же нужную описательную информацию об объектах – об их «характеристиках». В том числе могут задаваться ограничения значений для полей этих данных – списки или диапазоны допустимых значений."
То же самое: проблема в интерфейсе. Кроме того, что такое «идентификаторы»? Хендлы? Так они могут влегкую меняться AutoCAD’ом при вставке файла как внешней ссылки. Я уже молчу про вопрос вставки файла как блока. Или вообще копипаста. ObjectID? Так это вообще работает только в текущем документе и в текущей сессии: стоит переоткрыть файл — и все, ObjectID уже оказывается другим. Что-то еще? А что? И как хранить? И где хранить? И каким образом обеспечить быстрый поиск данных по огромной базе чертежа? Ответ, конечно, есть: ObjectARX / .NET. Но в таком случае вариант «легкого изменения файлов настроек со стороны пользователя» может отправляться очень далеко: структура данных непредсказуема, что и как хранить — непонятно.
«В том числе, к одному графическому элементу можно присоединить любое число записей (XRecord, Object Data), включая и одинаковые. Т.е. один графический элемент можно определить как отображение многих типов объектов одновременно.»
Ага, только надо будет, во-первых, определить эти представления объектов, во-вторых, разработать (опять же!) интерфейс для их переключения и, в-третьих, предусмотреть, что и как будет отображаться.
«Во многом предлагаемая идея решения реализована в вертикальных приложениях AutoCAD – использование расширенных данных, меню объектов, автоматизация процессов поиска и проверок и т.п. Но они не доступны основному большинству пользователей, и специализированы, ограничены специализацией приложений (хотя и не во всем).»
Именно! Правда, стоят эти вертикальные приложения немного побольше, да и объем дополнительного функционала там зашкаливает. Autodesk четко понимает, что создать абсолютно универсальный инструмент, который подойдет и картографам, и строителям, и электрикам одновременно — нереально. Намного проще и дешевле создать несколько специализированных приложений и обеспечить их взаимодействие.
«Еще больше реализаций этой идеи в пользовательских приложениях - вероятно, мнигие сотни, может быть тысячи пользовательских программ, предлагающих свои меню объектов, автоматическую или полуавтоматическую загрузку ресурсов и настроек в dwg, способы описания и хранения характеристик объектов, в т.ч. в расширенных данных AutoCAD. И эти решения сильно привязаны к частным мнениям и предпочтениям, специализированны, чаще всего их пользователи зависимы от постоянного участия программистов и т.п.»
Правильно. Потому что «создать абсолютно универсальный инструмент…» — и далее по тексту.
«Ограничения в применении данной идеи связаны в первую очередь с трудоемкостью создания файлов описания стандартов черчения. С наличием и качеством готовых файлов описания.»
ИМХО — абсолютно неверное утверждение! Основная проблема будет в составлении задания и в разработке соответствующей программной начинки. Могу предложить автору статьи составить такое ТЗ, которое учитывало бы интересы самых разных специальностей, и увязать все это в единое решение.
«Предлагаемая идея реализована мной (как постановщиком задач) для вертикального приложения AutoCAD Map 3D на основе его расширенных данных – Object Data, и почти полностью повторена для базового AutoCAD на основе XRecord.»
Отлично! Прекрасный пример подмены понятий! В самом начале разговор шел про AutoCAD, и тут в игру вступает Map3D. В котором тьма вещей сделаны именно для определенной специализации. ObjectData — это «всего лишь» верхушка айсберга, которую видит конечный пользователь. А внутри это — достаточно жестко структурированный и взаимосвязанный комплекс словарей, записей и ссылок. Говорю как человек, который в свое время разбирался с программным представлением объектов AutoCAD Architecture.
«Уже одно только черчение из удобного меню объектов, поиск по типам объектов и по классификационным группировкам, поиск не определенных элементов дают общее снижение трудозатрат примерно на 10-20% и очень заметное улучшение качества чертежей. Остальные цифры в моем обещании ускорить оценочные, т.к. сейчас пока невозможно широкое производственное применение, тестирование и доработка. Обещания улучшить, упростить, расширить, создавать новые виды продукции и пр. в базовом AutoCAD вполне проверены и ответственны.»
Меню объектов? Отлично! Создай и покажи. Поиск по типам объектов? Создай и покажи. Поиск по классификационным группировкам? Не очень понимаю, что это — но создай и покажи. Но! — оно должно работать в чистом AutoCAD и (заодно, чтобы жизнь медом не казалась) показывать поиск по земельным участкам, армированию ЖБ ферм, фасонам для мет.ферм, выполненных из уголков до 50, деревянным окнам, балконным дверям из ПВХ, жилым комнатам и трубопроводам холодной воды не включая арматуру) в пределах дома.
Так что найти тех, «кто будет реализовывать такое решение», ИМХО, нереально.
Теперь насчет ToolPalettes (http://dwg.ru/b/topomap/79)
Я, конечно, приношу свои извинения, но показанный на скриншотах функционал не имеет никакого отношения к чистому AutoCAD. Ничего подобного там нет и никогда не было.
Автору следовало бы попытаться запустить чистый AutoCAD с новым профилем (см.ключи вызова AutoCAD в справке), установив в нем demandload равным 2 и посмотреть, что там есть и в каком варианте.
Дальше.
«меню объектов в Tool Palettes одноуровенные – в них невозможно полноценно реализовать классификации объектов, т.е. привязать к классификационным группировкам (классам, подклассам и т.д.) какие-то действия.»
Что за «классы и подклассы»? В чистом AutoCAD ничего подобного нет и никогда не было.
« Классификация в Tool Palettes реализуема сейчас только множеством Palettes, например, сколько классов – столько и Palette, а так же реализуется чисто зрительно – текстовыми строками и линейными разделителями в меню объектов. Вследствие этого для меню большого числа типов объектов требуется множество Palettes, возникает необходимость подгрузки множества Palettes вместо одной, необходимость переключения между Palettes»
Группировка палитр, вполне возможно, решит подобную проблему.
«повышается риск потери xml-файлов описания при их передаче или передача лишних таких файлов»
Это, простите, про что? Существует экспорт и импорт палитр, ничего не теряется и ничего лишнего (по крайней мере насколько я помню) не передается.
Дальше перечислю те моменты, которых в чистом AutoCAD нет и никогда не было (если я ошибаюсь, покажите вариант исполнения в чистом AutoCAD):
|
Стандартные меню в ToolPalettes для чистого AutoCAD достаточно ограничены. Так что реализация этого «стандартного меню» — отдельная песня. И очень длительная. Если есть решение — с интересом на него взгляну. Только для чистого AutoCAD |
|
Поиска в ToolPalettes нет. По крайней мере внутри AutoCAD — нет. Опять же — на готовое решение гляну. Для чистого AutoCAD |
|
Что значит «если»? В штатном режиме ее нет. Значит, надо разрабатывать, тестировать, расширять… На готовое решение… Хотя, я повторяюсь. |
|
Добавить — можно. Правда, сложно, долго и дорого. Готовое решение? Отлично! Где? |
|
В штатном режиме — нельзя. Ну или опять, готовое решение, посмотреть, бла-бла-бла… |
«Возможность всех этих дополнений уже заложена в самих Tool Palettes»
Ни-фи-га! Все эти решения будут определяться обработкой соответствующих событий и представлением соответствующей информацией. Т.е. программирование и ни на йоту более того.
