Форум Flasher.ru - Грамотный вызов stop() у мувиклипа

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - Грамотный вызов stop() у мувиклипа (http://www.flasher.ru/forum/showthread.php?t=174987)

Грамотный вызов stop() у мувиклипа

Приветствую, уважаемые коллеги!
Есть дилемма, которая меня давно мучает: я не знаю, как грамотно вызывать stop() у мувиклипа с областью видимости функции.

Есть три часто встречающихся способа, но все они мне не подходят.
1. Вызывать stop() в непосредственно в нужном кадре, но вызов функций в кадре - это нехорошо.
2. Использовать addFrameScript() где callback является анонимной функцией, в которой будет вызван stop() у мувиклипа, но анонимные функции - это тоже нехорошо.
3. Использовать addFrameScript() где callback является глобальной функцией, но в таком случае придется и мувиклип делать глобальным, а это опять же нежелательно.

Может можно как-то в callback передать параметр с мувиклипом? Или может существуют какие-нибудь другие, более грамонтные способы?

ээ, а сделать функцию, которая говорит мувику stop - уже не актуально? создал ее и оперируй с ней

А как она ему это говорит? Посредством того, что она анонимная, или посредством того, что мувиклипу придется делать глобальную область видимости. Оба эти варианта меня не устраивают. Повторюсь, у мувиклипа область видимости функции.
Еще пришел в голову вариант создавать для каждого мувиклипа отдельные классы, в которых и будет stop() вызываться напрямую, но это тоже извращение какое-то. Если мувиклипов будет сотни?

Совсем непонятен вопрос. Ну есть на сцене мувиклип , ну обратились вы к нему из класса как mc.stop() тогда когда это надо. в чем проблема то? Что значит область видимости функции? - откуда такие понятия *?

Цитата:

Сообщение от in4core (Сообщение 1061409)

Что значит область видимости функции? - откуда такие понятия *?

Такие понятия у Мука я вычитал, но может что-то неправильно понял и это называтся по-другому (просто локальная область видимости, например).

Вот что имелось ввиду под вторым вариантом (локальная переменная и вызов анонимной функции, останавлювающей мувиклип):

Код AS1/AS2:

private function foo():void 

{

        var mc:check_mc = new check_mc(); //у объекта mc локальная область видимости

        mc.addFrameScript(mc.totalFrames - 1, function ():void { mc.stop(); } ); //анонимная функция останавливает мувиклип

        addChild(mc);

}

Третий вариант (делаем мувиклип глобальным с глобальной callback функцией, но делать мувиклипу глобальную область видимости нежелательно):

Код AS1/AS2:

private var mc:check_mc;

private function foo():void 

{

        mc = new check_mc();

        mc.addFrameScript(mc.totalFrames - 1, onFinalFrame);

        addChild(mc);

}

 

private function onFinalFrame():void

{

        mc.stop();

}

последний вариант - верный вариант, так и надо писать. и это не глобальная область. а область ( поле ) класса. глобальная это когда во всех классах. не путайте. а локальными переменными пользоваться только в случаях реальной необходимости, например как в цикле

Цитата:

Сообщение от in4core (Сообщение 1061412)

и это не глобальная область. а область ( поле ) класса. глобальная это когда во всех классах. не путайте.

Ой! Извиняюсь, совсем затупил под вечер :)

Цитата:

Сообщение от in4core (Сообщение 1061412)

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

Прошу прощения за флейм в своей же теме, но чем так плохи локальные переменные?

Цитата:

Сообщение от in4core (Сообщение 1061412)

последний вариант - верный вариант, так и надо писать.

А если у меня этих мувиклипов несколько десятков и у каждого должен быть с десяток вызовов stop() в разных кадрах? Все мувиклипы выносить в поле класса и для каждого создавать отдельную функцию, вызывающую stop()?

Цитата:

Сообщение от gait (Сообщение 1061405)

1. Вызывать stop() в непосредственно в нужном кадре, но вызов функций в кадре - это нехорошо.

Откуда такая информация? Аргументируйте - мне самому интересно. А то, если клип из SWC должен проделывать какую-то анимацию я всегда пишу в кадре "stop()", "gotoAndStop()" etc.
Короче такие маленькие методы я всегда пишу на кадре, зачем засорять класс какими-то ненужными функциями, ентерфреймами и проверками, ради того чтобы остановить какой-то незначительный мувиклип, который и так должен должен остановится после проигрывания анимаии. Короче вот это:

Код AS3:

private var mc:check_mc;

private function foo():void 

{

        mc = new check_mc();

        mc.addFrameScript(mc.totalFrames - 1, onFinalFrame);

        addChild(mc);

}

 

private function onFinalFrame():void

{

        mc.stop();

}

сравнивать с вот этим:

Код AS3:

this.stop();

Ничего не скажу, просто со стороны посмотрите.

Цитата:

3. Использовать addFrameScript() где callback является глобальной функцией, но в таком случае придется и мувиклип делать глобальным, а это опять же нежелательно.

Как in4core уже сказал - он не будет глобальным в таком случае а переменной или свойством класса. Опять же откуда такая информация, что это нежелательно? Пруф пожалуйста.

Цитата:

Сообщение от in4core (Сообщение 1061409)

Что значит область видимости функции? - откуда такие понятия *?

Это то же самое что локальная переменная - видна только в пределах одной функции.

Цитата:

Сообщение от in4core (Сообщение 1061409)

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

А че так? Наоборот же - она удалится GC после выполнения функции и не будет мозолить глаза...

Добавлено через 1 час 8 минут
PS: не поймите меня неправильно. Я не сторонник кода в кадрах. Просто, если есть возможность написать одну строчку в кадре, вместо 15 в классе, то допускаю что эту строчку можно повесить на кадр. Почему допускаю? - потому что это надо делать не все время и когда угодно. Это надо делать с умом. То есть делать лишь в тех случаях, когда код кадра никак не влияет на происходящее вне его пределах. Пример: есть анимация крутящейся звездочки (один оборот/10 кадров). Пишем в классе код - добавляем звезду в дисплей лист. Зачем писать какие-то addFrameScript или ентерфреймовские проверки "не проигралась ли анимация до конца", чтобы вернуть ее на первый кадр и снова проиграть? Лучше написать в кадре gotoAndPlay(1) - и звезда будет крутится вечно. А когда буду писать код в классе - мне не надо парится крутится там звезда или нет - я забываю про ее анимацию и манипулирую ею как простым спрайтом. Кто сказал что такой подход плохой?

О! Что-то я усложнил всё, может проще всего вот так?))

Код AS1/AS2:

mc.addFrameScript(mc.totalFrames - 1, mc.stop);

Он тоже в одну строчку :)

Цитата:

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

Я не сторонник кода в кадрах. Просто, если есть возможность написать одну строчку в кадре, вместо 15 в классе, то допускаю что эту строчку можно повесить на кадр.

Да просто, чтобы отделить мух от котлет. Может это звучит слишком категорично, но раз пишут, что кода не должно быть в кадрах, значит не должно (даже такой мелочи как stop()). Код должен быть в классах, а в графике должна быть графика, так сказать, принцип наименьшего удивления. Я вот уже как-то порвал себе волосы и потерял пару тысяч нервных клеток, пытаясь докопаться до бажины, забыв про stop() в глубоко вложенном мувиклипе и больше не хочу из-за таких мелочей терять время.

Цитата:

Сообщение от gait (Сообщение 1061487)

Я вот уже как-то порвал себе волосы и потерял пару тысяч нервных клеток, пытаясь докопаться до бажины, забыв про stop() в глубоко вложенном мувиклипе и больше не хочу из-за таких мелочей терять время.

Повторюсь:

Цитата:

Сообщение от HardCoder (Сообщение 1061425)

Это надо делать с умом. То есть делать лишь в тех случаях, когда код кадра никак не влияет на происходящее вне его пределах.

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

Чтобы писать код в кадрах, нужно сначала научиться не писать код в кадрах :) После этого появляется понимание, когда код в кадре является оптимальным решением, а когда - причиной потери кучи времени и нервов в будущем.