![]() |
динамическое создание схемы.
Всем привет. Делаю курсач. Суть работы в том что бы можно было на схему набрасывать элементы и связывать их мужду собой (ну и потом проводить расчет, но это не важно). Так вот кто нибудь что нибудь такое делал? Возникают вопросы в обработке событий например при перетаскивание мыши может поворачиваться элемент, может передвигаться элемент, может перемещаться связь, или прикрепляться к элементу. Как построить обработку событий, чтобы не возникало конфликтов?
Добавлено через 2 часа 15 минут Может какой нибудь класс, который следит за всеми событиями и определяет обработчика? |
Сам пиши класс, это серьёзный курсак получается, видал такие коммерческие схемы, сам диплом дела на редактор графов и пришлось не мало попотеть, изучил много чего пока соорудил что надо. Курсак по какому предмету и что за схема (тиматика).
|
Цитата:
|
У меня есть класс схема - большая плоскость на которую набрасываются др. элементы. Др.элемент может быть элементом узлом или связью. По поводу событий у меня две мысли: первая элементы выкидывают свои события, схема их слушает и решает что с этим событием делать.
Вторая: при нажатии мыши схема выставляет владельца, и если элемент не владелец(проверка внутри элемента), то он ничего не делает, а если владелец то делает то что ему надо, при отпускании мыши поле владелец чиститься. |
Первый вариант вполне рабочий.
А вот со вторым не понял. Что есть владелец? |
И как создать слушателя, который бы мог слышать события на всех объектах?
Добавлено через 7 минут В схеме есть поле владелец события. По mouseDown в это поле пишу id элемента по mouseUp чищу поле. А все другие прежде чем что-то сделать спрашивают у схемы владельца и если владелец пуст или он сам владелец начинают работать. |
Ну, если активен должен быть только один элемент и только нажатый, то да. Только лучше, чтобы элементы не лезли в управляющий класс. Это он их содержит, а не они его. Поэтому лучше, если при активации определённого элемента схема будет вызывать у этого элемента определённый метод (или устанавливать свойство). Аналогично при деактивации.
Также, возможно, будет удобнее перенести обработку MOUSE_DOWN/MOUSE_UP и других событий ввода, касающихся конкретного элемента, в класс самого элемента, а не обрабатывать их в схеме. Это обеспечит бОльшую гибкость в случае разных типов элементов, так как элемент сам сможет решать, как ему реагировать на ввод. А уже после принятия решения, если нужно, сообщать о нём схеме (с помощью посылки соответствующего события). Слушателя события нескольких объектов можно создать, либо подписав его на это событие для всех объектов по очереди, либо используя бабблинг (всплывание событий). Во втором случае нужно передавать в конструктор события второй аргумент, равный true. Всплывание работает только для наследников класса DisplayObject, добавленных в контейнер. Слушатель можно добавлять в любом из иерархии родительских контейнеров. |
Код AS3:
Таким образом, Вы можете диспатчить события любым объектом, а решения принимать в классе схемы (родительском объекте) Собственно, пример к тому что написал Samfr UPD: Я бы делел так? 1 - класс ОбъектСхемы 2 - класс СвязьДвухОбъектов 1 - должен иметь поля: - тип - размер - координаты - связи (массив ссылок на объекты класса связьДвухОбъектов) - ... что-то еще по заданию 1 - должен диспатчить события: - при перемещении - при удалении - при изменении других свойств 1 - должен слушать свои события: - перемещения (и вызывать метод перерисовать() для всех своих связей) - удаления (и освобождать все вои связи от ссылки на себя) 2 - должен иметь поля: - тип - цвет - координаты одного конца |=> для создания связей без привязки к объектам - координаты второго конца| - первый объект (ссылка на объект класса ОбъектСхемы) - второй объект (ссылка на объект класса ОбъектСхемы) - ... еще что-то по заданию 2 - должен иметь методы: - перерисовать() - метод, рисующий связь заново при изменении положения ОбъектовСхемы, ссылки на которые записаны в первомОбъекте и второмОбъекте данной связи - ... еще что-то по заданию |
спасибо народ стало проесняться в моей голове. и еще вопрос если у меня в коде присутствует обращение к parent значит стоит задуматься об объектной модели(о свойствах и методах). Может есть какой нибудь патерн проектирования под управление событиями?
|
Лучший паттерн – лист бумаги и автоматический карандаш :) Есть такая хорошая штука – UML. Никто, конечно, не запрещает рисовать по-своему, но ознакомиться очень рекомендую.
Да, обращение к parent – нехорошо. Задуматься стоит. Составной элемент схемы ничего не должен о ней знать, на то он и составной элемент. Не говоря уже о том, что тип придётся приводить – свойство parent имеет тип DisplayObjectContainer, а вам же, наверное, что-то вроде Circuit нужно. Почему бы, например, не высылать события? А родитель уже пускай на них реагирует соответствующим образом. |
| Часовой пояс GMT +4, время: 07:57. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.