динамическое создание схемы.

[dimani4]

Всем привет. Делаю курсач. Суть работы в том что бы можно было на схему набрасывать элементы и связывать их мужду собой (ну и потом проводить расчет, но это не важно). Так вот кто нибудь что нибудь такое делал? Возникают вопросы в обработке событий например при перетаскивание мыши может поворачиваться элемент, может передвигаться элемент, может перемещаться связь, или прикрепляться к элементу. Как построить обработку событий, чтобы не возникало конфликтов?

Добавлено через 2 часа 15 минут
Может какой нибудь класс, который следит за всеми событиями и определяет обработчика?

[WRC_S]

Сам пиши класс, это серьёзный курсак получается, видал такие коммерческие схемы, сам диплом дела на редактор графов и пришлось не мало попотеть, изучил много чего пока соорудил что надо. Курсак по какому предмету и что за схема (тиматика).

[SamFR]

Сообщение от dimani4

Может какой нибудь класс, который следит за всеми событиями и определяет обработчика?

Одним классом тут не обойтись. Главное – хорошо продумать структуру, определить взаимосвязи. Выразить стутурные элементы в виде классов. Написать управляющий класс (или несколько управляющих классов разного уровня), которые будут заниматься логикой взаимодействия структурных элементов.

[dimani4]

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

[SamFR]

Первый вариант вполне рабочий.
А вот со вторым не понял. Что есть владелец?

[dimani4]

И как создать слушателя, который бы мог слышать события на всех объектах?

Добавлено через 7 минут
В схеме есть поле владелец события. По mouseDown в это поле пишу id элемента по mouseUp чищу поле. А все другие прежде чем что-то сделать спрашивают у схемы владельца и если владелец пуст или он сам владелец начинают работать.

[SamFR]

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

Также, возможно, будет удобнее перенести обработку MOUSE_DOWN/MOUSE_UP и других событий ввода, касающихся конкретного элемента, в класс самого элемента, а не обрабатывать их в схеме. Это обеспечит бОльшую гибкость в случае разных типов элементов, так как элемент сам сможет решать, как ему реагировать на ввод. А уже после принятия решения, если нужно, сообщать о нём схеме (с помощью посылки соответствующего события).

Слушателя события нескольких объектов можно создать, либо подписав его на это событие для всех объектов по очереди, либо используя бабблинг (всплывание событий). Во втором случае нужно передавать в конструктор события второй аргумент, равный true. Всплывание работает только для наследников класса DisplayObject, добавленных в контейнер. Слушатель можно добавлять в любом из иерархии родительских контейнеров.

[gloomyBrain]

package {
 
	import flash.display.Sprite;
	import flash.events.Event;
 
	/**
	 * ...
	 * @author gloomyBrain
	 */
 
	public class Main extends Sprite {
 
		public var s0:Sprite;
		public var s1:Sprite;
		public var s2:Sprite
 
		public function Main():void {
 
			s0 = new Sprite();
			s1 = new Sprite();
			s2 = new Sprite();
			s0.addEventListener("someEvent", onEvent);
 
			addChild(s0);
			s0.addChild(s1);
			s1.addChild(s2);
			s2.dispatchEvent(new Event("someEvent", true));
 
		}
 
		public function onEvent(evt:Event):void {
			trace("got you!");
		}
 
	}
 
}

В данном примере слушатель регистрируется в объекте s0, а событие возникает объекте s2. Событие ловится, т.к. свойство события bubbles = true. Это заставляет событие проходить по всей иерархии отображения.
Таким образом, Вы можете диспатчить события любым объектом, а решения принимать в классе схемы (родительском объекте)

Собственно, пример к тому что написал Samfr

UPD:
Я бы делел так?
1 - класс ОбъектСхемы
2 - класс СвязьДвухОбъектов

1 - должен иметь поля:
- тип
- размер
- координаты
- связи (массив ссылок на объекты класса связьДвухОбъектов)
- ... что-то еще по заданию

1 - должен диспатчить события:
- при перемещении
- при удалении
- при изменении других свойств

1 - должен слушать свои события:
- перемещения (и вызывать метод перерисовать() для всех своих связей)
- удаления (и освобождать все вои связи от ссылки на себя)

2 - должен иметь поля:
- тип
- цвет
- координаты одного конца |=> для создания связей без привязки к объектам
- координаты второго конца|
- первый объект (ссылка на объект класса ОбъектСхемы)
- второй объект (ссылка на объект класса ОбъектСхемы)
- ... еще что-то по заданию

2 - должен иметь методы:
- перерисовать() - метод, рисующий связь заново при изменении положения ОбъектовСхемы, ссылки на которые записаны в первомОбъекте и второмОбъекте данной связи
- ... еще что-то по заданию

[dimani4]

спасибо народ стало проесняться в моей голове. и еще вопрос если у меня в коде присутствует обращение к parent значит стоит задуматься об объектной модели(о свойствах и методах). Может есть какой нибудь патерн проектирования под управление событиями?

[SamFR]

Лучший паттерн – лист бумаги и автоматический карандаш Есть такая хорошая штука – UML. Никто, конечно, не запрещает рисовать по-своему, но ознакомиться очень рекомендую.

Да, обращение к parent – нехорошо. Задуматься стоит. Составной элемент схемы ничего не должен о ней знать, на то он и составной элемент. Не говоря уже о том, что тип придётся приводить – свойство parent имеет тип DisplayObjectContainer, а вам же, наверное, что-то вроде Circuit нужно.

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