МД>Пока ждал хоть какого-нибудь ответа, пришёл к выводу, что всё можно сделать без каких-либо контролов. Всё вполне укладывается стандартное ООП без APIшных наворотов.
При желании почти все можно уложить в ООП без наворотов. Это не самоцель.
P>>А если серьезно, то можно свободно пользовать подход студии. P>>Классы примитивов — отдельно. Контролы, их отрисовывающие (или одно рабочее поле) — сами по себе.
МД>Хмм... А смысл? Ведь в моём случае, если я правильно понимаю, экземпляров контролов будет столько же, столько и экземпляров примитивов, и наличие у контрола нескольких дополнительных полей ничего не изменит. Какой смысл выделять поля, отвечающие за сам примитив, в отдельный класс?
Никаких дополнительных полей у контрола быть не должно. Поля, отвечающие за примитив, тоже не надо. Дело в другом — в режиме дизайна ты работаешь с контролом или чем-то, изображающем из себя контрол (чтоб быстрее работало и.. дуги, сам понимаешь...). Рамки выделения и другие элементы управления — почти точно контролы.
Но в конце концов тебе придется перевести это в другое представление — линии, круги и пр. Помимо прочего, нашпиговывать контрол геометрическими расчетами совсем неправильно.
Один контрол изображает внешний вид, другие позволяют редактировать свойства. Дизайнер знает обо всех них, принимает сообщения, обрабатывает клавиши, а также:
• перекачивает данные из контролов в классы примитивов, чтобы при последующем вызове у экземпляра класса примитива метода
вроде CalculateBodyAngle или свойства NormalLine, все обсчитывалось правильно.
• предоставляет дизайнеру сцены (или там... чертежа).. получать данные о snappoint's.
• Сам, или созданные им тулзы, кладут транзакции (команды) о выполняемых операциях в стек отмены текущего дизайнера сцены
(или специального DesignService).
