обфускация swf Encrypt
 

Всем привет.

У меня есть два swf файла, первый - это лоадер, а второй - главный swf файлы который подгружается независимым лоадером.

Когда главная swf подгрузилась, я хочу получить flashvars.

написал вот так.
где flashvars в лоадере, это public переменная котоая сохраняет туда loaderInfo.parameters

Вобщем до обфускации все работало отлично.
После того как обфусцировал главную swf с помощью Encrypt 5.0
вылитают ошибки что он не может найти свойство flashvars в моем лоадере, видать обфускатор поменял имя.

Потом написал вот так уже

думал увидет что метод и не будет менять ему имя... но все равно пишет что не может найти такого метода.

Как обойти это?

не использовать обфускацию :)

зачем писать такие ответы? Если не знаете, можно вобще не писать.

Если я использую, значит есть на то причины.

flashvars, э... вроде ведь stage.loaderInfo.parameters? Или я не о том?

я же писал, это просто переменная

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

отдиспатчите наверх событие, что хотите получить некие данные. наверху подумают, подумают и отдадут вам эти данные )

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

В API vkontakte, тоже так сделано, там получаешь wrapper = Object(parent.parent) и уже потом вытаскиваешь из него и флешварс и вызываешь разные методы

я забил на вконтактовский application и сделал как говорит тигра - дергаю из стейджа и вся недолга

Anry_coolboy, дёргать parent у дисплей обджектов - дурной тон. А вот дёргать stage - нет. Проще говоря, чем Вам не угодил super.stage.loaderInfo.parameters? Попробуйте так.

P.S. если вопрос именно "почему" - то это баг криптера, очевидно.

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

Вдруг мне надо будет отправить другие данные.
Если я в главной swf сделаю метод что б передать данные, после обфускации прелоадер этот метод не находит.Точно так же и главная свф не видет методы прелоадера.

Добавлено через 1 минуту
Но почему же API Vkontakte так сделали, я думаю там тоже не дураки сидят....))

Диспатчите событие, ловите, отдавайте то что надо. Или передавайте ссылку в конструктор. Экспериментируйте. Флешку зашифровать - не кашу сварить)

)))) спасибо за советы.

вот разами сомневаюсь..

Почему? Мне вправду интересно знать.

Аналогично. ;)

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

Ребёнок не может приказывать родителю - из этих побуждений.

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

Об управлении родителем не было речи :)

Это частный случай, которой можно рассматривать только в определенном контексте. В общем случае ребенку о родителе знать вредно.

Ну вот вы завязываетесь на то, что обязательно будет св-во parent, оно будет не null и у него будет определённый набор св-в/методов.

Обычно использование parent (и прочих getChildPorn) плохо тем, что имеется в виду не "контейнер данного обьекта", а некий обьект, который по совместительству является контейнером данного обьекта. Ну т.е. если имеешь в виду "первая буква алфавита", то пиши "первая буква алфавита", не пиши "a". Иначе 1) - не понятно, что имеется в виду 2) если вдруг проявится разница в том, что надо и в том, что написано, то возможно, проще будет это место переписать (особенно весело, когда почти везде имеется в виду "первая буква алфавита", но в самых забытых местах таки "а"). Можно написать метод, типа getMyObject():MyObj { return parent as MyObj;}

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

Они знают про родителей необходимый минимум.

parent.removeChild(this) – нормально (более или менее),

parent.parent.parent.removeChild(parent.parent.parent.getChildByName('someChildName')) – та связанность, о которой я говорил.
Подход к parent'ам как у вас, рано или поздно приведет ко второму варианту.

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

А возможности огороды наогородить (про второй вариант) желающий везде найдет.

Это миф, что это нормально. Вот лежали у Вас в кармане деньги. И опа, решили исчезнуть. С точки зрения денег - всё нормально. С точки зрения Вас - вы охреневаете. Другое дело, если они сообщили что провалились в дырку в штанах, о чем сообщили.

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

Как раз земле совсем не по барабану.
Вдруг на земле наступило лето. Все снежинки сразу же оттаяли. Как их всех растаять? Земля должна приказать. А как приказать? Нужно иметь на них ссылки, например в массиве. А как иметь на них ссылку в массиве если не понятно, жива снежинка или мертва? parent.myArray.splice? Блестяще.

Вдруг лето не наступает это раз, а два снежинка помрет от повышения температуры, т.е. на неё может влиять контроллер атмосферы. Я к тому, что parent не всегда должен иметь контроль над детьми, только лишь потому что он родитель.

Тогда приведите вменяемый пример когда. В примере со снежинками я не могу в любой момент узнать сколько снежинок ещё живо без извращений.

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

А, ну синглтон тоже "понятен" в качестве центральной логики. Теперь Ваши мысли поняты правильно.

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

А в реальном мире "синглтон, _root, parent и т.п. - зло", вот это мифы.
Можно всё если с умом и в меру.

Мой мир строю я сам. Я не понимаю людей, которые сначала делают stage.addChild, а потом воют, что всё плохо и всё пропало, а с кодом невозможно работать. Начать нужно себя. Например, люди используя такие конструкции могли бы сказать что это плохо и так делать не нужно. Тогда может быть в мире стало бы на одного "идеального" разработчика больше, а автору слов что "суровые мир - суровое использование root и parent" не пришлось бы выть при копании в коде.

А может у меня ниша проектов побольше, чем тех, в которых допустимо parent`ить.

И тут ты заблуждаешься, не нужно только говорить что это плохо или так делать не нужно, нужно еще объяснить почему, раз уж взял на себя такие обязательства.

И не всегда нужно писать 5-7 классов ("идеальная" архитектура) чтоб вывести "Hello World!!!".

Ребёнок не должен командовать родителем - это вполне обосновано. Максимум - что-то у него спросить (parent.x).

Конечно не всегда. Идеальная архитектура существует только в конкретном проекте. Для Хэлоу Ворлд идеальная архитектура - один класс.

Тигра перфекционист )

а вообще - редко возникают ситуации явные, когда ребенок кричит родителю "удали меня!". скорее чаще возникают события "я изменился, посмотри, что там к чему". родитель ловит событие и понимает "бааа, ды ты же умер" и удаляет.

На счет парентов в принципе согласен - это инкапсуляция.
Но вот с обращением к паренту для самоудаления хотелось бы уточнить - просто на removeChild дебажный плеер ругается. Как тогда побороть?

скорее всего ругается на ссылку на null объект

Как ругается? Как удаляете?

Рано или поздно у любого программиста наступает стадия идиализации, когда хочется всё делать правильно и идеально. Потом наступает стадия "хочу на море", когда всё делается чтобы в этом не было противно копаться, с другой стороны чтобы работало. Я - в стадии идиализации. Мне можно )

если писать removeChild(this) - ругается (сейчас уже не помню как, может позже напишу)
а вот если
то не ругается
...как-то так.

Значит нету parent`а.

parent есть, 100%, т.к. все отличие именно в этой проверке, а от самого факта проверки парент появится не может