Results tagged “Progression”

Jul 072011

ProgressionでSWFAddressのExternalChangeが発動しない件

走り書き。

Progression4 + SWFaddressでindexにQueryって駄目だったっけ?
#?id=112
みたいなの。
この形だとexternalChangeeがWebSynchronizer内のSceneId.validatePathに引っかかってgotoまで遷移しない。(Queryの場合はSceneEvent.SCENE_QUERY_CHANGEも呼ばれない)

とりあえず間にひとつシーンをかませば問題なく動作する。
#/v/?id=2
みたいなかんじ。

SWFAddress単体では動作していたような気もするのだけど、記憶が定かではない。

Ref.Asual | SWFAddress - Deep linking for Flash and Ajax
Progression - Framework for Flash

Jun 262011

LoadBitmapData

久々Progressionネタを書いてみる。
LoadBitmapDataのcompleteの処理はL193から以下のように記述されている。
private function _complete( e:Event ):void {
	// 対象が Bitmap であれば
	try {
		// データを保持する
		super.data = Bitmap( _loader.content ).bitmapData;
	}
	catch ( err:Error ) {
		// データを破棄する
		super.data = null;
		
		// 破棄する
		_destroy();
		
		// エラー処理を実行する
		super.throwError( this, err.message );
		return;
	}
	
	// 破棄する
	_destroy();
	
	// 処理を終了する
	super.executeComplete();
}
これ、
super.throwError( this, err.message );
この部分
super.throwError( this, new Error(err.message) );
にしないと動かないんじゃないかしら?と思った。

そんなこたーないかしら? もうライブラリに手を入れないようにしようと思っているけれど、ちょっとここは直さないと動かないんじゃないかなぁ?

Feb 262011

managerの違い

SceneLoaderで外部Progressionを子供Sceneに設定した場合、子Progressionの中でのmanagerの参照先が参照場所によって変化します。

簡単書くと
SceneObject@manager > 子Progressionを参照
DisplayObjectを継承したCast系@manager > 親Progressionを参照

シーンはProgressionセグメントのレベルで管理されますが、Cast系はその辺には関与せず、純粋に最上位のProgressionの管理下に置かれるってな感じなのだと思います。

詳しい中身の管理ロジックについてはよく分からないですけど・・。

これ具体的に何が困るかというと、子Progression内で遷移の際の行き先や、出発点によって何かを制御しようとした際に、
getSceneBySceneId(manager.destinedSceneId)
としたときに、SceneObject上では問題ないのだけど、Cast系だと親Progressionを参照してしまうため、SceneObjectを参照できずエラーが戻ってくるという部分です。

なんか便利機能とかあるのかもしれないけれど、判別式で参照managerを切り分けて処理するようにしますた。

Jan 222011

SceneLoaderで読み込んだ外部Progressionのcontainerを設定する

Progressionで初期Loadの負荷を下げるために、シーンファイルを個別のswfで作成し、SceneLoaderで制御するという事は多々あります。

その際に外部swf内の子ProgressionコンテンツをAddchildする先を親Progressionのcontainerにすると、各コンテンツの深度制御がちょっと面倒になる時があります。(シーン移動のトランジション時など) その場合、子Progressionのcontainerを親Progressionの任意のDisplayObjectContainerにしてしまうと楽ちんです。

こんな感じ
親Progression
_boxContents = new CastSprite( { id:"box:contents" } );
addCommand(new AddChild(container, _boxContents));
var sLoader:SceneLoader = new SceneLoader("hoge");
sLoader.onScenePreLoad=function():void{
	var loader:LoadScene = new LoadScene(new URLRequest("hoge.swf", sLoader);
	loader.loaderContainer = _boxContents;
	sLoader.addCommand(loader);
}
addScene(sLoader);
これで、子Progression内における、"container"は、自動的に_boxContentsを参照することになります。

ちと自分はカスタムクラス化して、上記のような記述をしていないので、実際きちんと動くか?は分からないですけど・・・。こんな感じなのは間違いない。

で、もし親Progressionのcontainerにアクセスしたい場合はgetManagerByIdを用いて親Progressionのmanager経由でアクセスしてやればよいかと・・・。
これウソ。managerにcontainerを参照するproperty無かった。 あれー?

追記: Progression4から、各シーンのcontainerを変えれるので(って上でやってますけど)、manager.containerではなく、manager.root.containerでアクセスするかんじですね。(これもトップシーンのcontainerってだけですけど)もし、厳密にアクセスしたいのであれば、getSCeneByIdでシーンに直接参照する感じかな?しらんけど。

Nov 042010

Google Analyticsの新しいやつとProgression

ちょくちょく変わるGoogle Analytics。
ga.jsになったのは去年の12月。久しぶりに見たらまたちょっと埋め込みコードが変わっているっぽい。(headの中に入れるようになっていた)
まぁ昔のやつでも動作するし、特に問題は無いのだけど、Getting Started with the Asynchronous Snippet - Google Analytics - Google Codeこの辺のやつにチラッとProgressionで対応できるように。

Progression純正のやつは"WebSynchronizer"になるのだけど、この中で定義されているのは
pageTracker._trackPageview
urchinTracker
の2タイプ。

新しいやつはswcコンポーネントから"GATracker"生成してやれということなのですが、"WebSynchronizer"の中に手を入れる必要があるので面倒だなと・・。
"GATracker"を使うメリットはそれなりにあるので、一応それのProgression連動クラスは作ってはいるけれど、使う必要が無い場合に純正のProgressionのまま対応する方法を考えてみた。

Continue reading Google Analyticsの新しいやつとProgression.

Oct 012010

LoadBitmapData.defaultCacheAsResourceなど無い

最近あまりFlash実装の機会がありませんけれど、唐突にProgression。

LoadBitmapDataのdefaultCacheAsResourceを設定しようとして、
LoadBitmapData.defaultCacheAsResource
とか書いてエラーになって困っていたが、ドキュメントのURLをよくよく見たら、リンク先がsuperClassのLoadCommandになっていたアルヨ。

LoadCommand - Progression 4.0 API Reference

つまりLoadCommandのサブクラスも一括設定ということで、他のサブクラスでCache有効にしたい場合とかは個別インスタンスで設定すべし。
べしべし。

なんか前も似たようなことをやっていた気がするけれど・・・。忘れた。

ちなみにキャッシュ有効にして、LoadCommand.disposeを使用しないで、BitmapDataを直接disposeするとリソース管理が把握できなくてヌルっちゃいます。注意。

Mar 192010

API系の画像取得の際

最近はAPIでGETから画像を取得したりすることがありますが(hogehoge/thumb?id=1234みたいな)、その際にLoadCommand系でアクセスするならcacheAsResourceをきちんとfalseに設定してあげましょう。


1つ目を読み込んだあと、次のデータを読み込むために引数を変更してコマンド実行しても、リクエストを発生させず、completeが発動させ、キャッシュリソースとして格納されているデータを戻してきます。


よく考えれば動作としては至極正常。つまりLoadVarsはResourceの一意性を保証する要素では無いというだけの話。一見不便に思えるがCashBusterなどのことを考えると至極当然。


このResource機能はとても便利なのですがね。元々この手のリソース情報は別途リソース管理用のクラスで管理する方なので、ちと失念していた。これはProgressionの初期化の際にConfigで全体としてONN/OFFとかできてもいいんじゃないかなあ・・って思った。(今は毎回LoadCommand系を全部Offにする必要がある)
※Saqooshaさんからのご指摘の通り、Static propertyの
LoadCommand.defaultCacheAsResource = false;
で設定してあげれば一括設定可能でした。失礼しましたー。


何回読んでも違うデータが出てくるとか、リクエストが発生しないとかそういう場合、ちょっとこれを思い出してみればいい。

Oct 192009

Query周りとか

日曜はワイフとマイソンが遊びに出かけたので、これまでの処理を再度見直してみる。
これまでウニャウニャにしてた部分は
SceneEvent.SCENE_QUERY
のイベントに絡んだコマンド処理の部分。

Query変化時のProgressionのステータスとしては
1)progression.running==true
2)progression.running==false (既にそのシーンにいる)
の2パターンが存在

1)の場合はloadイベント後にSceneEvent.SCENE_QUERYが発動するのでSceneObjectにaddCommandしてやれば特に気にすることは無い。
問題は2)の場合、SceneObjectのコマンドで制御できないので、独自にSerialListで管理するわけになるのだけど、その際の_onGoto時との連動部分。

簡単に言うと、常にコマンドは別で用意したSerialListで管理して、それをProgressionの状態によって、SceneObjectに追加するか、executeさせるかを切り分け。_onGoto時には、そのSerialListをinterruptしてリセットという処理をSceneObjectのコマンドに追加。

ってな感じでシンプルに制御できた。

これまでSceneObjectのコマンドと、SceneEventに絡まないCommandを別管理してややこしいことになっていたのだけど、この辺がかなりスリムになってスクリプト的に見通しもよくなったし、動作も軽快になった。

やっぱ日々の業務に追われない時間の中での作業時間って必要だ。

#Progression4でその辺どうなってるのか、知らないけど・・・(ゴメンナサイ

Feb 092009

ProgressionでRSLを配置するとCastDocumentの"_onInit"がロストしてしまう件

先日のエントリー(AS3での埋め込みフォントの共有について:其の伍[RSLの先読み対応 with Progression](多分解決))の中で書いた、「2)ProgressionでRSLを配置するとCastDocumentの"_onInit"がロストしてしまう。」の件について少し調べてみました。前回のエントリーでは

loaderInfoの"Event.COMPLETE"がRSLが存在すると発動しないというのが起因しているかと思います。
ってさらっと書きましたが、一応順を追って書いておきます。

"CastDocument._onIinit"は"ExDocument._initialize"内でdispachされて発動されます。"ExDocument._initialize"の発動は、"ExDocument"内の4つのフラグ"_initialized","_loaderInited","_loaderCompleted","_addedToStaged"が

if ( _initialized ) { return; }
if ( !_loaderInited ) { return; }
if ( !_loaderCompleted ) { return; }
if ( !_addedToStaged ) { return; }
を満たした場合に実行されます。 で、RSLを配置しない場合は
trace("ExDocument._initialize",_initialized,_loaderInited,_loaderCompleted,_addedToStaged);
//ExDocument._initialize false false false true
//ExDocument._initialize false true false true
//ExDocument._initialize false true true true
//発動
な感じで"_onInit"がcallされます。

一方RSLを配置した場合は

trace("ExDocument._initialize",_initialized,_loaderInited,_loaderCompleted,_addedToStaged);
//ExDocument._initialize false false false true
//ExDocument._initialize false true false true
//停止

のなります。問題になっているのは3番目の変数"loaderCompleted"であって、これは"ExDocument.loaderInfo"の"Event.COMPLETE"によって切り替わるフラグになります。

loaderInfo.addEventListener( Event.COMPLETE, _complete, false, int.MAX_VALUE, true );

つまり"CastDocument.loaderInfo"の"Event.COMPLETE"が発動しない。というのが先の

loaderInfoの"Event.COMPLETE"がRSLが存在すると発動しないというのが起因しているかと思います。
この一文の意味するところです。

RSLを配置していると何故に"CastDocument.loaderInfo"の"Event.COMPLETE"が発動しないのか?そこさえクリアすれば動作するのですが、RSLの情報にどーやってアクセスすんだ?ってことろが未だ分からず途方に暮れております。

Continue reading ProgressionでRSLを配置するとCastDocumentの"_onInit"がロストしてしまう件.

Feb 072009

AS3での埋め込みフォントの共有について:其の伍[RSLの先読み対応 with Progression](多分解決)

さて、現実的に使うためにどーするか?ということを考えてみます。特にProgressionで・・・。

問題点としては
1)共有フォントの読み込みがドキュメントクラスのコンストラクタ前に発動してしまう。
2)ProgressionでRSLを配置するとCastDocumentの"_onInit"がロストしてしまう。
この2点をなんとか解決したいと思います。

2)はloaderInfoの"Event.COMPLETE"がRSLが存在すると発動しないというのが起因しているかと思います。(何故なのか?は不明。そもそもRSLのローディングが管理できないのでどーしていいのやら)
ということで、コチラは無理やり"CastDocument"のコンストラクタに

addEventListener(Event.ADDED_TO_STAGE, _onAdd);
として、_onInitに連結します。(override出来ないから)

これに関しては諸々調べていますが、問題が発生する可能性があるので、暫定的な処理とさせてください。実際にこの手法を用いる際にはリスクがあることをご理解の上、実装してください。(今のところ問題が発生するものとしないものの2つのパターンがあることは確認していますが、明確な切り分けは出来ていません。)

private function _onAdd(e:Event):void
{
	_onInit();
	removeEventListener(Event.ADDED_TO_STAGE, _onAdd);
}

一応_onInitの重複発動(Preloader経由だと"Event.COMPLETE"が発動するので)防止のために、"onInit"の最初に以下の一文を入れておく。

if (prog) return;
Continue reading AS3での埋め込みフォントの共有について:其の伍[RSLの先読み対応 with Progression](多分解決).

Feb 072009

AS3での埋め込みフォントの共有について:其の参[ランタイム共有ライブラリ編](未解決)

AS3での埋め込みフォントの共有について:其の一の続きです。

子swfのFontクラスを親swfで使用するやり方は便利な面もありますが、先のエントリーに書いたようにコンフリクトが発生する可能性があります。コンフリクトをクリアするには、子swfの中でそのフォントのTextFieldを適応したTextFieldを生成して親に戻してやれば親swf上で表示可能ですが、早い話がTextFormatのテンプレートを内包する必要があり、TextFormatが追加になるたびにデータサイズの大きいフォントを内包する子swfを更新、その都度ユーザに読み込み負荷をかけることになり、本来の目的に則していないことになります。(コンパイル時間の短縮という制作サイドの利点もありますが、あくまでユーザの利点ベースで考えていきます。)

ということで、他のフォント共有方法というと昔からあるRSL(ランタイム共有ライブラリ)のやり方です。昔はこのやり方のほうにフォントのコンフリクトが発生していたのですが、どうもこの一連の検証をしていてフォントの管理方法がPlayer9からクラスベース(リンケージネーム)からFont.fontName(String)に変更されたような感じです。(この辺はapeirophobia: 特定の文字だけを埋め込んだフォントのランタイム共有方法(AS 2.0)に書いているように、Player9からコンフリクトが改善されている)

ということでまぁこなれた手法ではありますが、一応検証。


Continue reading AS3での埋め込みフォントの共有について:其の参[ランタイム共有ライブラリ編](未解決).

Jan 182009

baseが上手く適応されない件(Progression3.1.2)

先日Progressionがバージョンアップした(blog.progression.jp» ブログアーカイブ » [リリース] Progression 3.1.2 をリリースしました)それに伴い、SWFObjectが2にバージョンアップ。それに伴いJS関係が色々変更。
今進めている案件はJSONを組み込んだりとJSを結構弄ってしまっていたので、Class関係だけを更新してJSは前のままにしたら、SWFAddressが動作しなくなってしまった(汗

ということでJS系の更新を試みたのだけど、外部ファイル参照起点設定のbase="."が上手く認識されないのか、起点がindex.htmlになってしまっているっぽく、外部ファイルの参照ができなくなってしまった。

ということでバージョンアップの手順を実際にやりながら書いていく。
(検証しながら色々やっていると自分でどこまで潰したか分からなくなるので・・・)

まず、オデの良く使うフォルダ構造は

/root
 index.html
 /swf
  preloader.swf
  index.swf
 /data
  hoge.xml

っつーような構造で、参照起点をindex.htmlではなく、/swfにする。これはまぁhtmlから読み込んだ際にも、Flashのパブリックプレビューからでも同じように外部ファイルにアクセスして動作するようにしたいということです。(じゃないと正直開発できない。)(index.htmlと同じ階層にSWFを配置すれば問題は無いのだけど、ルートに色々ファイルがあるのは個人的に好みではないというだけ・・)

じゃあまずFlash単体で動作するようにしてみようちうことで、IndexSceneの中でTopちうCastSprite拡張のクラスをAddChildして、その中で外部XML(hoge.xml)を読み込んでみる。

ま、特に悩むことはない。簡単に書く

var url:URLRequest = new URLRequest("../xml/hoge.xml");
net = new LoadURL(url);
net.after(_onLoadComp);
net.error(function(e) {
	txf.text += e;
});
addCommand(
	net
	);

index.flaをパブリッシュプレビューすれば問題なく読み込める。

次にswf/preloader.swfswf/index.swfを読み込み、その中からxml/hoge.xmlを読み込んでみる。いや、別に特別なことは何も無い、Preloader.asのコンストラクタは

public function Preloader() {
	// 読み込みたい SWF ファイルの URL を設定します。
	url = "index.swf";
	
	// SWF ファイルの URL の起点を、自身の SWF ファイルが存在するフォルダにするかどうかを指定します。
	useSWFBasePath = false;
}

ですが、swf基点からの読み込みなので、特に変更せずとも読み込める。
(ただuseSWFBasePath ってのがイマイチどのswfまで継承されるのか良くわからないけど・・)

ということで、一度HTMLを経由して表示してみる。

Continue reading baseが上手く適応されない件(Progression3.1.2).

Jan 152009

MovieClip.addFrameScript

Flashには幾つかundocumented functionが存在するのだけど、そのうちの一つ"addFrameScript"。
存在は知っていたのだけど、今まで上手く動作せず、どーしたもんかしら?と放置していた。ちと今回どうしても使いたくなってきたので改めてClassを見てみたらこんな感じだった。

// NON-DOCUMENTED (MANUAL ADDITION)
/**
* Attach a callback method to a frame. Note that this will replace any timeline code or
* previously attached callback.
* The callback method should not expect any parameter.
* @param frame Target frame number (starting from 0).
* @param notify Callback method to attach.
*/
public function addFrameScript(frame:uint, notify:Function):void;

やー (starting from 0).だった。これだけで長い間放置していた・・・汗

ちなみに複数フレームに一気に追加する場合には

addFrameScript(5, aho,6,aho2);

削除する場合には

addFrameScript(5, null);

となります。
ちなみにflashguruでは

addFrameScript(9,output,false,false);

というような記述がありますが、これは動作確認取れませんでした。


ちなみにProgressionの"ExMovieClip"クラスではループ再生制御のためにコンストラクタで

addFrameScript( totalFrames - 1, _complete );

されているので、ループさせる場合等には1フレーム程多目にフレームを定義しておかないとフレームアクションが上書きされてしまいます。


Ref.FlashGuru Consulting - Undocumented Actionscript 3

Dec 012008

Progressionサイトリニューアル

Progression™
リニューアルされました。
これに伴いドキュメントのURLも変更されました。(突然見れなくなって泣きそうになった)
All Packages - Progression 3.0 - API Reference

リニューアルに際して、恐れ多くもメッセージを送らせていただきました。
んが、ちょっと一人だけ浮いている気がします。ゴメンナサイ。
(仮面ライダーファンなら分かってくれると思いますが・・・)

Nov 222008

progression検証 #20 HistoryManagerの拡張

今回は正確に言うと検証ではなく、改造です・・・。
今後のバージョンアップ等を考えると同期が取れなくなるのでお勧めしません。実装される方は一応自己責任でお願いします。

ドキュメントには掲載されていないのですが、
jp.progression.core.managers.HistoryManager
という履歴を管理するクラスがあります。基本的にはブラウザの「戻る」「進む」ボタンに対応してシーンを遷移させる働きをしています。これを使用しているクラスとしては
jp.progression.core.managers.KeyboardManager
jp.progression.core.managers.SceneManager
jp.progression.core.ui.CastObjectContextMenu

の3つがあります。コンテキストとかは標準的に表に出てくるので使っている人も多いと思います。

で、これと同じ働きをする「back」「next」ボタンをFlash内で実装する場合

HistoryManager.back();//戻る
HistoryManager.forward();//進む
という感じになります。

ただ履歴とその中における現在の位置の関係が分からないため、これ以上戻れない、進めない状態になったときにボタンを殺したりすることができません。(その口を見つけられていないだけかもしれないけど)

つまりHistoryManager._positionとHistoryManager._histories.lengthの関係をチェックして、フロントのボタンの制御を行える口を用意したいなと・・。
ただposition、histories共にprivate static属性のためextendsもできず・・・ということでHistoryManagerに2つメソッドを追加してしまいました。

Continue reading progression検証 #20 HistoryManagerの拡張.

Nov 172008

progression検証 #19 progression.jsを使用した際のSWFForceSizeの挙動不審

ちとはまったのでメモ。

swfの最小表示領域を確保したい場合にSWFForceSizeを使用するのですが、それがIEで上手く動作しなくてフガフガしてた。現象としては
・設定ウインドウサイズになってもスクロールバーが表示されない
・最初に小さいウインドウで表示させた後に、ウインドウを拡大してもFlashサイズが変わらない。
・縦サイズのみスクロールバーが表示され、横方向は表示されない。
等、上手く動作するときもあれば、上記のようなバラバラの挙動を示していた。

SWFObject2.0でSWFForceSizeを使う | FlashやWebにまつわるいろいろなことが原因かな?とも思ったのだけど、ちと違う。そもそもSWFForceSize.onResizeDivが発動していない。

Progression.jsの中を確認してみると"/contents/objects/version.swf"を用いてバージョンチェックを行って、progression.onLoadを実行。その中でswfObject,SWFForceSizeを定義するってのがデフォルトの流れ。

SWFForceSize内部では定義時に

this.addWindowEvent( 'onload', this, this.onLoadDiv );

をセットして初期化を行うようにしている。

んがprogression.onLoadの発動タイミングによって、document.onload後にSWFForceSizeが定義される可能性があり、そこが多分不具合の原因なのではないだろうか?と思う。(違ったらごめん)

単純に考えて"prog.onLoad"の一番最後にdocument.onLoad()を強制的にCALLしてやれば上手く動くかな?と思ったのだけど、横方向のスクロール制御が不能になったりしたので断念。

外部JSの読み込みのタイミング等に依存しているのか上手く動いたり動かなかったりという不安定な挙動をしめすので一度Progression.jsをはずした形で実装を進めてみることにする。

落ち着いたらも少し調べてみる。

Nov 162008

progression検証 #18 CastImageLoaderの読み込み強制終了 CastImageLoader.close編

apeirophobia: Loaderの読み込み強制終了 Loader.close編apeirophobia: Loaderの読み込み強制終了 Loader.unload編の続き。Progression3でやるとどうなるか?の検証。

主要なコードは以下の通り。本当はもっとスマートな書き方がCastImageLoaderにはありますが、敢えてここはcontentsLoaderInfoと比較するためにこの記述の仕方で・・。
CODE:1

_loader = new CastImageLoader();
//CastImageLoaderイベント
_loader.addEventListener(CastEvent.CAST_LOAD_COMPLETE, _loaded_Loader);
_loader.addEventListener(CastEvent.CAST_LOAD_START, function() { trace("CastImageLoader::ロード開始");_output.text = "CAST_LOAD_START"} );
_loader.addEventListener(Event.UNLOAD, function() { trace("CastImageLoader::アンロードされました"); _output.text = "CAST_REMOVED" } );
//contentLoaderInfoイベント
_loader.contentLoaderInfo.addEventListener(Event.COMPLETE, function() { trace("contentLoaderInfo::ロード完了"); } );
_loader.contentLoaderInfo.addEventListener(Event.OPEN, function() { trace("contentLoaderInfo::ロード開始"); );
_loader.contentLoaderInfo.addEventListener(Event.UNLOAD, function() { trace("contentLoaderInfo::アンロードされました"); } );
・・・
_bt_cancel.onCastMouseDown = function()
{
	trace("CLOSE実行");
	if (_loader.contentLoaderInfo && _loader.contentLoaderInfo.bytesLoaded < _loader.contentLoaderInfo.bytesTotal)
	{
		_loader.close();
	}
	_loader.unload();
}
・・・
private function _loaded_Loader(e:Event):void
{
	trace("CastImageLoader::ロード完了");
	addChildAt(_loader,0);
}
で、一点注意点としてはCastEventは"UNLOAD"イベントを持たないので、その部分だけはEvent.UNLOADを使用します。あ、あとcontentLoaderInfoではなく直接CastImageLoaderを監視します。

プレビュー/ダウンロードシミュレートでの実行結果は

1:読み込み中にclose実行>読み込みは中断されず、COMPLETEイベント発生。ただし_loaderは表示されない。
2:読み込み前にclose実行>特に問題なし
3:読み込み後にclose実行>_loader消去
4:読み込み中にclose実行後、再度読み込み>2回目の読み込みCOMPLETEイベントが発生するが、_loaderが表示されない。
5:読み込み完了後にclose実行後、再度読み込み>問題なく表示
6:読み込み後、再度読み込み中にclose実行>unloadが無視され、COMPLETE発生後表示されてしまう。

という感じに。読み込みは中断されずCOMPLETEイベントは発生してしまいますが、表示されることはありません。

ただし4、5、6あたりが挙動が不審なところで、読み込み中にunloadを実行する、もしくは一度unlaod無しでCOMPLETEしてしまうとcontents(DisplayObject)の制御が利かなくなるようです。(ExLoader、ExImageLoader、CastImageLoaderの中を見てみましたが、ちょっと原因良く分からなかった)

HTTP経由での実行結果は

1:読み込み中にclose実行>読み込み中断。
2:読み込み前にclose実行>特に問題なし
3:読み込み後にclose実行>_loader消去
4:読み込み中にclose実行後、再度読み込み>問題なし
5:読み込み完了後にclose実行後、再度読み込み>問題なく表示
6:読み込み後、再度読み込み中にclose実行>問題なし

という結果になりました。プレビュー環境でおかしかった4、5、6辺りはHTTP経由では問題ないようです。

で、話はちょっと横にそれますが、contentsLoaderInfoのイベントとのタイミングですが、普通にLoadingした場合

CastImageLoader::ロード開始
contentLoaderInfo::ロード開始
CastImageLoader::ロード完了
contentLoaderInfo::ロード完了

というようにCastImageLoaderのイベントのほうが先に実行されています。ステキです。

では続いて、CastImageLoaderに最適と思われる記述の仕方をしてみます。

Continue reading progression検証 #18 CastImageLoaderの読み込み強制終了 CastImageLoader.close編.

Nov 122008

progression検証 #17 ページタイトルの設定

ProgressionはSWFAddressを内包しており、URLハッシュの制御が可能です。
また同様にSWFAddressの持っているページタイトルの制御もSceneObjectレベルで可能です。
(ただしブラウザ同期機能を有効にしておく必要があります)

やり方は簡単でSceneObjectの中で"title"を設定してやるだけで、そのシーンに移動した際にページタイトルが変更されます。
何も設定しない場合には各シーンのsceneIdが"|"区切りで表示されます。
インデックスシーンにのみ設定を行った場合には、そのタイトルの後ろにsceneIdが"|"区切りで表示されます。

注目すべき部分としてはシーンイベントの発生のタイミングではなく、"title"の変更を監視していて、titleの変更に対して随時ページタイトルを更新するという点です。

つまり"SceneObject"の中で複数のページタイトルを持たせることも可能と言うことになります。
(ただURLは別の話になるので、その行為にどれほどの意味があるのか微妙ですけど)
こんな感じ(※CastSprite等の中から)

getSceneById("hogehoge").title="ほげほげ";
titleのベース部分と、シーンタイトルを別で制御できたりするのか?はちょっとまだ良く分からないですが、まぁシーン設計の際にキチンとsceneIdが定義できていればtitleを設定しなくても問題ないかも知れません。(ただし日本語のタイトルはsceneIdに日本語を使ったことが無いので分からないですが・・・)

なんにしてもやりたいことの細かい部分まで行き届いていて、感心しきりです。

Nov 122008

Progression 3.0.7リリース

一日遅れですが
blog.progression.jp» ブログアーカイブ » [お知らせ] 緊急アップデートのお願い
だそうです。なにやらセキュリティに関する部分のアップデートということです。

このアップデートで修正される問題は、3.0.0 Beta 1 から 3.0.6 までの全てのバージョンが対象となっております。
過去、該当バージョンにて制作されたコンテンツに関しても、お手数ですがプロジェクトパネルの自動アップデート機能をご利用いただき、最新の状態となるように修正作業をお願い致します。

これはちょっと具体的な修正箇所を公開は難しそうです。
詳細は個別にメールでと言うことですが、これは大変だ・・・・汗

GNU系プロジェクトこういうときに本来の持ち味である公開性が使えなくって個人に負荷が集中してしまうのが辛いところ。やっぱなんかビジネスとして展開しないと作者さんが疲労してしまいそうで心配です。

AdobeCS4のアップデートで20万近くかかりますが、心情的にはProgressionにも20万ぐらい払いたい気持ちです。

ということでアップデートしてみます。

Nov 092008

progression検証 #16 CastDocumentでの先読み処理におけるProgression.sync=trueの設定

Progressionの便利機能の一つに

sync : Boolean
ブラウザ上でコンテンツを実行している場合に、URL と Progression インスタンスのシーンを同期させるかどうかを取得または設定します。 同一コンテンツ上で有効化できる Progression インスタンスは 1 つのみであり、複数に対して有効化を試みた場合、最後に有効化された Progression インスタンス以外の sync プロパティは自動的に false に設定されます。

があるわけですが、"Index(CastDocument)"クラス内でコマンドを使って外部ファイルのローディング処理等をしつつ、"sync=true"にしていると、コマンド処理待ちをすっ飛ばして自動的にfirstSceneIdシーンに遷移してしまいます。(prog.goto( prog.firstSceneId );"を記述していない場合、プレビュー環境では遷移しないのですがブラウザ上でみると遷移しちゃう)

各シーン毎に必要なものを読み込む様な形であれば問題ないのですが、先読みデータ前提で各シーンの設定していると(例えば外部イメージをbitmapdataとして保持して、そこから呼び出したり)、読み込み前のためにnullになってしまってエラーが出てきます。

でわどするか?っつーと"prog.sync = false;"の設定をコマンドの中にいれて設定を同期させてしまいます。つまり先読み処理が終わった後、且つ最初のシーンへの移動の間で設定する。こんな感じ
CODE-1

_list = new SerialList();
_list.addCommand(
・・・
  //先読み処理終了
  ,function() { prog.sync = true; }
  ,new Goto(prog.firstSceneId)
);
_list.execute();
これで多分大丈夫。 多分・・。
2  

Search and Archives

Tags