Silverlight 3 Multi-touch: The Basics より。WM_TOUCH メッセージに対応していると言った方がいいのかも。Multitouch Input には IE8 が必要そうなことが書いてあります。Windows 7 なので IE7 という選択肢はそもそも無いのかも知れませんが、Firefox とかがどうなるのかはよくわかりません。
Silverlight 上での実装方法ですが、単に System.Windows.Input.Touch クラス の FrameReported イベント を受け取るようにするだけです。TourchFrameEventArgs の GetTouchPoints() メソッドなどでタッチされている座標などがわかりますので、あとは好きなように実装すれば OK です。
Silverlight 3 Multi-touch: The Basics にはデモ動画やサンプルコードもありますので、興味のある人は見てみては。
スポンサーサイト
Silverlight Version Compatibility より。
Silverlight 3 プラグインがインストールされていれば、Silverlight 2 アプリも 3 アプリも Silverlight 3 プラグインの上で動くことになります。
quirks mode について、Silverlight のプログラムマネージャである Tim Heuer 氏のブログに簡単にですが書いてありました。Check your Silverlight 2 apps for compatibility with Silverlight 3 の “A word on quirks mode” のところ。
これら 2つの記事の内容をあわせると、Silverlight アプリごとに AppDomain が作られ、また、quirks mode は AppDomain ごととなっている、ということになりますから、一つのページに 2 アプリと 3 アプリが混在していても問題は発生しないようになっている、ということになるわけですね。
HLSL in Office より。
まぁ、実用というより実験的なものなんだと思いますが （fxc.exe が必要なので DirectX SDK を入れとかなくちゃいけませんし） こんなとこにも HLSL が出てくるのかぁ、と思ったもので紹介してみましたｗ
A simple and totally thread-safe implementation of IDisposable より。
正直、IDisposable をスレッドセーフにする必要を感じたことは無いんですが、何となく気になったので。
ちなみに、IDisposable の実装方法のガイドラインは↓にあります。アンマネージ リソースをクリーンアップするための Finalize および Dispose の実装
Silverlight 2 には ItemContainerGenerator が無いため自前で実装する方法を 「[Silverlight] ListBox や ComboBox の各行の見た目にアクセスする 」 で紹介しましたが、ItemContainerGenerator in Silverlight 3
ちなみに、Silverlight 3 版の Silverlight Toolkit も独自に ItemContainerGenerator を実装するのはやめてビルトイン版のものを使うように変更されているそうです。（自分では確認してませんが）
"Printing" in Silverlight 3 with WriteableBitmap より
Silverlight で表示している内容のスナップショットを印刷する方法が紹介されています。
まず、WriteableBitmap クラスを使って Canvas をビットマップ化します。
続いて Joe Stegman 氏の PNG encoder の EditableImage クラスを使って上記のビットマップを PNG にして、そのバイト配列を Base64 化した文字列として取り出します。
この Base64 化した PNG 文字列を、あらかじめ HTML 上に用意してある <input type=”hidden”> な項目の value としてセットしてやり、サブミット （PostBack） してやります。
あとは、これをサーバで受け取って、PNG を組み込んだ PDF を作るなりなんなりしてレスポンスを返してやれば OK です。
なるほどなぁ。
7/13 の Worldwide Partner Conference 2009 で Microsoft Office 2010 のテクニカルプレビューの発表があったそうで、情報がいろいろと出てきてますね。
http://www.microsoft.com/office/2010/ Script# ってことは Ajax なアプリなのか。
Chalkbot at the Tour de France より
なにこれスゴイ
ナイキとランス・アームストロングの Livestrong foundation との共同プロジェクトの チョークボット だそうです。
ちなみに、Livestrong っていうのは、ガン撲滅とかガン患者の支援とかそういったことを目的とした基金だそうです。なので、このチョークボットもそういった活動の一環なんだと思います。
Windows Media エンコーダ 9 にはスクリーンキャプチャ機能があったのに、Expression Encoder には無くなっちゃってたんですよね。What’s new in Expression Encoder 3 」 によると、Expression Encoder 3 にはスクリーンキャプチャ機能が付くようです。
アナウンス通り 7月 10日に Silverlight 3 が正式リリースされましたね。
Silverlight 3 Released! What is new/changed?
テキストのレンダリングが進化したらしい。ここには書かれてないけど、他のブログで ClearType をサポートするようになったので文字がきれいになったし、小さい文字も読みやすくなったと書かれてるのを見た。 今まで Silverlight Tools を入れると勝手に入ってた ASP.NET サーバコントロールの asp:Silverlight と asp:Media は無くなった。<object> を書けばいい。欲しけりゃ http://silverlight.net/learn/whitepapers.aspx にある。 アセンブリキャッシングは beta では Microsoft の特定のアセンブリのみキャッシュ可だったが、どのアセンブリをキャッシュするか自由に指定できるようになった。 DataForm は Silverlight Toolkit に移動した。 （記事には書かれてないけど） Blend SDK ってのもあるみたい。Blend 3 に一緒に入ってる or 別途ダウンロードも可。Behaivor とかを作るときに必要なものが入っている模様。
http://www.office2010themovie.com/
なんだこれｗｗｗ
「[.NET][COM] Marshal.ReleaseComObject の危険性について 」 の記事へのコメントで Jitta さんに 「More on ReleaseComObject (and why we did not implement IDisposable on the classes contained in the RCW) 」 という続き的な記事があることを教えてもらいました。
以下、「More on ReleaseComObject (and why we did not implement IDisposable on the classes contained in the RCW) 」 より。
[厳密な訳ではありません。かなり大雑把ですし、一部英文の意味がよくわからないところもあります。正確なところはぜひ原文をご覧ください。なお、文字色や区切り線は原文にあわせてあります]
RCW に IDisposable を実装しなかったのは RCW が積極的に COM オブジェクトを Release することにリスクがあるからだ。それらのリスクの詳細は Yves blog link を参照して欲しい。
けど、それから誰かに聞かれた。
OK。RCW が IDisposable を使わないと決めたことに異議は無い。必要無いときに ReleaseComObject を呼ぶべきではないということにも同意する。
しかし、他の 2つの点について同意できないことがある。
RCW への参照を保持しているコードを ReleaseComObject したあとに使うことができないということ。
あるスレッドが ReleaseComObject を呼ぶときに他のスレッドが同じオブジェクトを使っていると、AV [アクセス違反のこと] が発生したりメモリがおかしくなったりすること。
#1 （前者のこと） は COM オブジェクトに限ったことではない。アンマネージリソースをカプセル化しているオブジェクトには同じことが言えるはず。たとえば、FileStream オブジェクトはクローズしたあとにリードやライトをすることはできない。しかし、FileStream は IDisposable を実装できないということはない。
#2 （後者） は私には理解できない。ReleaseComObject は IUnknown::Release を一度呼び出すんだよね？そうであれば、他のスレッドにどう影響するんだ？COM インターフェースをスレッド間でマーシャリングするとき CoMarshalInterThreadInterfaceInStream を呼びそれから CoGetInterfraceAndReleaseStream を呼ぶ。この結果オブジェクトの参照カウンタは一つインクリメントされる。オブジェクトがフリースレッドモデルで同じマルチスレッドアパートメントに属す 2つのスレッド間でマーシャリングするときは、確かに物理的に同じポインタを受け取ることにはなるが、その場合であっても参照カウンタはインクリメントされる。あるスレッドが ReleaseComObject を呼び、別のスレッドがそのオブジェクトを使っていたとしよう。ReleaseComObject の結果として参照カウンタは 1つデクリメントされるけれども、オブジェクトはまだ生きてるし、2番目のスレッドは普通に動く。なぜ AV やメモリがおかしくなると言ったことになるのか理解できない。
Dave の追加説明。
#1 について。他のマネージドコンポーネントも同じじゃないかということは正しい。しかし、RCW 自身が持っている COM コンポーネントを呼び出すたびに切断されていないかどうかをチェックするというコストを払いたくない。そのようにスタブは最適化されている。RCW はこの最適化された x86 スタブを通じてメソッドを呼び出すので、すでに ReleaseComObject を呼ばれている場合には AV の原因となり得る。こういったわけで、IDisposable を実装してるほとんどのマネージドコンポーネントの振る舞いよりもひどいことになってしまう。
#2 について。両スレッドが MTA ならばプロキシを取得する必要はないし、パフォーマンス的な理由で呼び出しのたびに COM コンポーネントの AddRef や Release を呼び出したりしない。この理由で、MTA スレッドから ReleaseComObject を呼び出すと別の MTA スレッドでメソッドを呼び出したときに COM コンポーネント内部で AV が発生したりプロセス全体の状態がおかしくなったりする。
結局のところ以下のような話なのかと思いました。
#1 の方を前回の記事と合わせて考えると、要するに 「ReleaseComObject でも IDisposable でもいいけど、もうちょっとうまいことできないのか？」 という話に対して 「COM の呼び出し部分ってなかなかそううまくいかない。だから IDisposable はやめた。ReleaseComObject は用意しておくけど不用意に使うと死ぬよ。だからコード書く人が十分に気を付けて ReleaseComObject を使うか、もしくは反対に何もせずにランタイムに任すかして欲しい。ランタイムに任せたときは GC によって解放された時かプロセスが終了するときに Release されることになるよ」
#2 の方はそれなりに COM のことがわかってないと意味わからないかもしれませんね。
じゃ、MTA じゃない場合は？
7/8 19:50 追記
News: Microsoft Silverlight 3 and Expression 3 Launch より。http://www.seethelight.com/
結局、beta 1 の後は何も出ずに RTW か。
July 7th, 10AM PT/1PM ET、ロサンゼルスのステイプルズ・センター （the Staples Center in Los Angeles） で開催されるマイケル・ジャクソンの一般向け告別式が Smooth Streaming + Silverlight を使って HD 品質で中継されるそうです。http://inmusic.ca/news_and_features/Michael_Jackson
（日本時間だと 8日の AM2時になるのかな？間違ってるかも）
2ch でもやけに評判がよかったスムースストリーミングですがｗ （【1080p】MS Silverlightのスムースストリーミングが凄すぎる件【XBOXLIVE】 ） さすがに今回は相当なアクセスがあるでしょうし、サーバや回線が耐えられるのかちょっと心配。
http://windows4all.com/
ちょっと不思議に思った点。
ところで、こういうのを見ると http://www.windowsvista.si/ を思い出す人もいるんじゃないかと思います。www.windowsvista.si － WPF/E のサンプル 」 なんて見ると、まだ Silverlight という名前が無く WPF/E と呼ばれていたころなんですね。
先日書いた 「[IE][C#][COM] IE のセキュリティゾーンをプログラムから操作する 」 に、元記事を書かれた Dennis "D.C." Dietrich さんがコメントをくれました。
そのコメントにてDiscussion of Marshal.ReleaseComObject and its dangers
[厳密な訳ではありません。かなり大雑把ですし、一部英文の意味がよくわからないところもあります。正確なところはぜひ原文をご覧ください]
Marshal.ReleaseComObject を使えば望んだときに即座にリリースできる。しかし、COM コンポーネントのマネージド表現である RCW のこれを呼ぶとき、もしこの RCW を AppDomain 上の他のマネージドコードが保持していると、リリースできなくて InvalidComObjectException が発生するだろう。
さらに悪いことは、呼び出しがすでにリリースされた RCW に行われると、その振る舞いは未定義である。AV [訳注: アクセスバイオレーションのこと？] が発生する機会になったり、メモリを腐らせたり、妙なクラッシュをするまでだらだらと実行し続けたりとデバッグをするのが非常に大変になったりする。
このリスクは CoCreateInstance が毎回同じインターフェースポインタを返すようなシングルトンな COM コンポーネントの場合にさらに悪化する。AppDomain 内の別々の独立したマネージドコードが同じシングルトンな COM コンポーネントの RCW を使っているとき、それらのうちのどれかがその COM コンポーネントの ReleaseComObject を呼び出すと他のところが壊れる。
これが、 本当に必要だという場合を除いて ReleaseComObject を使うべきではないと私が強く勧める理由だ！
別の話として、本当に ReleaseComObject を使う必要があるときには、.NET Framework 2.0 からある Marshal.FinalReleaseComObject を使うべき。この API は RCW が何回参照されていても COM コンポーネントをリリースしてくれる。FinalReleaseComObject ならばループの中で ReleaseComObject がゼロを返すまで繰り返すなんてことをしなくて済む。
なるほど、ものすごく納得です。
IInternetSecuriryManager のような COM インターフェースの場合は、うかつに Marshal.ReleaseComObject を呼び出すくらいなら放置しておいた方が安全というですね。
ちなみに、Excel を Automation 経由で呼び出す場合なんかの話は、上の議論とは別だと思います。
RSSリーダーで購読する