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

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

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

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

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

Здравствуйте, 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

Где вы, Exhumer?