Здравствуйте, всем доброго дня.

Я хочу модернизировать интерфейс одной своей разработки. Суть следующая: на рабочей области нужно размещать примитивы — многоугольники, эллипсы, параболики — и мне хотелось бы делать это именно так, как это реализовано в AutoCAD'е. То есть, чтобы все примитивы можно было бы легко редактировать мышкой, прибегая к помощи диалогов только в крайнем случае. Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения. С какой стороны подступиться — написать какие-то компоненты (какие и как?), которые бы помещались в контейнер, служащий рабочей областью или просто на ООП реализовать классы с кучей методов?

Здравствуйте, Михаил Дюмин, Вы писали:

МД>Я хочу модернизировать интерфейс одной своей разработки. Суть следующая: на рабочей области нужно размещать примитивы — многоугольники, эллипсы, параболики — и мне хотелось бы делать это именно так, как это реализовано в AutoCAD'е. То есть, чтобы все примитивы можно было бы легко редактировать мышкой, прибегая к помощи диалогов только в крайнем случае. Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения. С какой стороны подступиться — написать какие-то компоненты (какие и как?), которые бы помещались в контейнер, служащий рабочей областью или просто на ООП реализовать классы с кучей методов?

В последних версиях AutoCAD'а (Начиная с 2000) встроен VBA, и открыта архитектура(Описания классов и методов в хелпе имеются) и подробно изучив ее можно получить представление о том, как это реализуется. У меня где-то до сих пор иерархия классов в dwg формате лежит.

У меня есть простенький векторный редактор (взят из книги "Программирование графики в Windows"). Он позволяет рисовать простенькие примитивы (линии, окружности, элликсы, полилинии, полигоны...), масштабировать их и перемещать. также позволяет выставлять свойства линий. Там есть пара ошибок, но для изучения это не существенно. Написан на VC++6 и чистом API. Если интересно — могу скинуть на майл.

Здравствуйте, Михаил Дюмин, Вы писали:

МД>Здравствуйте, всем доброго дня.

МД>Я хочу модернизировать интерфейс одной своей разработки.
Ага..

МД>Суть следующая: на рабочей области нужно размещать примитивы — многоугольники, эллипсы, параболики — и мне хотелось бы делать это именно так, как это реализовано в AutoCAD'е. То есть, чтобы все примитивы можно было бы легко редактировать мышкой, прибегая к помощи диалогов только в крайнем случае.
Круто.

МД>Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения.
Ничего не устоялось. И при чем тут "задача векторной графики"?

МД>С какой стороны подступиться — написать какие-то компоненты (какие и как?), которые бы помещались в контейнер, служащий рабочей областью или просто на ООП реализовать классы с кучей методов?
А как же. Написать компоненты. Потом в контейнер. Ну и уж никуда не деться от классов с кучей методов.

А если серьезно, то можно свободно пользовать подход студии.
Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе. Кроме того нужны дизайнеры : классы, которые будут отображать на рабочем поле "фишечки", добавлять контролы-"прямоугольнички", контролы-"стрелочки" и т.д., модифицируя внутреннее представление классов примитивов. По правой клавише — GetDesignVerbs и т.д.

Здравствуйте, Михаил Дюмин, Вы писали:

МД>Пока ждал хоть какого-нибудь ответа, пришёл к выводу, что всё можно сделать без каких-либо контролов. Всё вполне укладывается стандартное ООП без APIшных наворотов.

P>>А если серьезно, то можно свободно пользовать подход студии.
P>>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе.

МД>Хмм... А смысл? Ведь в моём случае, если я правильно понимаю, экземпляров контролов будет столько же, столько и экземпляров примитивов, и наличие у контрола нескольких дополнительных полей ничего не изменит. Какой смысл выделять поля, отвечающие за сам примитив, в отдельный класс?

P>>Кроме того нужны дизайнеры : классы, которые будут отображать на рабочем поле "фишечки", добавлять контролы-"прямоугольнички", контролы-"стрелочки" и т.д., модифицируя внутреннее представление классов примитивов. По правой клавише — GetDesignVerbs и т.д.

МД>Интересная идея. Надо будет надо всем этим подумать.
МД>А вообще, придётся поизучать идеологию конторолов. Создавать их мне ни разу не приходилось.

В ACAD-е есть графические (entity) и не графические объекты (просто object). Для графических объектов ACAD сам вызывает функции отрисовки в конкретном контексте рисования. Так что как надо рисоваться знает только сам объект. За сериализацию объектов отвечают тоже сами же объекты. И скажите еще, что у ACAD-а плохой дизайн приложения.

Вообще-то можно и разделять объекты данных и объекты отображения. Смотря, какие задачи стоят. А делать это ради того чтобы сделать – “суета одна и томление духа”.

Здравствуйте, Poudy, Вы писали:

P>А если серьезно, то можно свободно пользовать подход студии.
P>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе. Кроме того нужны дизайнеры : классы, которые будут отображать на рабочем поле "фишечки", добавлять контролы-"прямоугольнички", контролы-"стрелочки" и т.д., модифицируя внутреннее представление классов примитивов. По правой клавише — GetDesignVerbs и т.д.

Не надо делать классы примитивов.

Класс, который реализует редактирование примитива ("дизайнеры") еще куда ни шло, но
класс для самого примитива — не стоит. Достаточно контейнера.

Здесь уже начинает работать правило больших объемов — накладные расходы на создание-удаление
объекта класса будут очень велики.

Павел

Здравствуйте, Михаил Дюмин, Вы писали:

Можно микрософтовскйи примерdrawcli за основу взять и под себя заточить.

Можно поиском по сайту найти Rogue Wave Stingray Studio и разобратся с ихней Objective Views.

Здравствуйте, Poudy, Вы писали:

P>Здравствуйте, bizhan, Вы писали:

B>>Пример расчетов. Таких, что их надо реализовывать на уровен одного примитива.
B>>Легко расширение библиотеки примитивов — это хороший вопрос. Я не знаю универсального решения.
B>>Хорошие — известны, но часто зависят от конкретной предметной области.
P>Примитив — просто универсальный доступ к объекту. Базовый класс. То, у чего есть отдельный дизайнер.
P>Соотв. поверхности, пересечения, геометрические преобразования, типа размножения с поворотом, вытягивания — примитивы.

Мне кажется, что у тебя каша из терминологии.
Примитив — это что?
Класс — это что?
Дизайнер — это что?
Почему преобразование (глагол) у тебя примитив (существительное)?

P>Может быть. На мой взгляд — это проблема аглоритма. Если заранее поделить область редактирования на клетки (кубы),
P>т.е. самый большой контейнер реализовать как группу контейнеров поменьше, то необязательно обходить все объекты.

Здесь ответ будет такой — сходи и наступи на эти грабли

P>Опять же — как реализовать. Инкапсуляция и все такое. Можно выделять память в пуле, отрисовывать много объектов сразу. Одно другому не мешает
P>и не делает объекты примитивов лишними.

Сходи и наступи. Сделай простой тест и посмотри в профайлере на что уходит время.

Павел

p.s я не настаиваю

Здравствуйте, bizhan, Вы писали:

B>Почему преобразование (глагол) у тебя примитив (существительное)?

Да нет, вообще-то "преобразование" — это не глагол.

P>>Может быть. На мой взгляд — это проблема аглоритма. Если заранее поделить область редактирования на клетки (кубы),
P>>т.е. самый большой контейнер реализовать как группу контейнеров поменьше, то необязательно обходить все объекты.

B>Здесь ответ будет такой — сходи и наступи на эти грабли
Я не понимаю, к чему ты придираешься. Я такое два раза писал.

Где вы, Exhumer?

Здравствуйте, Poudy, Вы писали:

МД>>Суть следующая: на рабочей области нужно размещать примитивы, как в AutoCAD'е.
P>Круто.
Ещё бы.

МД>>Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения.
P>И при чем тут "задача векторной графики"?
Видимо при том, что AutoCAD по сути — граф.редактор, пусть и специализированный. А подобный интерфейс — вещь для векторной графики, вроде бы, стандартная...
Ну да ладно, не в этом суть.

Пока ждал хоть какого-нибудь ответа, пришёл к выводу, что всё можно сделать без каких-либо контролов. Всё вполне укладывается стандартное ООП без APIшных наворотов.

P>А если серьезно, то можно свободно пользовать подход студии.
P>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе.

Хмм... А смысл? Ведь в моём случае, если я правильно понимаю, экземпляров контролов будет столько же, столько и экземпляров примитивов, и наличие у контрола нескольких дополнительных полей ничего не изменит. Какой смысл выделять поля, отвечающие за сам примитив, в отдельный класс?

P>Кроме того нужны дизайнеры : классы, которые будут отображать на рабочем поле "фишечки", добавлять контролы-"прямоугольнички", контролы-"стрелочки" и т.д., модифицируя внутреннее представление классов примитивов. По правой клавише — GetDesignVerbs и т.д.

Интересная идея. Надо будет надо всем этим подумать.
А вообще, придётся поизучать идеологию конторолов. Создавать их мне ни разу не приходилось.

Спасибо за ответ.

Здравствуйте, Михаил Дюмин, Вы писали:


МД>Пока ждал хоть какого-нибудь ответа, пришёл к выводу, что всё можно сделать без каких-либо контролов. Всё вполне укладывается стандартное ООП без APIшных наворотов.
При желании почти все можно уложить в ООП без наворотов. Это не самоцель.

P>>А если серьезно, то можно свободно пользовать подход студии.
P>>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе.

МД>Хмм... А смысл? Ведь в моём случае, если я правильно понимаю, экземпляров контролов будет столько же, столько и экземпляров примитивов, и наличие у контрола нескольких дополнительных полей ничего не изменит. Какой смысл выделять поля, отвечающие за сам примитив, в отдельный класс?

Никаких дополнительных полей у контрола быть не должно. Поля, отвечающие за примитив, тоже не надо. Дело в другом — в режиме дизайна ты работаешь с контролом или чем-то, изображающем из себя контрол (чтоб быстрее работало и.. дуги, сам понимаешь...). Рамки выделения и другие элементы управления — почти точно контролы.
Но в конце концов тебе придется перевести это в другое представление — линии, круги и пр. Помимо прочего, нашпиговывать контрол геометрическими расчетами совсем неправильно.

Один контрол изображает внешний вид, другие позволяют редактировать свойства. Дизайнер знает обо всех них, принимает сообщения, обрабатывает клавиши, а также:
• перекачивает данные из контролов в классы примитивов, чтобы при последующем вызове у экземпляра класса примитива метода
вроде CalculateBodyAngle или свойства NormalLine, все обсчитывалось правильно.
• предоставляет дизайнеру сцены (или там... чертежа).. получать данные о snappoint's.
• Сам, или созданные им тулзы, кладут транзакции (команды) о выполняемых операциях в стек отмены текущего дизайнера сцены
(или специального DesignService).

Здравствуйте, Nata1111, Вы писали:

N>В последних версиях AutoCAD'а (Начиная с 2000) встроен VBA, и открыта архитектура(Описания классов и методов в хелпе имеются) и подробно изучив ее можно получить представление о том, как это реализуется. У меня где-то до сих пор иерархия классов в dwg формате лежит.
То есть, надо полагать, что и в Mechanical Desktop 6 это тоже есть. Гляну...

N>У меня есть простенький векторный редактор (взят из книги "Программирование графики в Windows"). Он позволяет рисовать простенькие примитивы (линии, окружности, элликсы, полилинии, полигоны...), масштабировать их и перемещать. также позволяет выставлять свойства линий. Там есть пара ошибок, но для изучения это не существенно. Написан на VC++6 и чистом API. Если интересно — могу скинуть на майл.

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

(Собственно, прога написана два года назад на VC++ 6.0. Работает вполне нормально и впечатление производит. Но интерфейс никуда не годится и исходник там местами страшный настолько, что умным людям его показывать опасно для собсвенной репутации. Вот и взялся переписать кое-что от нехрен делать)

Здравствуйте, bizhan, Вы писали:

B>Не надо делать классы примитивов.

B>Класс, который реализует редактирование примитива ("дизайнеры") еще куда ни шло, но
B>класс для самого примитива — не стоит. Достаточно контейнера.

А куда тогда запихнуть геометрические расчеты? И как иначе сделать легким расширение библиотеки примитивов?
Я почти уверен, что поверхность не стоит хранить как множество отрезков, только в таком контексте поверхность — тоже
примитив. А не примитивы — только составные объекты.

B>Здесь уже начинает работать правило больших объемов — накладные расходы на создание-удаление
B>объекта класса будут очень велики.

• 100 000 никого не запарят;
• совсем необязательно инстанциировать все объекты;
• сериализовывать можно и в контейнеры;


B>Павел

Здравствуйте, bizhan, Вы писали:

P>>А если серьезно, то можно свободно пользовать подход студии.
P>>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе. Кроме того нужны дизайнеры : классы, которые будут отображать на рабочем поле "фишечки", добавлять контролы-"прямоугольнички", контролы-"стрелочки" и т.д., модифицируя внутреннее представление классов примитивов. По правой клавише — GetDesignVerbs и т.д.

B>Не надо делать классы примитивов.

B>Класс, который реализует редактирование примитива ("дизайнеры") еще куда ни шло, но
B>класс для самого примитива — не стоит. Достаточно контейнера.

B>Здесь уже начинает работать правило больших объемов — накладные расходы на создание-удаление
B>объекта класса будут очень велики.

А вот скажи, пожалуйста, ты САМ (в команде) что-то разрабатывал достаточно большое? Или просто умных книжек почитал?

Я тут выше писал, как это сделано в ACAD-е. Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем. Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов. Также можно реализовать расширения протоколов (ACAD-овских) для каждого из классов.

Кроме того, при достаточно сильной связи между объектами (составные объекты, ownership, etc) будет достаточно сложно реализовать управление объектами в принципе. Ведь по классической схеме объект данных (контейнер) ничего не знает о своем accessor-е. Поэтому все управление должно быть централизованно.

Так что предлагаю посмотреть, для начала, как это сделано у людей.

Здравствуйте, Poudy, Вы писали:

P>Здравствуйте, bizhan, Вы писали:


P>А куда тогда запихнуть геометрические расчеты? И как иначе сделать легким расширение библиотеки примитивов?

Пример расчетов. Таких, что их надо реализовывать на уровен одного примитива.
Легко расширение библиотеки примитивов — это хороший вопрос. Я не знаю универсального решения.
Хорошие — известны, но часто зависят от конкретной предметной области.

P>Я почти уверен, что поверхность не стоит хранить как множество отрезков, только в таком контексте поверхность — тоже
P>примитив. А не примитивы — только составные объекты.

Я про другое. Я про то, что класс для каждого типа примитива — это не самое удачное решение.
Например,

class Line {}
class Rectangle {}
class PolyLine {}
class Ellipse {}
class Surface {}

+ к ним контейнеры

Line Lines[];
...

и так далее.

B>>Здесь уже начинает работать правило больших объемов — накладные расходы на создание-удаление
B>>объекта класса будут очень велики.

P>• 100 000 никого не запарят;
P>• совсем необязательно инстанциировать все объекты;
P>• сериализовывать можно и в контейнеры;

О том и речь.
То, что тебя не запарят 100 000 объектов — это вопрос.
Вот алгоритм (условно) для отрисовки только тех, кого надо.
Есть rectangle окна.

foreach(Line *pLine in Lines){
 if(pLine->Intersect(rectangle)) {
   pLine->Draw();
}
}

Я про то, что этот вариант — не самый удачный.

Причины, например такие:
1. индексы
2. свопинг
3. если хранение в БД, то инициализировать объекты придется

Мой поинт таков — правило больших объемов.
Основная работа, это:
1. отрисовать _много_ примитивов (а не один)
2. редактировать один или несколько.

То есть, упор именно на работу с многими объектами.

Павел

Здравствуйте, Exhumer, Вы писали:


E>А вот скажи, пожалуйста, ты САМ (в команде) что-то разрабатывал достаточно большое? Или просто умных книжек почитал?

Да, разрабатывал. Система для кабельных сетей. Подстанции, кабели и так далее.
Система разработана и успешно внедрена например на Шереметьево и в 7 районе Московской кабельной сети. И еще десятке организаций Москововской области.

И книжки умные я тоже почитал.

E>Я тут выше писал, как это сделано в ACAD-е. Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем. Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов. Также можно реализовать расширения протоколов (ACAD-овских) для каждого из классов.

А как это противоречит тому, что написал я?-)

Унификация, раз уж ты заговорил об этом, это нормальное решение. Лучше, чем класс на
каждый тип примитива. А для основных операций подобную унификацию провести можно.

А вот уже редактирование — это конкретика. Общее в редактировании тоже есть, это само собой,
но конкретики больше. Сравни — редактирование полигона и редактирование эллипса.

E>Кроме того, при достаточно сильной связи между объектами (составные объекты, ownership, etc) будет достаточно сложно реализовать управление объектами в принципе. Ведь по классической схеме объект данных (контейнер) ничего не знает о своем accessor-е. Поэтому все управление должно быть централизованно.

Это правда. Ты сам пишешь, что объектом данных выступает не объект типа примитива (конкретного),
а весь контейнер. А вся работа с ним — внешняя. Я об этом и говорю.

Павел

p.s а сам-то что-нить сделал или книжек почитал?-))

Здравствуйте, Nata1111, Вы писали:

N>Здравствуйте, Михаил Дюмин, Вы писали:

МД>>Я хочу модернизировать интерфейс одной своей разработки. Суть следующая: на рабочей области нужно размещать примитивы — многоугольники, эллипсы, параболики — и мне хотелось бы делать это именно так, как это реализовано в AutoCAD'е. То есть, чтобы все примитивы можно было бы легко редактировать мышкой, прибегая к помощи диалогов только в крайнем случае. Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения. С какой стороны подступиться — написать какие-то компоненты (какие и как?), которые бы помещались в контейнер, служащий рабочей областью или просто на ООП реализовать классы с кучей методов?

N>В последних версиях AutoCAD'а (Начиная с 2000) встроен VBA, и открыта архитектура(Описания классов и методов в хелпе имеются) и подробно изучив ее можно получить представление о том, как это реализуется. У меня где-то до сих пор иерархия классов в dwg формате лежит.

N>У меня есть простенький векторный редактор (взят из книги "Программирование графики в Windows"). Он позволяет рисовать простенькие примитивы (линии, окружности, элликсы, полилинии, полигоны...), масштабировать их и перемещать. также позволяет выставлять свойства линий. Там есть пара ошибок, но для изучения это не существенно. Написан на VC++6 и чистом API. Если интересно — могу скинуть на майл.

И мне, и мне ... vva@udm.ru

Здравствуйте, bizhan, Вы писали:

E>>А вот скажи, пожалуйста, ты САМ (в команде) что-то разрабатывал достаточно большое? Или просто умных книжек почитал?

B>Да, разрабатывал. Система для кабельных сетей. Подстанции, кабели и так далее.
B>Система разработана и успешно внедрена например на Шереметьево и в 7 районе Московской кабельной сети. И еще десятке организаций Москововской области.

А вы под конкретный заказ писали или так вообще? Просто интересно.

B>И книжки умные я тоже почитал.

Извини, что вышло как наезд. Вообще-то, неправильно получилось. Я должен был описать это Poudy. То ли Opera глюкнула, то ли я :)

E>>Я тут выше писал, как это сделано в ACAD-е. Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем. Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов. Также можно реализовать расширения протоколов (ACAD-овских) для каждого из классов.

B>А как это противоречит тому, что написал я?-)

Никак!

B>Унификация, раз уж ты заговорил об этом, это нормальное решение. Лучше, чем класс на
B>каждый тип примитива. А для основных операций подобную унификацию провести можно.

B>А вот уже редактирование — это конкретика. Общее в редактировании тоже есть, это само собой,
B>но конкретики больше. Сравни — редактирование полигона и редактирование эллипса.

Ну да. Тут уж каждый (примитив) сам все про себя знает.

E>>Кроме того, при достаточно сильной связи между объектами (составные объекты, ownership, etc) будет достаточно сложно реализовать управление объектами в принципе. Ведь по классической схеме объект данных (контейнер) ничего не знает о своем accessor-е. Поэтому все управление должно быть централизованно.

B>Это правда. Ты сам пишешь, что объектом данных выступает не объект типа примитива (конкретного),
B>а весь контейнер. А вся работа с ним — внешняя. Я об этом и говорю.

Консенсус.

B>p.s а сам-то что-нить сделал или книжек почитал?-))

RCAD Steel — гражданское строительство. Проект развивается уже три года. Ну и книжки само собой :).

Здравствуйте, Exhumer, Вы писали:

E>А вот скажи, пожалуйста, ты САМ (в команде) что-то разрабатывал достаточно большое? Или просто умных книжек почитал?
Сейчас разрабатываю ERP, а в составе нее дизайнер форм.

E>Я тут выше писал, как это сделано в ACAD-е. Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем. Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов. Также можно реализовать расширения протоколов (ACAD-овских) для каждого из классов.

Довольно нетривиально понять, что ты тут написал.

E>Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем.
Это чем-то отличается от базового класса?

E>Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов.
"Стандартных классов" не примитивов? А чего тогда?

E>Также можно реализовать расширения протоколов (ACAD-овских) для каждого из классов.
Под протоколом понимается динамический вызов, какое-то сообщение или те же виртуальные методы?



E>Кроме того, при достаточно сильной связи между объектами (составные объекты, ownership, etc) будет достаточно сложно реализовать управление объектами в принципе.
Согласен.

E>Ведь по классической схеме объект данных (контейнер) ничего не знает о своем accessor-е. Поэтому все управление должно быть централизованно.
Ну да, в дизайнере оно и будет централизовано. Только зачем в дизайнер запихивать метод нахождения касательной? А если нет класса примитива, то куда это поместить?

E>Так что предлагаю посмотреть, для начала, как это сделано у людей.
Не имею ничего против.

Здравствуйте, bizhan, Вы писали:

B>Пример расчетов. Таких, что их надо реализовывать на уровен одного примитива.
B>Легко расширение библиотеки примитивов — это хороший вопрос. Я не знаю универсального решения.
B>Хорошие — известны, но часто зависят от конкретной предметной области.
Примитив — просто универсальный доступ к объекту. Базовый класс. То, у чего есть отдельный дизайнер.
Соотв. поверхности, пересечения, геометрические преобразования, типа размножения с поворотом, вытягивания — примитивы.


B>Я про другое. Я про то, что класс для каждого типа примитива — это не самое удачное решение.
B>Например,

B>О том и речь.
B>То, что тебя не запарят 100 000 объектов — это вопрос.
B>Вот алгоритм (условно) для отрисовки только тех, кого надо.
B>Есть rectangle окна.

B>

B>foreach(Line *pLine in Lines){
B> if(pLine->Intersect(rectangle)) {
B>   pLine->Draw();
B>}
B>}

B>

B>Я про то, что этот вариант — не самый удачный.

Может быть. На мой взгляд — это проблема аглоритма. Если заранее поделить область редактирования на клетки (кубы),
т.е. самый большой контейнер реализовать как группу контейнеров поменьше, то необязательно обходить все объекты.

B>Причины, например такие:
B>1. индексы
B>2. свопинг
B>3. если хранение в БД, то инициализировать объекты придется

B>Мой поинт таков — правило больших объемов.
B>Основная работа, это:
B>1. отрисовать _много_ примитивов (а не один)
B>2. редактировать один или несколько.

Опять же — как реализовать. Инкапсуляция и все такое. Можно выделять память в пуле, отрисовывать много объектов сразу. Одно другому не мешает
и не делает объекты примитивов лишними.

B>Павел
Очень приятно.

Здравствуйте, Юнусов Булат, Вы писали:

ЮБ>Здравствуйте, Михаил Дюмин, Вы писали:

ЮБ>Можно микрософтовскйи примерdrawcli за основу взять и под себя заточить.

ЮБ>Можно поиском по сайту найти Rogue Wave Stingray Studio и разобратся с ихней Objective Views.

А Вы случаем не пробовали для каких-нибудь разработок (САПР или что-то того) Objective Views?
Если кто пробовал, поделитесь опытом, какие там минусы и плюсы?
Что там можно использовать, а что не стоит?
Ну короче, есть мнения какие-нибудь об вышеупомянутой приблуде?

Здравствуйте, Exhumer, Вы писали:

E>А вы под конкретный заказ писали или так вообще? Просто интересно.

Скорее вообще. Но был главный заказчик, который определял общее направление.
Как сейчас — не знаю, я там не работаю.

E>Ну да. Тут уж каждый (примитив) сам все про себя знает.

При редатировании да. Только скорее не примитив, а нечто, что этот примитив редактирует.

B>>p.s а сам-то что-нить сделал или книжек почитал?-))

E>RCAD Steel — гражданское строительство. Проект развивается уже три года. Ну и книжки само собой .

У вас ээ расширение RCAD или это полнотсью ваш продукт? Я по инету посмотрел и не понял.

Павел

p.s а до 3D я так и не дошел.

Здравствуйте, bizhan, Вы писали:

E>>RCAD Steel — гражданское строительство. Проект развивается уже три года. Ну и книжки само собой :).

B>У вас ээ расширение RCAD или это полнотсью ваш продукт? Я по инету посмотрел и не понял.

Расширение ACAD-а. http://www.rcad.robobat.com/Rcad/St044/Main/index.asp?PDetectJS=1
Но там как-то плохо все расписано.

B>p.s а до 3D я так и не дошел.

Ну и хорошо. Потому, что мало кто (из преметной области) понимает что и как надо в этом 3D делать.

Здравствуйте, Poudy, Вы писали:

E>>А вот скажи, пожалуйста, ты САМ (в команде) что-то разрабатывал достаточно большое? Или просто умных книжек почитал?
P>Сейчас разрабатываю ERP, а в составе нее дизайнер форм.

А что такое ERP? Так ты бизнес логику пишешь или диалоги ваяешь?

E>>Я тут выше писал, как это сделано в ACAD-е. Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем. Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов. Также можно реализовать расширения протоколов (ACAD-овских) для каждого из классов.

P>Довольно нетривиально понять, что ты тут написал.

?

E>>Все графические объекты имеют единообразный алгоритм взаимодействия с пользователем.
P>Это чем-то отличается от базового класса?

Ничем.

E>>Поэтому все стандартные команды могут работать с custom объектами, т.е. расширениями стандартных классов.
P>"Стандартных классов" не примитивов? А чего тогда?

Вроде же писал — "Все в одном". Подробнее — см. ниже.

E>>Также можно реализовать расширения протоколов (ACAD-овских) для каждого из классов.
P>Под протоколом понимается динамический вызов, какое-то сообщение или те же виртуальные методы?

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

E>>Ведь по классической схеме объект данных (контейнер) ничего не знает о своем accessor-е. Поэтому все управление должно быть централизованно.
P>Ну да, в дизайнере оно и будет централизовано. Только зачем в дизайнер запихивать метод нахождения касательной? А если нет класса примитива, то
куда это поместить?

Централизованное управление я приводил как недостаток. Объект сам знает "что и куда и зачем" и как он взимодействет с другими объектами. А собственно "манагер" командует — отрисоватся, сохранится, скопироватся, найти точки пересечения с другими объектамиб etc.

Возможно, что без описания, как все система работает в целом, не обойтись. Так, что я могу описать как это работает в ACAD-е, а ты опиши свою задумку. Вот и посмотрим :)

Здравствуйте, Exhumer, Вы писали:

E>А что такое ERP? Так ты бизнес логику пишешь или диалоги ваяешь?
Enterprise Resource Planning
Бизнес маленький — приходится заниматься всем по очереди. А для диалогов говорю же — дизайнер я пишу сейчас.


E>Централизованное управление я приводил как недостаток. Объект сам знает "что и куда и зачем" и как он взимодействет с другими объектами. А собственно "манагер" командует — отрисоватся, сохранится, скопироватся, найти точки пересечения с другими объектамиб etc.

E>Возможно, что без описания, как все система работает в целом, не обойтись. Так, что я могу описать как это работает в ACAD-е, а ты опиши свою задумку. Вот и посмотрим

Хорошее предложение.

P>Здравствуйте, Exhumer, Вы писали:


E>>Так, что я могу описать как это работает в ACAD-е ...

Ну так давай описывай.. Или времени нет?

Здравствуйте, Poudy, Вы писали:

E>>>Так, что я могу описать как это работает в ACAD-е ...

P>Ну так давай описывай.. :) Или времени нет?

Давай определим уровень абстакции на котором будем все описывать. А иначе мне проще выслать ObjectARX Developer's Guide, а оно тебе надо?

Здравствуйте, Exhumer, Вы писали:

E>Давай определим уровень абстакции на котором будем все описывать. А иначе мне проще выслать ObjectARX Developer's Guide, а оно тебе надо?

Ну вот и определились.

Здравствуйте, Михаил Дюмин, Вы писали:

МД>Здравствуйте, всем доброго дня.

МД>Я хочу модернизировать интерфейс одной своей разработки. Суть следующая: на рабочей области нужно размещать примитивы — многоугольники, эллипсы, параболики — и мне хотелось бы делать это именно так, как это реализовано в AutoCAD'е. То есть, чтобы все примитивы можно было бы легко редактировать мышкой, прибегая к помощи диалогов только в крайнем случае. Очевидно, что это стандартная задача из вектороной графики и наверняка существует вполне устоявшийся способ её решения. С какой стороны подступиться — написать какие-то компоненты (какие и как?), которые бы помещались в контейнер, служащий рабочей областью или просто на ООП реализовать классы с кучей методов?

А ты скачай с сайта Autodesk ADS (интерфейс для С++ программирования под ACAD). И по образу и подобию и действуй.

Здравствуйте, Poudy, Вы писали:

E>>Давай определим уровень абстакции на котором будем все описывать. А иначе мне проще выслать ObjectARX Developer's Guide, а оно тебе надо?

P>Ну вот и определились.

С чем? Я полагаю, поправь меня если не прав, что тебе проще описать то, что ты придумал, чем мне описать, то, что сделали другие люди. Ты вообще представляешь СКОЛЬКО времени надо чтобы описать работу ACAD-а достаточно подробно? Если я этим и займусь, то только когда буду издавать очередную книгу из серии "Программирование под ACAD для чайников за 2 дня".

Так что, начинаешь?

Здравствуйте, Exhumer, Вы писали:

E>Так что, начинаешь?
Ладно. Завтра начну.

Здравствуйте, Poudy, Вы писали:

Ну так вот, наконец-то дошли руки.

Как мне кажется, вот как надо действовать:

• Нужно создать контейнер, логически представляющий собой крупную клетку рабочей области. Допустим, квадрат 10x10. Он возвращает коллекцию элементов по координате или прямоугольнику. Т.е. просто проходится по всем своим элементам и выполняет проверку.
• Через специальный сервис извещать клетки о перемещениях и изменении размеров их элементов.
• Создать "клетку клеток", которая ... ну все понятно. Это тоже не массив, а коллекция.
• Использовать самую большую клетку в рабочем поле.

• Написать классы геометрических примитивов. Не важно, где будут храниться данные. Т.е. можно хранить все координаты и параметры в теле объекта, а можно оформить их в виде свойств, достающих данные из общего пула по индексу, или еще как угодно. Тут главное — собрать вместе методы геом. преобразований и сделать обращение с ними максимально удобным.
[В ходе обсуждения вссерх по ветке было сделано замечание, что нужные методы редко работают с отдельными объектами. На это я могу ответить тем, о чем уже говорил. Делать сложные геометрические преобразование примитивами. Ну то есть : поворот нескольких объектов — это создание примитива "поворот", аргументом которого был примитив "группа". Такая мешанина из понятий полезна вот чем: позволяет создавать для преобразований такие же дизайнеры, рисующие adornments, и добавляющие средства управления (вроде стрелок поворота). Позволяет отображать преобразования в дереве навигации по объектам, как это сделано в параметрических CAD'ах. Позволяет организовать на этой базе отмену/возврат, как создание и удаление примитивов.]

• Написать для примитивов дизайнеры. Как и в студии, дизайнер делает сделующие вещи:
+ предоставляет список редактируемых свойств объекта;
+ дорисовывает всякие штучки;
+ обрабатывает нажания клавиш;
+ составляет контекстное меню;
+ добавляет элементы управления, вроде рамки выделения с grip'ами для изменения размеров;
+ обрабатывает сообщения мышки, организует выделение внутри примитива;

большую часть этих функций можно оформить в виде reusable тулзов, которые дизайнер создает и которым затем предоставляет данные. Ну, вроде SelectionFrame, KeyTool и пр.

Рассмотрим, к примеру, выделение нескольких объектов. Сначала при помощи дизайнера рабочей области создается и растягивается контрол, изображающий из себя рамку выделения. После отжатия клопки мыши находятся все элементы, которые отправляются в SelectionService. В зависимости от нажатых кнопок (Shift, Ctrl), SelectionService решает как объединять новые элементы с ранее выделенными. После этого SelectionService создает/модифицирует объект "группа элементов", который или помечен как design или лежит отдельно или еще как больше нравится. Под этот примитив создается дизайнер, который прямо или косвено рисует рамки, дорисовывает фигню, пополняет статус бар и добавляет в context menu пункты "группировать", "выровнять" и т.д. Если кому-то кажется, что создается слишком много объектов, приведу в пример new MouseEventArgs.

Вот таким путем.

Здравствуйте, Poudy, Вы писали:

P>Нужно создать контейнер, логически представляющий собой крупную клетку рабочей области. Допустим, квадрат 10x10. Он возвращает P>коллекцию элементов по координате или прямоугольнику. Т.е. просто проходится по всем своим элементам и выполняет проверку.

Тут вы уже похоже путаете структуру непосредственно редакторов с системой отображения и хранения (т.е. всё вместе — быстрый поиск для отображения и выделения примитива под мышкой)..
Опять же подобные вещи известны.. (например R-деревья, ещё кое-что)
Такие виды индексов (получить всё что в прямоугольнике) и объектов присутствуют например
в Oracle, DB2, PostgreSQL, mySQL (начиная с 4.1 альфа)
искать по ключевым словам "Open GIS"
Так что их ИМХО лучше наверно вообще готовые взять..

P>• Написать классы геометрических примитивов.
P>• Написать для примитивов дизайнеры.

Писал я когда то такие вещи, получалось неплохо..
http://217.106.53.149/~vva/docs/cx.zip
Сейчас как "хобби" пытаюсь это на новом уровне сделать, чтобы исходники открыть..
если интересно, пишите на vva@udm.ru