RIA crumbs.

Небольшой tips’n'trick для тех кто борется или будет бороться с тем, что IE “отхватывает” фокус при навигации внутри Flex приложения табом. Все что нужно сделать, это прописать параметр <param name=”SeamlessTabbing” value=”false”/>. Который реализован для “нативной табуляции” с целью устранить “замкнутость” Flex приложения в себе, чтобы пользователь не “табался” только внутри приложения, но и мог перейти табом в адресную строку браузера и т.п.

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

Продолжаем тему о Flex 3 Builder, и его “тонкостях”. Сейчас расскажу о том, как просматривать исходники своих собственных SWC по F3 или Ctrl+Click. Итак

Для того чтобы иметь возможность работать с исходниками подключенных к проекту библиотек нужно, при подключении библиотеки задать значение свойству библиотеки Source attachment. И все Это не хитрое действие позволит вам не только смотреть на свои классы, но и ходить по ним в процессе дебагинга.

После установки билдера от Flex 3 beta 2 я начал доводить его до рабочего состояния, и на первом же этапе, при установке Subclipe меня обругали и попросили org.eclipse.jdt.core. Не долго мучаясь, времени было в обрез на любование новой штукой, я обновил практически весь Eclipse, и потом поставил все что мне нужно. Но минус в таком способе такой, что с нужной нам org.eclipse.jdt.core ставится куча разного хлама который мешает жить и еще плюс ко всему лезет в help

Но нашёл более правильное решение, уже дома не спеша, без глобализма так сказать.

Делаем так:

Help > Software updates > find and install > search for new features to install > Europa Discovery Site ( тут убираем галку с “ignore features not applicable to this environment” > (выбираем откуда качать) > Java Development > Eclipse Java Development Tool 3.3.1.

Вот собственно и все. Дальше можно уже ставить свои плагины без проблем.

ps. надеюсь я не последний до этого додумался

Решил поделиться рецептом для осуществления копирования большого количества файлов в связке Flex + MDM Zink под Mac OS.

Проблема с копированием большого количества файлов, используя MDM Zink API для работы с файловой системой, скажем, с CD на винт, и расфасовке их по папкам под Mac OS заключается в том, что MDM Zink Flex projector просто-напросто переставал копировать, не выдавая при этом никаких признаков того, что процесс копирования умер и ждать собственно нечего, плюс ко всем этим прелестям он копирует довольно долго даже сравнительно не большие файлы до 100 kb.

Служба поддержки у MDM Zink говорила в ответ на запрос, что, мол, таки да, но пока ничего поделать не будем.

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

В результате всех этих неуспешных попыток настало время кардинальных методов; в начале пробовал реализовать копирование файлов посредством AppleScript (только для Mac OS), благо в API у MDM Zink заложена такая возможность. Но снова решение не совсем удалось, во-первых, из-за того, что AppleScript обладает не совсем привычным синтаксисом, и с первого раза не “раскуришь” все тонкости “языка яблок”, простенький пример, который считает количество файлов в папке “Applications”:

[code lang="applescript"]
tell application "Finder"
if folder "Applications" of startup disk exists then
return count files in folder "Applications" of startup disk
else
return 0
end if
end tell
[/code]

Да и не очень удобно было производить отладку, так как в начале приходилось писать код на Mac’e, в его чудном редакторе ScriptEditor, потом переносить в MDM Zink под Win, так как проект собирался на Flex + MDM Zink под Windows, где он не всегда компилировался. В итоге я не нашел консенсуса с “языком яблок” и принялся искать другое решение.

Финальная часть “марлезонского балета”: ситуация спасена благодаря тому, что MDM Zink API предусмотрел возможность работы с MacShell, он же bash. Посредством команд MacShell мы успешно копируем файлы.

[code lang="actionscript"]

// file это наш типизированный объект в котором идет нужая нам инфа
private function doCopy ( file:CopyTarget ) : void
{
// преобразовываем пути в макосъедобные, на случай если они у вас в win формате
var macFromPath : String = mdm.FileSystem.nativePathToUnixPath( file.copyFrom );
var macToPath : String = mdm.FileSystem.nativePathToUnixPath( file.copyTo );

// устраняем лишний слеш, если его нет, то устранять не нужно
macFromPath = macFromPath.slice( 0, macFromPath.length - 1 );
macToPath = macToPath.slice( 0, macToPath.length - 1 );

// оборачиваем все в кавычки "
macFromPath = '"' + macFromPath + '"';
macToPath = '"' + macToPath + '"';

// составляем shell команду
var shellScript : String = 'cp ' + macFromPath + ' ' + macToPath;

// запускаем, подчеркивания убрать поставил из-за того что WordPress отказывался сохранять пост
mdm_._Mac_Shell_._exec_( shellScript );

// тут вызов рекурсии по таймеру, чтобы дальше копировать и отображаем прогресс копирования
setTimeout( processCopyFiles, 600 );
}

[/code]

Итого, алгоритм действий, которые позволяют решить проблему с копированием большого количества файлов из MDM Zink под Mac OS:

1. Подготавливаем заранее пути для создания каталога/ов и для копирования файлов (откуда и куда; путь, куда копировать, нужен еще для того, что иногда хочется файл переименовать). Времени много не отберёт, но разгрузит нагрузку под Mac OS и упростит создание дерева каталогов, во время подготовки путей для каталогов можно отсеять дубликаты.
2. Создаём каталоги, это можно реализовывать через MDM Zink API, методом mdm.FileSystem.makeFolder();
3. Копируем файлы поштучно, используя MacShell, с небольшой задержкой (я ставил 600 мс);
4. Радуемся жизни.

Помимо всего, выигрышем в использовании MacShell является возможность радовать глаз пользователя такой замечательной вещью, как прогресс копирования файлов, чего никак нельзя сделать, если мы делаем какие-либо операции с файловой системой, используя MDM Zink API. Потому что он просто посылает Flex приложение в глубокий нокаут до завершения своих злодеяний, и на примере прогресса копирования счастливый пользователь увидит только состояние в 100%. Также мы легко можем сделать паузу/отмену копированию. В общем, сплошная радость.

Бонусный рецепт для тех, кто дочитал до конца . Рецепт, как закрыть ваше MDM Zink приложение, работающее под Mac OS, да еще и в fullscreen режиме. При попытке закрыть приложение путем MDM Zink API (mdm.Application.exit()), приложение бывает просто уходит в ступор и жалобно просит “force quit”, то есть “снять задачу”.

MDM Zink сапорт, когда-нибудь напишу про него отдельную статью, лаконично ответил: “А вы не юзайте fullscreen”.

Но выход есть, немного грубо, но работает, просто запускаем, через mdm.MacShell.exec(), чудную команду – “killall mdm-static”.

Fin.

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

ps. сорри за битый пост, была проблема с wordpress и code snippet плагином, чтото не дает сохранить пост с кодом

Всем столкнувшимся с проблемой передачи фокуса своему Flash/Flex приложению в Mozilla (FF) посвящается.

Недавно захотелось, чтобы приложение сходу, после запуска в браузере, без “стартового” клика по нему, “отлавливало” события мышиного колеса, к примеру.

В ходе детальных экспериментов и мучительных поисков, выяснилось, что в IE, как это ни странно, реализовать это очень просто. Достаточно просто-напросто при помощи JavaScript передать фокус вашей флешке, и все сразу счастливы:
[code lang="javascript"]
$("#MyFxApplication").focus();
[/code]
Но тут и вступает в игру FireFox, в котором фокус и события упорно игнорируют ваше приложение. На просторах Гугла и Яндекса нашлось много интересного, но все сводится к тому, что по-хорошему работать ничего не будет. Есть варианты, которые “лечат” эту болезнь у FireFox, но порождают болезни у Flex, отключение мультиселекта и fullscreen.

Такой вариант заключается в том, что приложению ставится wmode=”transparent” или wmode=”opaque”, а фокус передается тем же JavaScript, но с небольшим изменением, перед передачей фокуса приложению, даем его нашему body:
[code lang="javascript"]
$().focus();
$("#MyFxApplication").focus();
[/code]
Метод хорош, но мы теряем важные для большинства, как мне кажется, людей функциональности, причем fullscreen теряется как в IE, так и в FF.

Ответ Mozilla, по поводу этой проблемы, взято отсюда:

Mozilla hired a contractor to do the work, who stopped before finishing. Now
it’s too late in the release cycle to take the change, especially since there is
no one available and qualified to do the work.

I will push hard to get Mozilla Corporation to put someone on it after Firefox 3.

- Aaron

Есть варианты, где люди предлагают передавать события клавиатуры и мышки, в Flash/Flex через ExternalInterface. Чем-то это решение и хорошо, но при большом приложении можно немного затеряться при “расфасовке” входящих событий из JavaScript. И все равно остаётся проблема автофокуса.

Итого, будем ждать и надеяться, что в FireFox 3 все будет хорошо, и все им дружно будут пользоваться, или …

Но, есть еще метод от _etc, который предлагает зайти со стороны AS2. Главными идеями метода, являются:

• Подписываться на глобальные события мыши, как в AS2, везде и всюду, в любом классе;
• Не иметь привязки ни к какому InteractiveObject, необходимости наследования, отрисовки чего-либо;
• Захват скролла мыши от браузера (в AS3 скролл продолжает работать в самом браузере).

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

ps. Если кому удалось решить данную проблему, просьба поделится со страждущими

pss. В JavaScript примерах использовался синтаксис суперзамечательной библиотеки jQuery, о которой мне рассказал Майкл Клишин. За что ему большое человеческое спасибо.