Проблема работы с TimerEvent, Tweener'ом

[SpetZ_Naz]

Тогда не понимаю в чем проблема. Почему кнопка должна реагировать при наведении на шарик?

Нет, Вы меня не поняли. Она именно не должна реагировать. На сцене, в результате манипуляций, лежат N-е количество шариков, кнопка и изображение. Навожу на шарики - они разлетаются, но код написан так, что кнопка и изображение тоже улетают, так как обработчик события у меня прописан для всех объектов, общий. Цель, отделить обработчики события для шариков отдельно, для кнопок отдельно: навожу на шарик, шарик улетел по своему обработчику, навожу на кнопку - стоит на месте, нажал на кнопку, появилось изображение, которое тоже должно по своему реагировать на движение мышью.

Вот реализация, работающая не правильно, реагировать должны только шарики:

[SpetZ_Naz]

Проблема не решена, также не знаю как отделить события для проекта, что выложен выше.

[Wolsh]

Вы предлагаете декомпилировать вашу флэшку?

Сам вопрос мягко говоря странный. Обычно на объекты с разным поведением вешают разные слушатели, невзирая на то что события могут быть одинаковыми. Ну не генерит мышь событие "наехала на шарик", "наехала на кнопку". Это шарик генерит событие "на меня наехала мышь". И Ваше право конечно слушать событие "на меня наехала мышь" от всего что на сцене одним слушателем. Но можно и разными, да. И соответственно делать разные действия. Конечно, совсем не обязательно создавать отдельную функцию для каждого шарика и каждой кнопки. Можно сделать один слушатель для всех шариков, если основные действия в обработчике одинаковые, надо только определить конкретный шарик, а это есть в событии. Можно даже сделать один обработчик для всех кнопок, но это уже гораздо реже, так как кнопки обычно запускают очень разные действия. Но уж точно нет смысла делать один обработчик и для шариков, и для кнопок.

[MINASTIS]

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

[SpetZ_Naz]

Вы предлагаете декомпилировать вашу флэшку?

Нет, это все та же программа, с которой все начиналось, листинг лежит выше (просто добавил кнопку). Вот вырезка из кода:

          //..................
 
           public function SuperCircle()
		{	
                // Создаю 50 шариков
 
			for (var i:uint=0;i<50;i++){
			bl = new Ball(0x00ff00,2);
			addChild(bl);
			bl.x = 100 + (i*bl.width);
			bl.y = 100;
			_dictionary[bl] = [bl.x, bl.y];
			}
 
                //Вешаю на них обработчик события MOUSE_OUT		
 
		this.addEventListener(MouseEvent.MOUSE_OUT, onMO);
 
               // Создаю кнопку (нарисовал сам в CS5 и обозвал Button)
 
		bt = new Button ();
		addChild(bt);
		bt.x = 200;
		bt.y = bt.height + 5;
 
                // Вешаю на кнопку обработчик события CLICK
 
		bt.addEventListener(MouseEvent.CLICK, onMc);	
		}
 
		private function onMc(e:MouseEvent):void 
		{
			pc = new PictureDwn("main.jpg");
			addChild(pc);
			trace("Click!!");
			bt.removeEventListener(MouseEvent.CLICK, onMc);
		}
		private function onMO(e:MouseEvent):void
		{
 
                // ...... продолжение кода...

Как видите в коде, строчка....:

this.addEventListener(MouseEvent.MOUSE_OVER, onMO);

.....вешает обработчик события MOUSE_OVER на ВСЕ объекты и получается, что пронося мышкой над новосозданной кнопкой, она тоже улетает как шарики, а мне этого Не нужно.

Попытки писать обработчики для каждого объекта, вместо this :

bl.addEventListener(MouseEvent.MOUSE_OUT, onMO);  // обработчик для ШАРИКОВ - 
                                                        //-срабатывает только последний созданный
bt.addEventListener(MouseEvent.MOUSE_OUT, onMO_2);// обработчик для КНОПКИ

...приводит к неправильной реакции шариков, т.е. срабатывает всего один, последний созданный, но кнопка, да, начинает реагировать нормально.

Так вот вопрос заключается в том, как грамотно разделить обработчики событий для каждого из объектов в МОЕМ случае.

[Wolsh]

public function superCircle()
{	
	// Создаю 50 шариков
	for (var i:uint = 0; i < 50; i++)
	{
		var bl:Sprite = this.addChild(new Ball(0x00ff00, 2)) as Sprite;
		bl.x = 100 + (i * bl.width);
		bl.y = 100;
		_dictionary[bl] = [bl.x, bl.y];
		//Вешаю на них обработчик события MOUSE_OUT
		bl.addEventListener(MouseEvent.MOUSE_OUT, onMO);
	}
}

[SpetZ_Naz]

var bl:Sprite = this.addChild(new Ball(0x00ff00, 2)) as Sprite;

Во-первых прошу объяснить, эту строчку, а во-вторых выдает ошибку при компиляции:

ReferenceError: Error #1074: Недопустимая запись в свойство "только на чтение" Sprite в global.
	at SuperCircle()

Может это из-за того, что я родителя не Sprite везде использую, а MovieClip? :::

1 ---  public class Ball extends MovieClip
2 --- var bl:Ball;

Добавлено через 6 минут

Насчет способа сделать отдельный класс, что отлично разграничит шарики от кнопок

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

package
{
    import flash.display.MovieClip;
    public class Ball extends MovieClip
    {   
        public function Ball(_color:uint,_radius:uint)
        {                   
                graphics.lineStyle(2,0);
                graphics.beginFill(_color);
                graphics.drawCircle(_radius,_radius,_radius);
        }       
    }
}

Мне проще обратиться из основного класса программы к этому путем наследования:

var bl:Ball;
bl = new Ball(0x00ff00,2);

MINASTIS, если не трудно, покажите, как дописать в класс Ball обработчик события для этих шариков... подозреваю что все просто, но пока не для меня..

[Wolsh]

Я Вас окончательно перестал понимать. При чем тут графикс. Какие проблемы с классом Ball от моего кода. 1) Ball наследует МувиКлип, МувиКлип наследует Спрайт. Любой Ball является так же и спрайтом. Не нравится — пишите MovieClip. Я опущу здесь размышления о том, нужен ли вообще класс МувиКлип, если нет никакой покадровой анимации (таймлайна).

Во-первых прошу объяснить, эту строчку

Создается локальная переменная bl типа Sprite, ей присваивается ссылка на новый экземпляр класса Ball, добавленный в список отображения (addChild()).

а во-вторых выдает ошибку при компиляции:

Это не моё. Следите за орфографией.

Насчет способа сделать отдельный класс, что отлично разграничит шарики от кнопок

Я согласен, что так было бы удобней в принципе, так скажем более профессионально

Я даже не понял о чем речь.

я не знаю как дописать в классе, где я рисую шарик, например смещение по Х

this.x += 15;

как дописать в класс Ball обработчик события для этих шариков...

Это наихудшее решение, какое вообще можно придумать. А было все так.. профессионально..

[MINASTIS]

Минутку. Я же выше кидал класс RandomBall. В нем всего-лишь дописать то, что шарик можно сколько угодно толкать, но он вернется.
То есть, в классе RandomBall шарик и рисуется, ему задаются координаты в конструкторе класса, которые при создании указываются, и они являются начальными.

Теперь, все проще пареной репы. Зачем делать цикл, который создает кучу параметров каждому шарику, если можно сделать класс (в нем все прописать, включая листенеры), и после циклом просто накидать экземпляров класса на сцену.

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

Может я чего-то не понимаю? По моему это даже логически упростит всю ситуацию.

[Wolsh]

ОК.
Сейчас речь пойдет немного не о флэш. О проектировании как самостоятельной дисциплине))
Вот представьте, что Вам на день рожденья подарили новый футбольный мячик.
Вы позвонили двум-трем друзьям и понеслись во двор гонять футбол.
Но, как часто бывает в фильмах ужасов, мячик оказался не простым.
Какой-то злой гений, доктор Девелопер, запихал в него устройство с искусственным интеллектом, и теперь мячик сам решает, куда ему лететь и в какой точке футбольного поля останавливаться.
Самое противное в том, что мячик делает это по каким-то своим правилам, а не правилам Футбольной Лиги, и даже не по вашим с друзьями правилам.
Теперь представим, что фильм приближается к хеппи-энду, и с помощью одноклассника-ботана вам удалось взломать мячик и Вы можете перепрограммировать его правила. Вопрос на засыпку: какова вероятность того, что Вы выберите отключить мячику всякое, любое, интеллектуальное поведение, и только тогда сможете наслаждаться игрой, когда он просто полетит туда, куда Вы его пнете?
В чём мораль?
Любой объект, являющийся частью системы, идеален тогда, когда не диктует своих правил объектам системы выше по иерархии. Объект должен заниматься только собой и своими подчиненными (своими частями). Футбольное поле не содержится в мячике. Контейнер не содержится в ребенке. Положение мячика это положение на поле. У самого мячика никакого положения нет. Есть положение лоскутов и ниппеля, и положение логотипа на мячике. Это — область ответственности мячика. Этого — ни поле, ни судья, ни голкипер не могут изменить в мячике. Это его личное дело, его личная ответственность, его составляющие в его системе координат. А вот положение мячика может изменить и голкипер, и защитник, и даже чирлидерша в розовых гольфах. Какой бы икс-игрек он там себе ни пыжился назначить, любой котенок без труда назначит ему другой одним касанием. Потому что у мячика есть место в иерархии и есть положение в системе координат его контейнера (стараюсь избежать слова "родителя", хотя обычно так и бывает). Управлять мячиком должен тот, кто его создал с известной только ему (не мячику!) целью, для решения своих (не мячика!) задач.
В данном конкретном случае у автора все было более-менее логично и соответствовало ООП. Конечно, можно расширять проект дальше, но — расширять, а не закапывать вглубь. Рано или поздно будет написан класс BallContainer или GameScreen. А кнопки и статусы будут вынесены в HUD. И еще много чего появится. Но если шарики будут летать по своим собственным делам, а кнопки будут сами решать, какие функции в главном классе им вызывать, это будет шапито, а не приложение, написанное программистом.