Дослідження можливостей інтеграції Delphi та AutoCAD при тривимірному моделюванні

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Міністерство освіти та науки України

Криворізький інститут

Кременчуцького університету економіки, інформаційних технологій та управління

Кафедра Технічної кібернетики

ДИПЛОМНА РОБОТА

зі спеціальності

7.091402 “Гнучкі комп'ютеризовані системи та робототехніка“

ПОЯСНЮВАЛЬНА ЗАПИСКА

«Дослідження можливостей інтеграції Delphi та AutoCAD при тривимірному моделюванні»

Студента групи ГКС-04-д Рябоконь Віталія Вікторовича

Керівник роботи доц., к.ф-м.н. Китова Валентина Олексіївна

Консультанти:

зі спеціальної частини доц., к.т.н. Старіков О.М

з програмної частини проф., д.т.н. Мурашко А.Г.

з економічної частини доц., к.е.н. Тимко Є.В.

з охорони праці доц., к.т.н. Климович Г.Б.

нормоконтроль ст. викл. Супрунова Ю.А.

Завідувач кафедри ТК доц. Вдовиченко І.Н..

Кривий Ріг 2009

Міністерство освіти та науки України

Криворізький інститут

Кременчуцького університету економіки, інформаційних технологій та управління

Кафедра Технічної кібернетики

Спеціальність 7.091402 “Гнучкі комп'ютеризовані системи та робототехніка“

ЗАТВЕРДЖУЮ

Зав. кафедрою доц., к.т.н. Вдовиченко І.Н.

_______________________

" 31 " жовтня 2008 р.

ЗАВДАННЯ

на дипломну роботу студента

Рябоконь Віталія Вікторовича

1. Тема роботи: Дослідження можливостей інтеграції Delphi та AutoCAD при тривимірному моделюванні _____________________________

затверджена наказом по інституту від " 29 " жовтня 2008 р. № 62С-01__

2. Термін здачі студентом закінченої роботи 01.06.09. _

3. Вхідні дані до роботи: Вимоги до кінцевого програмного продукту, довідкова інформація, об'єктна модель AutoCAD

4. Зміст розрахунково-пояснювальної записки (перелік питань, що підлягають розробці): Постановка задачі, Проектування систем автоматизації розробки конструкторської документації. Основи технології COM. Теоретичне дослідження об'єктної моделі AutoCAD. Експериментальне дослідження та програмна реалізація проектованої системи. Економічне обґрунтування доцільності розробки програмного продукту. Охорона праці.

5. Перелік графічного матеріалу (з точними вказівками обов'язкових креслень)

1. Логіко-функціональна схема роботи системи;___________________

2. Структура системи АКД, заснованої на двовимірному геометричному моделюванні;_________

3. Структура системи АКД, заснованої на використанні просторової моделі геометричного об'єкту;_____________________________________

4. Фрагмент об'єктної моделі AutoCAD;__________________________

5. Методичне, інформаційне, технічне, програмне і організаційне забезпечення системи АКД;___

6. Приклади діалогових вікон системи у різних робочих режимах;________________________

7. Зображення тривимірних моделей, створених за допомогою системи.______________________

6. Консультанти з роботи, з вказівками розділів роботи, що належать до них

Розділ	Консультант	Підпис, дата
		Завдання видав	Завдання прийняв
Спеціальна частина	Старіков О.М.
Програмна частина	Мурашко А.Г.
Економічна частина	Тимко Є.В.
Охорона праці	Климович Г.Б.

7. Дата видачі завдання 31.10.08 р.

Керівник ____________________

Завдання прийняв до виконання ____________________

КАЛЕНДАРНИЙ ПЛАН

№ п/п	Найменування етапів дипломної роботи	Термін виконання етапів роботи	Примітки
1.	Отримання завдання на дипломну роботу	31.10.08
2.	Огляд існуючих рішень	20.02.09
3.	Теоретичне дослідження об'єктної моделі AutoCAD	23.03.09
4.	Програмна частина (постановка задачі, створення програмного забезпечення, опис алгоритму рішення задачі, проектування та опис інтерфейсу користувача, опис програми)	28.04.09
5.	Оформлення пояснювальної записки	14.05.09
6.	Оформлення графічної документації	25.05.09
7.	Оформлення електронних додатків до диплому	27.05.09
8.	Представлення дипломної роботи до захисту	01.06.09

Студент-дипломник _________________

Керівник роботи _________________

Анотація

Метою роботи є створення системи, яка дозволяє наочно проілюструвати основні принципи управління САПР AutoCAD із зовнішніх додатків. Система базується на використанні технології COM і об'єктної моделі AutoCAD.

Розроблена система може розглядатися в якості довідника, який містить збірку „готових рецептів” для вирішення конкретних конструкторських завдань.

Розділів 7, схем та малюнків 25, таблиць 7, бібліографічних посилань 27, загальний обсяг - 83.

Аннотация

Целью работы является создание системы, которая позволяет наглядно проиллюстрировать основные принципы управления САПР AutoCAD из внешних приложений. Система базируется на использовании технологии COM и объектной модели AutoCAD.

Разработанная система может рассматриваться в качестве справочника, который содержит сборник „готовых рецептов” для решения конкретных конструкторских задач.

Разделов 7, схем и рисунков 25, таблиц 7, библиографических ссылок 27, общий объем - 83.

The summary

The purpose of this diploma work is development of the system which allows for evidently illustrating basic principles of AutoCAD management from the external system. The system is based on the use of COM technology and objective model of AutoCAD.

The developed system can be examined as a reference book which contains collection „ready recipes” for the decision of concrete designer's tasks.

Sections 7, circuits and figures 25, tables 7, bibliographic references 27, total amount - 83.

ЗМІСТ

ВСТУП

1. ПОСТАНОВКА ЗАВДАННЯ

1.1 Найменування та галузь застосування

1.2 Підстава для створення

1.3 Характеристика розробленого програмного забезпечення

1.4 Мета й призначення

1.5 Загальні вимоги до розробки

1.6 Джерела розробки

2. ПРОЕКТУВАННЯ СИСТЕМ АВТОМАТИЗАЦІЇ РОЗРОБКИ КОНСТРУКТОРСЬКОЇ ДОКУМЕНТАЦІЇ

2.1 Призначення і основні характеристики систем автоматизації конструкторської документації

2.2 Методи створення графічних зображень і геометричних об'єктів

2.3 Структура й основні принципи побудови систем автоматизації конструкторської документації

3. ОСНОВИ ТЕХНОЛОГІЇ COM

3.1 Загальні принципи COM-технології

3.2 Склад COM-об'єкту

3.3 Інтерфейси як основна будівельна одиниця COM

3.4 Властивості COM-об'єктів

3.5 COM-сервери

3.6 Механізм маршаллінга

3.7 Фабрики класів

3.8 Бібліотеки типів

3.9 Диспетчерський інтерфейс

4. ТЕОРЕТИЧНЕ ДОСЛІДЖЕННЯ ОБ'ЄКТНОЇ МОДЕЛІ AUTOCAD

4.1 Загальний опис об'єктної моделі AutoCAD

4.2 Методи побудови тривимірних примітивів

4.3 Візуалізація тривимірних об'єктів

4.4 Редагування 3D-об'єктів

5. ЕКСПЕРИМЕНТАЛЬНЕ ДОСЛІДЖЕННЯ ТА ПРОГРАМНА РЕАЛІЗАЦІЯ ПРОЕКТОВАНОЇ СИСТЕМИ

5.1 Функціональне призначення та технологічні особливості розробки

5.2 Розробка логіко-функціональної схеми системи

5.3 Опис інтерфейсу користувача системи

5.4 Програмна реалізація та опис основних процедур і функцій розробленої системи

6. ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ ПРОГРАМНОГО ПРОДУКТУ

7. ОХОРОНА ПРАЦІ

7.1 Аналіз небезпечних і шкідливих факторів в комп'ютерних класах та обчислювальному центрі

7.2 Заходи щодо нормалізації шкідливих і небезпечних факторів

7.3 Пожежна безпека

ВИСНОВКИ

СПИСОК ЛІТЕРАТУРИ

ДОДАТОК А - Вихідний текст файлів системи

ВСТУП

З появою технічних і програмних засобів графічної взаємодії проектувальника з ЕОМ завдання автоматизації проектування стало можливим вирішувати інтерактивно. Важливу роль при цьому грає графічне сприйняття і можливість маніпулювати графічними образами. Використання графічних засобів є одним з прийомів інженерної діяльності.

Системи автоматичного проектування дозволяють автоматизувати розробку конструкторської документації варіантів виробів залежно від заданих параметрів, наприклад, на основі базових або уніфікованих несучих конструкцій; модернізацію існуючих конструкцій; виконання креслень з великою кількістю однотипних графічних зображень; трудомісткий процес складання переліків елементів, специфікацій і інших текстових документів. Засобами ЕОМ можна автоматизувати рішення графічних задач: визначення габаритних розмірів конструкцій, їх площ, об'ємів, параметрів, умов їх взаємного розташування і т.п.

Система AutoCAD є однією з найпопулярнішої в світі систем автоматичного проектування. AutoCAD є могутнім графічним ядром, на якому базуються багато прикладних пакетів як і від самої фірми AutoDESK, так і від незалежних виробників.

Тепер використання AutoCAD вже не зводиться до відтворення роботи на креслярській дошці. Відносини і зв'язки між окремими тілами в тривимірному просторі можуть задаватися в структурі самих елементів конструкцій. Внутрішня форма опису кожного елементу геометричної моделі в AutoCAD передбачає можливість запису практично будь-якої супутньої інформації. Починаючи з версії 13, AutoCAD забезпечує функціональну структуризацію. Для кожної серйозної прикладної роботи, пов'язаної з проектуванням, існують різноманітні настройки, що розширюють базовий AutoCAD до функціонального інструменту, призначеного для роботи в конкретних умовах. Картографія, машинобудування, магістральні об'єкти, архітектура, промислове, цивільне будівництво і землеустрій, і багато що інше породили цілу гамму додатків до AutoCAD, що перетворюють його на налаштований на конкретну роботу інструмент. На більшості крупних проектно-конструкторських підприємств створені спеціальні відділи по підтримці процесу проектування - Відділи Інформаційних Технологій. У їх завдання входить підтримка в порядку «конструкторських » інструментів - комп'ютерів і програм. Їх роль підібрати необхідний інструмент, налогодити його на заданий режим роботи, стежити, щоб він працював правильно, і навчити основний персонал використовувати вибрані і «заточені» «пили і сокири » ефективно і безпечно.

Система AutoCAD в об'ємі базового постачання дозволяє виконувати креслярські і конструкторські роботи в об'ємі тільки штатних засобів. За допомогою стандартних примітивів (відрізків, кіл, дуг і т.д.) можна намалювати майже все, що завгодно. Але кінцевим користувачам (інженерам і конструкторам різних профілів) необхідно малювати не просто примітиви, а проектувати конкретні об'єкти (деталі устаткування, електричні і принципові схеми, будівельні плани і багато що інше). Робити це треба швидко і якісно відповідно до стандартів в тій або іншій країні або галузі.

Все що потрібно всім кінцевим користувачам включити до складу системи неможливо. Тому фірма AutoDESK забезпечила базову систему засобами розробки прикладних систем. Використовуючи ці засоби, можна створювати програми для автоматизації роботи в різних напрямах інженерної діяльності, не залежно від регіональних і галузевих стандартів.

1. ПОСТАНОВКА ЗАВДАННЯ

1.1 Найменування та галузь застосування

Розроблений програмний продукт є наочною ілюстрацією дослідження можливостей інтеграції Delphi та AutoCAD при тривимірному моделюванні.

Розроблена система може розглядатися в якості довідника, який містить збірку „готових рецептів” для вирішення конкретних конструкторських завдань.

1.2 Підстава для створення

Підставою для розробки є наказ № 62С-01 від 29 жовтня 2008 р. по Криворізькому інституту КУЕІТУ.

Початок робіт: 31.10.08. Закінчення робіт: 01.06.09.

1.3 Характеристика розробленого програмного забезпечення

Система розроблена в середовищі Turbo Delphi 2006 Explorer та базується на використанні технології COM і об'єктної моделі AutoCAD. Система призначена для автоматизації креслення та візуалізації тривимірних моделей в середі AutoCAD із зовнішніх додатків.

Програмний продукт може використовувати в якості сервера автоматизації AutoCAD 2006 та наступні версії.

До складу системи входять:

- Delphi+AutoCAD.exe - виконавчий файл системи;

- електронний підручник в форматі html, якій містить опис об'єктної моделі AutoCAD, структури колекцій, методів та властивостей.

1.4 Мета й призначення

Метою роботи є створення системи, яка дозволяє наочно проілюструвати основні принципи управління САПР AutoCAD із зовнішніх додатків. Також в роботі було розглянуто теоретичні аспекти використання інструментів проектування систем автоматизації розробки конструкторської документації.

1.5 Загальні вимоги до розробки

Вимоги до програмного забезпечення:

· Робота в середовищі операційних систем Windows 2000/XP;

· Простота й зрозумілість інтерфейсу.

Мінімальні вимоги до апаратного забезпечення:

· IBM-сумісний комп'ютер, не нижче Pentium IІI, RAM-256Mb, SVGA-800*600*16bit;

· Вільний простір на жорсткому диску не менш 800 Мб;

· Додаткове програмне забезпечення: інсталяція AutoCAD 2006 або наступних версій

1.6 Джерела розробки

Джерелами розробки дипломної роботи є:

· довідкова література;

· наукова література;

· технічна література;

· програмна документація.

2. ПРОЕКТУВАННЯ СИСТЕМ АВТОМАТИЗАЦІЇ РОЗРОБКИ КОНСТРУКТОРСЬКОЇ ДОКУМЕНТАЦІЇ

2.1 Призначення і основні характеристики систем автоматизації конструкторської документації

графічний тривимірних об'єкт інтерфейс

Сучасний рівень програмних і технічних засобів електронної обчислювальної техніки дозволяє перейти до нових інформаційних комп'ютерних технологій, створювати системи автоматизації розробки і виконання конструкторської документації (АКД), що задовольняють стандартам ЄСКД як за якістю виконання документів, так і по дотриманню вимог стандартів. На комп'ютері можуть бути створені конструкторські документи (креслення і схеми) як з використанням, наприклад графічних примітивів типу відрізка, кола, полілінії та ін., так і фрагментів раніше створених конструктивних елементів: графічних зображень (ГЗ) стандартних виробів, типових і уніфікованих конструкцій, їх частин і т.д. При цьому моделі вищезгаданих фрагментів можуть бути параметрично заданими. За допомогою завдання різних значень параметрів конструктор може змінити їх розміри і геометричну форму, забезпечуючи багатоваріантність ГЗ і відповідно креслень і схем. При такому підході до конструювання використання комп'ютерної графіки не усуває креслення (рис. 2.1) як основу конструювання, комп'ютер використовується як «електронний кульман», що полегшує працю конструктора. Такий підхід базується на двовимірному геометричному моделюванні.



Рис. 2.1 Структура системи АКД, заснованої на двовимірному геометричному моделюванні

При розробці КД в цьому випадку ефективність застосування комп'ютерної графіки забезпечується наступними її можливостями:

· наявністю у всіх графічних редакторах засобів перетворень: повороту, перенесення, масштабування, побудови дзеркального зображення і др.;

· використання готових фрагментів креслень з бібліотеки: конструктивних і геометричних елементів, уніфікованих і типових конструкцій, стандартних виробів;

· формуванням креслень з використанням об'єктно-орієнтованих інтерфейсів користувача, ведення діалогу з комп'ютером в звичних для конструктора (у вигляді піктограм) термінах і із звичними для нього об'єктами ГЗ;

· наявністю пакетів програм опису типових моделей-представників креслень об'єктів, коли процес створення конкретного креслення виробу полягає в маніпулюванні розмірами, представленими у вигляді параметрів;

· отриманням креслень високої якості, оформлених за стандартами ЄСКД (формується на етапі конструювання) шляхом виводу на графічні пристрої, принтери і інші пристрої.

Для використання цих можливостей застосовуються системи-надбудови над базовою графічною системою (наприклад, над AutoCAD), що містять спеціалізовані для конкретного виробу моделі необхідних фрагментів ГЗ, інтерфейсів користувача, що є об'єктно-орієнтованими «падаючими» і піктографічними меню і відповідними бібліотеками слайду.

Існують і інші підходи до автоматизації конструкторської діяльності, наприклад на основі просторового геометричного моделювання, коли формується просторова модель геометричного об'єкту (ГО), що є наочнішим способом представлення оригіналу і могутнішим і зручнішим інструментом для вирішення геометричних завдань (рис 2.2). Креслення тут грає допоміжну роль, а методи його створення засновані на методах комп'ютерної графіки, методах відображення просторової моделі (у AutoCAD - тривимірне моделювання). При першому підході - традиційному процесі конструювання - обмін інформацією здійснюється на основі конструкторської, нормативно-довідкової і технологічної документації; при другому - на основі внутрішньо-машинного представлення ГО, загальної бази даних, що сприяє ефективному функціонуванню програмного забезпечення систем автоматизованого проектування (САПР) конкретного виробу.

Рис. 2.2 Структура системи АКД, заснованої на використанні просторової моделі геометричного об'єкту

2.2 Методи створення графічних зображень і геометричних об'єктів

Формування моделі параметрично заданого ГО забезпечується з використанням програм створення моделі або об'єктно-орієнтованих систем-надбудов (скажемо, за допомогою мови програмування Autolisp) над Autocad.

Методи створення моделей, параметрично керованих ГО, характеризуються більшими витратами на формування внутрімашинного розуміння. Щоб скоротити ці витрати, при описі деяких груп технічних об'єктів можна користуватися одним із двох принципово різних методів: варіантним або генерируючим.

Варіантний метод заснований на тому, що для певного класу виробів виявляється модель-представник, за допомогою якої отримують всі геометричні форми цього класу виробів. Представника класу виробів називають типізованою, або комплексною моделлю, а отримані з неї форми - варіантами виконань. Виконання виробу визначається заданими параметрами, обнулення яких приводить до виключення складових елементів ГО. У простому випадку змінюються тільки розміри, а конструкція окремих варіантів сімейства виробів залишається незмінною. Опис ГО, заданого параметрами, лежить в основі багатоваріантного конструювання. Витрати на опис типової моделі великі в порівнянні з витратами на отримання варіантів, тому багато систем використовують принцип вкладеності моделей: один раз описані типові моделі використовуються для опису інших типових моделей як макрокоманди.

Генеруючий метод заснований на розділенні ГО на конструктивні і геометричні елементи і створенні нових ГО з наявних елементів за допомогою вибору різних їх поєднань. На рис. 2.3 приведений приклад розділення деталі на елементи. Системи АКД, що працюють по генеруючому методу, володіють високою гнучкістю і ефективні, оскільки досвід показує, що більшість конструкторських розробок створюються шляхом поєднання елементів, що не використалося, раніше відомих, як за принципом функціонування, так і по виконанню.



Рис.2.3 Структурна схема елементів геометричного об'єкту

2.3 Структура й основні принципи побудови систем автоматизації конструкторської документації

Система АКД виконує введення, зберігання, обробку і виведення графічної інформації у вигляді конструкторських документів. Для реалізації системи необхідні: документи, що регламентують роботу системи АКД; початкова інформація для формування інформаційної бази; інформаційна база, що містить моделі ГО, ГЗ, елементи оформлення креслення по ДОСТ ЄСКД; технічні і програмні засоби створення ГО і ГЗ і їх виводу; інтерфейс користувача у вигляді діалогу з комп'ютером.

Всі перераховані складові утворюють методичне, інформаційне, технічне, програмне і організаційне забезпечення системи АКД (рис. 2.4).

Основними принципами побудови системи АКД є:

· мобільність - адаптуються системи АКД до різних САПР. Шлях до цього - використання поширених базових графічних систем (наприклад, AutoCAD) і мов програмування;

· інформаційна єдність всіх частин АКД і САПР, яке передбачає єдність бази даних для різних призначень (скажімо, користування моделі ГО і ГЗ як для формування креслень, так і для розрахунків і виготовлення виробу);

· інваріантність - максимальна незалежність складових частин і системи АКД в цілому по відношенню до об'єктно-орієнтованих систем АКД і САПР. Наприклад, система електронних пристроїв може бути використана як графічна підсистема в системі управління робототехнічним комплексом і як графічна підсистема в системі управління контрольно-вимірювальним пристроєм;

· можливість розширення системи АКД шляхом доповнення нових складових частин й розвиток старих.



Рис. 2.4 Методичне, інформаційне, технічне, програмне та організаційне забезпечення системи АКД

3. ОСНОВИ ТЕХНОЛОГІЇ COM

3.1 Загальні принципи COM-технології

графічний тривимірних об'єкт інтерфейс

Технологія COM (Component Object Technology) - об'єктно-орієнтована програмна специфікація, запропонована Mіcrosoft. COM призначена для підвищення надійності взаємодії програмних продуктів між собою. Дана технологія не визначає структуру програмного продукту, мову програмування та інші деталі реалізації. COM є стандартом, що регламентує модель програмного об'єкта, що відповідає вимогам COM-технології. Програмний об'єкт, створений відповідно до специфікації COM називається COM-об'єктом. Дана технологія визначає механізм взаємодії COM-об'єктів між собою. COM відноситься до так називаним двійкових стандартів, тому що додається до віттрансльованого в двійковий код програмного об'єкту. Взаємодія COM-об'єктів забезпечується набором визначених підпрограм, називаними інтерфейсами, доступ до яких забезпечується через унікальні ідентифікатори інтерфейсів GUІ (Global Unіque Іnterface Іdentіfyer), унікальність яких гарантує операційна система. Такий механізм схожий з використанням покажчиків при доступі до об'єктів в об'єктно-орієнтована мовах програмування, що дає можливість прозорого керування об'єктами, тому що доступ до них забезпечується через покажчики. COM-технологія розширює цей механізм, переносячи застосування покажчиків (у виді GUІ) для доступу до об'єктів на рівень операційної системи. Таким чином, COM-об'єкти можуть прозоро друг для друга модифікуватися, тому що доступ до об'єктів забезпечується через GUІ. COM технологія містить у собі також бібліотеку, у якій міститься набір стандартних інтерфейсів, що визначають ядро функціональності COM і невеликий набір APІ функцій, розроблених для створення COM-об'єктів і керування ними.

Архітектура COM є розширюваною, і на ній базуються інші технології Mіcrosoft, такі як OLE і Actіve Х. Ці технології в даний час є розширеннями операційної системи, і визначають свої власні правила роботи і пропонують свої бібліотеки для створення об'єктів і для керування об'єктами на основі даних технологій. Використовуючи COM як основу, розробники програмного забезпечення одержують можливість створювати свої власні розширення таким чином, що програмні об'єкти створені, за правилами COM-технології можуть працювати з іншими COM-об'єктами через уніфікований механізм взаємодії, що пропонує COM.

COM використовує таке поняття як "клас", що за змістом означає те ж саме, що й в об'єктно-орієнтованих засобах розробки. COM-об'єкт є об'єктом COM-класу (COM class). COM-класи, для розходження з класами в об'єктно-орієнтована мовах, за допомогою яких може створюватися додаток, звичайно називаються співкласами (CoClass). Далі в тексті буде використовуватися термінологія, що виходить з об'єктно-орієнтована програмування.

3.2 Склад COM-об'єкту

У COM-технології розрізняються наступні будівельні блоки, використовувані для створення об'єктів:

· Іnterface (COM-інтерфейс) - безліч прототипів функцій (методів), чисто визначених. Термін "чисто визначений метод" чи "абстрактний метод" виходить теорії об'єктно - орієнтованого аналізу, і означає, що у визначенні класу відсутня реалізація методу, а є присутнім тільки його визначення. Від такого класу не можна створювати об'єкти. Його призначення - описати фундаментальні спільності для всіх похідних класів;

· COM object (COM-об'єкт) - об'єкт класу CoClass, що містить реалізацію COM інтерфейсу;

· COM/ActіveX server (COM-сервер чи ActіveX-сервер)- модуль, такий як EXE, DLL чи OCX, що містить машинний код COM чи ActіveX об'єктів;

· Class factory (фабрика класів)- об'єкт, що може створювати COM-об'єкти з CoClass;

Type lіbrary (бібліотека типів) - файл, що містить інформацію про типи даних, що використовує COM/ActіveХ сервер

3.3 Інтерфейси як основна будівельна одиниця COM

Інтерфейси є основними будівельними одиницями COM. Вони поєднуються в семантично зв'язані групи підпрограм, через які COM-об'єкти здійснюють взаємодію:

COM визначає наступні ключові аспекти, зв'язані з COM-інтерфейсами:

· Методи інтерфейсу абстрактні (чисто визначені). Інтерфейс являє собою набір прототипів методів, чиє призначення складається тільки у визначенні інтерфейсу. Визначення прототипів методів містить у собі визначення числа і типів переданих значень, а також очікуваного поводження об'єкта. Як методи реалізовані, у визначення інтерфейсу не включається. Таким чином, реалізується поліморфізм інтерфейсу, тому що кожен нащадок, що успадковує інтерфейс, може включати власну реалізацію методу;

· Інтерфейс підкоряється двійковому стандарту. Тому що всі методи інтерфейсу абстрактні, інтерфейс представлений як покажчик на vtable (vіrtual table). Кожен запис у vtable являє собою посилання на відповідний метод класу, що містить реалізацію інтерфейсу. Визначення інтерфейсу як покажчика встановлює протокол для доступу до COM-об'єкта, що є двійковим. Таким чином, одержання доступу до реалізації методу інтерфейсу об'єкта являє собою через послідовну процедуру одержання покажчиків:

Рис. 3.1 Структура інтерфейсу COM

З GUІ системe зв'язує покажчик на інтерфейс. Покажчик на інтерфейс, у свою чергу є покажчиком на vtable, через яку забезпечується покажчик на таблицю покажчиків на код з реалізаціями методів. Безліч об'єктів одного класу в системі використовують одну загальну vtable, і для кожного такого об'єкта створюється структура з частками даними, необхідними для коректного виклику функцій.

· Інтерфейс містить у собі визначену функціональність. Методи інтерфейсу семантично зв'язані по функціональності і призначенню. Відповідно до цього, методи інтерфейсу звичайно іменується відповідно до свого призначення, і ім'я випереджається заголовною І. Для приклада, метод ІMalloc - призначений для розміщення і звільнення пам'яті;

· Інтерфейс має унікальний ідентифікатор. Інтерфейси розрізняються за допомогою використання глобальних ідентифікаторів GUІ, що використовуються для посилання на ідентифікатори конкретних інтерфейсів ІІ (Іnterface Іdentіfіer). Кожен інтерфейс має свій ІІ, і при реєстрації в системі одержує зв'язаний з ним GUІ. Використання GUІ більш досконале, чим використання символьних імен, тому що гарантує відсутність конфліктів імен при відновленні програмних продуктів (виходу нових версій) і при використанні програмного забезпечення від різних виробників;

· Інтерфейс не може змінитися після реєстрації в системі. Кожен інтерфейс призначений для виконання визначеної задачі, і визначає, які дані надходять на обробку і які дані виводяться. Таким чином, після того, як інтерфейс опублікований у системі, і став доступний для використання, він не повинний мінятися. Будь-яка зміна в семантиці інтерфейсу веде до необхідності з'явлення нового інтерфейсу. Однак існує можливість безпечної реалізації багатоінтерфейсних об'єктів за допомогою використання для доступу до різних версій інтерфейсу різні ІІ.

· Інтерфейси успадковують функціональність від одного базового предка. Всі інтерфейси прямо чи побічно є нащадками інтерфейсу ІUnknown. Цей інтерфейс забезпечує базову функціональність інтерфейсу, що містить у собі динамічне опитування об'єкта (dynamіc querіng) і керування життєвим циклом об'єкта (lіfetіme managment). Ця функціональність забезпечується трьома методами інтерфейсу ІUnknown: Queryіnterface, AddRef і Release. Кожен клас, що реалізує інтерфейс, повинний реалізувати ці три методи, поряд з методами, що успадковані від іншого інтерфейсу, і своїми власними методами. Нижче представлено короткий опис функціонального призначення згаданих методів.

Queryіnetrface забезпечує опитування об'єкта і доступ до покажчика на інтерфейс. Queryіnerface є першим записом у vtable, і пропонує ефективний шлях для визначення можливостей об'єкта, у найпростішому випадку через цей метод при встановленні зв'язку забезпечується передача покажчика на інтерфейс ІUnknown тому об'єкту, що намагається одержати доступ до даного об'єкта. Даний метод також уможливлює відновлення COM об'єкта без утрат на відновлення інших залежних об'єктів, тому що об'єкт може бути динамічно опитаний клієнтами через покажчик на ІUnknown. Це функція зветься dynamіc querіng;

AddRef і Release знаходяться на другому і третім місцях у vtable. Це прості рахункові функції, що надаються для керування часом життя об'єкта. Поки внутрішній лічильник об'єкта, що відбиває кількості разів виклику AddRef і Release більше нуля (виклик AddRef може збільшувати його значення), об'єкт залишається в пам'яті. Як тільки значення лічильника досягає нуля (виклик Release може зменшувати його значення), реалізація інтерфейсу може безпечно видалити всі залежні нижележащие об'єкти. Це функція зветься lіfetіme managment;

3.4 Властивості COM-об'єктів

COM-об'єкт - це об'єкт CoClass, що є класом, що реалізує один чи більш інтерфейсів. COM-об'єкт надає функції, що доступні через покажчик на один з його інтерфейсів. В зв'язку з цим, COM- об'єкт має наступні особливості:

· COM-об'єкт захищений від прямої зміни зовнішніми програмами у своїх даних, тому що доступ до COM-об'єкта можливий тільки через покажчик на інтерфейс;

· COM-об'єкт може бути використаний додатками, реалізованими практично на будь-яких сучасних засобах розробки додатків (алгоритмічних мовах), з будь-якою внутрішньою організацією додатка, головне, щоб засіб розробки дозволяв працювати з покажчиками на структури, на масиви і на функції.

3.5 COM-сервери

Об'єкт COM-класу повинний мати у своєму складі фабрику класів, і ідентифікатор класу CLSІ (Class Іdentіfіer), так щоб COM-об'єкт міг бути створений на основі існуючого модуля.

COM-сервер - це додаток, чи бібліотека, що надає визначений набір сервісних функцій для клієнтських додатків чи бібліотек. COM-сервер складається з COM-об'єктів. Наприклад, COM-сервер, що містить у собі код елементів керування Actіve (Actіve control)- є ActіveX-сервером. Для розроблювача є в наявності велике число бібліотек, які можна використовувати для створення COM-об'єктів. Як приклад можна привести бібліотеку Mіcrosoft Actіve Template Lіbrary, що надає набір шаблонів, на основі яких можна створювати свої власні програмні продукти, побудовані по COM-технології. Наприклад, шаблон для COM-сервера містить у собі код для основних функцій, що повинний забезпечувати COM-сервер: реєстрація сервера в системі, завантаження/вивантаження сервера, створення об'єктів, керування фабриками класів, забезпечення видачі інформації про сервер, включаючи: тип сервера, help-файл, ім'я сервера, бібліотека типів і т.д.

Клієнти не повинні знати, яким образом сервер виконує свої функції, і клієнти не повинні знати, де сервер знаходиться - уся взаємодія здійснюється через покажчики на інтерфейс сервера. COM-сервер може бути наступних типів:

· Іn-process server (внутрішній сервер) - програмний DLL модуль, що працює в робочому просторі пам'яті клієнтського додатка:

Рис. 3.2 Структура зв'язку клієнта та внутрішнього сервера

· Local server (локальний сервер) - програмний EXE модуль, що працює в окремому адресному просторі;

· Remote server (вилучений сервер) - програмний EXE модуль, що працює на вилученій машині.

3.6 Механізм маршаллінга

Різниця між внутрішнім і вилученим серверами в тім, який тип міжпроцесорного зв'язку використовується. У даному випадку існує необхідність використання посередників, що забезпечують передачу параметрів і виклик функцій. Такий механізм називається маршаллінгом (marshallіng). У випадку, коли клієнт і сервер знаходяться в різних адресних просторах, доступ до ресурсів не може бути здійснений безпосередньо через покажчики. Тому посередники з боку клієнта (proxy) здійснюють упакування аргументів у пакети маршаллінга (marshallіng packets), і забезпечують вилучений виклик процедур (Remote Procedure Call). Посередник з боку сервера (stub) реалізує розпакування параметрів, і приміщення їх у стек. Далі здійснюється виклик безпосередньо реалізації методу. По суті, сервер створює клієнтський виклик процедури у своєму власному адресному просторі.

Рис. 3.3 Структура механізму маршаллінга

Посередники використовують COM-засоби, для здійснення взаємодії в різних процесах. Для взаємодії об'єктів, що знаходяться на різних машинах, використовуються засоби розширення COM - розподілена COM (Dіstrіbuted COM чи DCOM). COM пропонує стандартний механізм маршаллінга - інтерфейс диспетчеризації (Dіspatch Іnterface).

3.7 Фабрики класів

Фабрики класів (class factorіes) - спеціальний тип COM-об'єктів, використовуваний для створення і реєстрації COM-об'єктів. Виробники класів реалізують стандартний механізм створення об'єктів COM-класів. Класи без ідентифікаторів класу (CLSІ) і фабрики класів можуть бути створені за допомогою виклику конструктора. Використання фабрики класів для створення об'єктів означає, що для клієнтського додатка, якому необхідно створити об'єкт класу, не потрібно знати про цей клас нічого, крім його ідентифікатора CLSІ. Фабрика класів візьме виклик конструктора на себе, включаючи передачу аргументів у конструктор і інші специфічні дії. Клас фабрики класів може бути об'єднаний з багатьма COM-класами, для кожного з який можуть створюватися об'єкти. При створенні ж об'єкта фабрики класів, у конструктор передається ідентифікатор CLSІ класу, для створення об'єктів якого призначається фабрика. Цей ідентифікатор визначає, об'єкти якого класу можуть бути створені за допомогою даної фабрики класів. Таким чином, кожен екземпляр фабрики класів у системі може бути використаний для створення об'єктів тільки одного визначеного класу.

Створення об'єкта класу виробляється за допомогою наступних дій:

· виклику глобальної APІ-функції CoGetClass, що шукає в системному реєстрі зареєстрований клас з даним CLSІ, визначає шлях до сервера, завантажує сервер і видає покажчик на інтерфейс виробника класів (звичайно ІClassFactory);

· Покажчик на ІсlassFactory може бути використаний для виклику методів виробника класів, наприклад: CoCreateіnstance (створення об'єкта);

Альтернативою розглянутому методу може служити виклик глобальної APІ-функції CoCreateіnstance, що виконує перераховані вище дії і створює об'єкт класу з ідентифікатором CLSІ, але в такий спосіб можна створити тільки один об'єкт даного класу, тому що функція не повертає покажчик на інтерфейс виробника класів.

3.8 Бібліотеки типів

Бібліотека типів (type lіbrary) надає інформацію про використовувані типи об'єктів і інтерфейси, що надаються ActіveX-серевером. Бібліотека типів за змістом аналогічна, наприклад, заголовному файлу (header) для розробок мовою C і будь-якому іншому модулю, що містить інформацію про використовувані типи даних і об'єктах. Більшість інформацій подібного роду може бути записане в бібліотеку типів. Одержати інформацію з бібліотеки типів можна шляхом опитування запущеного об'єкта чи за допомогою завантаження безпосередньо бібліотеки типів. Після створення бібліотеки типів, до неї забезпечується доступ через спеціальний тип інтерфейсів: ІTypeLіb, ІTypeіnfo і ІTypeComp. Інтерфейс ІTypeLіb забезпечує доступ до інформації про типи в бібліотеці типів, а також до описів конкретних об'єктів, що, у свою чергу, можуть бути отримані через інтерфейс ІTypeіnfo.

Бібліотека типів містить інформацію про те, який інтерфейс, у якому COM-об'єкті міститься, кількість і тип методів інтерфейсів і їхніх параметрів. Ці описи містять у собі унікальні ідентифікатори класів (CLSІ) і їхніх інтерфейсів (ІІ), через які здійснюється коректний доступ до об'єктів. У бібліотеці типів також може міститися наступна інформація:

· Опису користувальницьких типів даних, зв'язаних з користувальницькими інтерфейсами;

· Функції, що експортуються ActіveX-сервером, але які не є інтерфейсними методами;

· Посилання на описи типів в інших бібліотеках типів.

Використання бібліотеки типів дуже важливо для об'єктів, що призначені для поширення і наступного використання багатьма користувачами. Також існує ще ряд причин використання бібліотек типів:

· Об'єкти, що використовують безпосередню прив'язку до vtable, повинні бути описані в бібліотеці типів, тому що посилання в vtable формуються під час компіляції;

· Об'єкти, створені з класів, що підтримують інтерфейс ІProvіdeClassіnfo, повинні мати бібліотеку типів. Об'єкти, що мають у своєму складі дані інтерфейс, є типізованими COM-об'єктами, тому що надають інформацію про використовувані типи (з бібліотеки типів);

· Елементи керування Actіve повинні мати бібліотеку типів, що міститься безпосередньо в DLL чи OCX файлі, що містить код ActіveX-сервера;

· Додатки, що є Automatіon-серверами, повинні мати бібліотеку типів, для більш зручно зв'язування з клієнтами;

· Використання бібліотеки типів у будь-якому випадку полегшує роботу з зовнішніми додатками, що можуть довідатися про використовувані типи даних, і таким чином виключається використання більш громіздкого методу передачі параметрів у системі через універсальний механізм.

3.9 Диспетчерський інтерфейс

Диспетчерський інтерфейс (dіspatch іnterface) - стандартна спеціальна реалізація інтерфейсу ІDіspatch, що пропонує COM. Дана реалізація забезпечує виконання процедур пізнього зв'язування (late bіndіng) і маршаллінга. Диспетчерський інтерфейс зберігає усередині себе таблицю диспетчерських ідентифікаторів (dіspі), кожний з який є унікальним ідентифікатором члена інтерфейсу, і таблиця, по суті, реалізує відображення відповідного dіspі на ім'я кожного члена інтерфейсу. Клієнт, що бажає одержати доступ до ресурсу сервера, повинний знати dіspі для відповідного ресурсу. Таку інформацію можна одержати через виклик методу інтерфейсу ІDіspatch, що називається GetіDsOfNames, і який є першим записом у vtable для інтерфейсу ІDіspatch. Таким чином, клієнт одержує інформацію про типи даних, використовуваних сервером, і одержує таблицю диспетчерських ідентифікаторів, з відображенням імені кожного ресурсу сервера на відповідний dіspі. Дана операція і з боку клієнта, і з боку сервера. При використанні стандартної реалізації інтерфейсу ІDіspatch це реалізується автоматично. Ця процедура називається пізнім зв'язуванням, тому що здійснюється на етапі виконання програми, а не на етапі компіляції. Маючи для кожного імені ресурсу сервера відповідний dіspі, клієнт може здійснити звертання до його, використовуючи метод інтерфейсу dіspі, що іменується Іnvoke. Метод Іnvoke має сигнатуру, що допускає виклик з будь-якою кількістю параметрів, чим забезпечується його універсальність. Реалізація Іnvoke розпаковує параметри і здійснює виклик відповідного чи методу властивості і здійснює контроль над видачею виключень при виконанні чи методу властивості. Коли виконання чи методу обробка властивості закінчується, значення, що повертаються чи властивості методу відправляються назад клієнту.

Основним недоліком диспетчерського інтерфейсу є обмеження на типи даних, які можна використовувати при передачі параметрів. Це випливає з необхідності упакування і розпакування параметрів при здійсненні маршаллінга. Допускається використовувати 13 стандартних типів даних. На користувальницькі типи даних установлюються досить строгі обмеження. Якщо вимоги задачі не укладаються в ці обмеження, розроблювач має можливість реалізувати маршаллінг, шляхом написання свого proxy/stub коду. Ще один недолік виявляється в тім, що при компіляції програми не виконується перевірка відповідності типів викликуваних функцій, тому що зв'язування диспетчерських інтерфейсів здійснюється на етапі виконання програми, і таким чином, не контролюється виклик Іnvoke з невірним набором аргументів, що викликає помилку виконання.

4. ТЕОРЕТИЧНЕ ДОСЛІДЖЕННЯ ОБ'ЄКТНОЇ МОДЕЛІ AUTOCAD

4.1 Загальний опис об'єктної моделі AutoCAD

Об'єктна модель AutoCAD є сукупністю об'єктів, властивостей, методів і подій. Для кожного з елементів цієї моделі є своя реалізація у вигляді даних і функцій, що забезпечують взаємодію з користувачем.

Об'єктна модель AutoCad є деревовидною структурою, на вершині якої знаходиться об'єкт Application - AutoCad. Об'єкти в AutoCAD розглядаються як ієрархія, що містить не тільки примітиви, але і інші елементи (таблиці, словники і т. д.). Однотипні об'єкти об'єднуються в сімейства (Collections). Кореневий об'єкт пов'язаний з сімействами Preferences, Documents, MenuBar, MenuGroups. Кожне з цих сімейств має безліч "нащадків".

Documents - колекція документів AutoCad (відкритих креслень). Отримати доступ до поточного (активного) документу можна по-різному. По-перше, AcadDocument має властивість Active, що інформує нас про те, чи активний даний документ чи ні. По-друге, можна прямо звернутися до активного документа через об'єкт ActiveDocument, або, що теж саме, через об'єкт ThisDrawing.

До складу кожного з документів входять колекції, що містять певний набір об'єктів. Наприклад, ModelSpace - колекція, яка містить всі об'єкти в просторі моделі. У даному додатку ми звертатимемося до об'єкту 3DSolyd - тривимірної твердотільної моделі.

Кожна колекція і кожен об'єкт володіє певними властивостями і методами, які дозволяють до нього звертатися. При роботі через об'єктну модель важливо правильно використовувати методи і знати, чи можна застосовувати їх до даного об'єкту в даній ситуації.



Рис. 4.1 Фрагмент об'єктної моделі AutoCAD

4.2 Методи побудови тривимірних примітивів

Команда BOX- призначена для побудови тривимірних твердотільних паралелепіпедів (ящиків).



Тіло будується шляхом вказівки наступних параметрів - координати геометричного центра паралелепіпеда, його довжини (по осі Х), ширини (по осі Y) і висоти (по осі Z).

Для створення паралелепіпеда в об'єктній моделі AutoCAD передбачений метод AddBox.

Синтаксис:

RetVal = object.AddBox(Origin, Length, Width, Height)

Object - ModelSpace Колекція, PaperSpace Колекція, Block - об'єкт або об'єкти що звертаються до цього методу.

Origin - тип Variant (масив з трьома елементами double); тільки для введення

Тривимірні координати положення WCS-початку координат поля. Ця координата представляє центр поля обмеження для об'єкту.

Length - тип Double; тільки для введення. Довжина поля. Повинне бути позитивне число.

Width - тип Double; тільки для введення. Ширина поля. Повинне бути позитивне число.

Height - тип Double; тільки для введення. Висота поля. Повинне бути позитивне число.



RetVal - 3DSolid об'єкт. Об'єкт 3DSolid як недавно створене поле.

Команда SPHERE- призначена для побудови тривимірної твердотільної кулі.

Тіло будується шляхом вказівки наступних параметрів - координати центру кулі і її радіусу.

Для створення кулі в об'єктній моделі AutoCAD передбачений метод AddSphere

Синтаксис :

RetVal = object.AddSphere(Center, Radius)

Object - ModelSpace Колекція, PaperSpace Колекція, Block. Об'єкт або об'єкти, що звертаються до цього методу.

Center - тип Variant (масив з трьома елементами double); тільки для введення. Тривимірні координати положення WCS центру сфери.

Radius - тип Double; тільки для введення. Радіус сфери. Повинне бути позитивне число.

RetVal - 3DSolid об'єкту. Об'єкт 3DSolid як недавно створена сфера.



Команда CYLINDER- призначена для побудови тривимірних твердотільних циліндрів, основа яких знаходиться на XY площині WCS.

Тіло будується шляхом вказівки наступних параметрів - координати центру основи циліндра, довжини радіусу основи (у площині XY), висоти (по осі Z).

Для створення тіла в об'єктній моделі AutoCAD передбачений метод AddCylinder

Синтаксис:

RetVal = object.AddCylinder(Center, Radius, Height)

Object - ModelSpace Колекція, PaperSpace Колекція, Block. Об'єкт або об'єкти що звертаються до цього методу.

Center - тип Variant (масив з трьома елементами double); тільки для введення. Тривимірні WCS координати положення центру грані.

Radius - тип Double; тільки для введення. Радіус циліндра. Повинне бути позитивне число.

Height - Double; тільки для введення. Висота циліндра. Повинне бути позитивне число.

RetVal - 3DSolid об'єкту. Об'єкт 3DSolid як недавно створений циліндр.



Команда CONE - призначена для побудови тривимірних твердотільних конусів, основа яких знаходиться на XY площині WCS.

Тіло будується шляхом вказівки наступних параметрів - координати центру основи конуса, довжини радіусу основи (у площині XY), висоти (по осі Z).

Для створення конуса в об'єктній моделі AutoCAD передбачений метод AddCone

Синтаксис

RetVal = object.AddCone(Center, BaseRadius, Height)

Object - ModelSpace Колекція, PaperSpace Колекція, Block. Об'єкт або об'єкти що звертаються до цього методу.

Center - тип Variant (масив з трьома елементами double); тільки для введення. Тривимірні координати положення WCS центру поля обмеження.

BaseRadius - тип Double; тільки для введення. Радіус конічної основи. Повинне бути позитивне число.

Height - тип Double; тільки для введення. Висота конуса. Повинне бути позитивне число.

RetVal - 3DSolid об'єкту. Об'єкт 3DSolid як недавно створений конус.



Команда WEDGE- створює клин з гранями, паралельними осям, за даними довжини, ширини і висоти.

Тіло будується шляхом вказівки наступних параметрів - координати центру грані клину, його довжини (по осі Х), ширини (по осі Y) і висоти (по осі Z).

Для створення клину в об'єктній моделі AutoCAD передбачений метод AddWedge.

Синтаксис:

RetVal = object.AddWedge(Center, Length, Width, Height)

Object - ModelSpace Колекція, PaperSpace Колекція, Block. Об'єкт або об'єкти, що звертаються до цього методу.

Center - тип Variant (масив з трьома елементами double); тільки для введення. Тривимірні координати положення WCS центру грані клину.

Length - тип Double; тільки для введення. Довжина клину по осі X. Повинне бути позитивне число.

Width - тип Double; тільки для введення. Ширина клину по осі Y. Повинне бути позитивне число.

Height - Double; тільки для введення. Висота клину по осі Z. Повинне бути позитивне число.

RetVal - 3DSolid об'єкту. Об'єкт 3DSolid як недавно створений клин.



Команда TORUS- призначена для побудови тривимірних твердотільних торів в заданому місцерозташуванні.

Тіло будується шляхом вказівки наступних параметрів - центру тора, відстані від центру тора до центру труби (радіусу тора), радіусу труби.

Для створення тіла в об'єктній моделі AutoCAD передбачений метод AddTorus

Синтаксис:

RetVal = object.AddTorus(Center, TorusRadius, TubeRadius)

Object - ModelSpace Колекція, PaperSpace Колекція, Block. Об'єкт або об'єкти, що звертаються до цього методу.

Center - тип Variant (масив з трьома елементами double); тільки для введення. Тривимірні WCS координати центру тора.

TorusRadius - тип Double; тільки для введення. Відстань від центру тора до центру труби. Повинне бути позитивне число.

TubeRadius - тип Double; тільки для введення. Радіус труби. Повинне бути позитивне число.

RetVal - 3DSolid об'єкту.Об'єкт 3DSolid як недавно створений тор.

4.3 Візуалізація тривимірних об'єктів

Швидкий спосіб установки виду (точки зору на об'єкт) полягає у виборі його з числа вже наявних стандартних 3D-видів. Існує декілька стандартних ортогональних і ізометричних видів, які можна вибирати по іменах. Ортогональні види відображають модель в проекціях зверху, знизу, спереду, зліва, справа і ззаду. Ізометричні види дозволяють розглядати наступні проекції: ПЗ (південно-західна), ПС (південно-східна), ПС (північно-східна) і ПЗ (північно-західна).

Для розуміння суті ізометричних видів можна уявити собі прямокутний ящик, що розглядається зверху. Якщо, наприклад, змістити точку зору до нижнього лівого кута ящика, вийде ізометричний південно-західний вигляд (ПЗ). Якщо ж змістити точку зору до переднього верхнього кута ящика, вийде ізометричний північно-східний вигляд (ПС).

Рис. 4.2 Представлення ізометричних видів

Для об'єктів поточного видового екрану можливо приховування виведення невидимих ліній і включення розфарбовування (тонування). Приховування невидимих ліній робить невидимими лінії, ребра і інші об'єкти, які насправді затулені об'єктами, розташованими на передньому плані. Розфарбовування, тобто заповнення певних об'єктів кольором, також робить невидимими лінії заднього плану. Розфарбовування кожного об'єкту проводиться поточним кольором. У режимі 3D-каркас об'єкти представляються у вигляді відрізків і кривих (як кромки граней і тіл).

3D-каркас Скриті Тонування

Рис. 4.3 Режими відображення 3D-об'єктів

Метод SendCommand посилає рядок команди від зовнішньої системи до документа AutoCAD для обробки.

Синтаксис:

object.SendCommand(Command)

Object - Document. Об'єкт або об'єкти що звертаються до цього методу.

Command - тип String; тільки для введення. Команда, щоб послати документу.

Приклад: а.activedocument.sendcommand('shademode у'+#13);

AutoCAD використовує стандартну палітру кольорів в діапазоні від 1 до 255. Властивість Color визначає колір об'єкту.

Синтаксис:

object.Color

object - All Drawing objects, Group, Layer. Об'єкт або об'єкти, що звертаються до цієї властивості.

Color - AcCmColor об'єкт - ціле число в діапазоні від 1 до 255

4.4 Редагування 3D-об'єктів

Rotate3D - обертає об'єкт навколо 3D-осі. Point1 і Point2 визначають лінію, яка стає віссю повороту.

Синтаксис:

object.Rotate3D Point1, Point2, RotationAngle

Object - всі Об'єкти рисунка, AttributeReference. Об'єкт або об'єкти що звертаються до цього методу.

Point1 - тип Variant (масив з трьома елементами double); тільки для введення. 3D координата положення WCS, перша точка лінії осі.

Point2 - тип Variant (масив з трьома елементами double); тільки для введення. 3D координата положення WCS, друга точка лінії осі.

Рис. 4.4 Результат роботи команди Rotate3D

Mirror3D - створює дзеркальне відображення даного об'єкту щодо площини.

Синтаксис:

RetVal = object.Mirror3D(Point1, Point2, Point3)

Object - All Drawing Objects. Всі об'єкти малюнка. Об'єкт або об'єкти, які звертаються до цього методу.

Point1 - тип Variant (масив з трьома елементами double); тільки для введення. Тривимірні координати положення WCS першої точки дзеркальної площини.

Point2 - тип Variant (масив з трьома елементами double); тільки для введення. Тривимірні координати положення WCS другої точки дзеркальної площини.

Point3 - тип Variant (масив з трьома елементами double); тільки для введення. Тривимірні координати положення WCS третьої точки дзеркальної площини.

RetVal - Відображений об'єкт. Цей об'єкт може бути одним з Drawing Objects.