.NETラボ 勉強会 2015年04月の資料です。 Windowsフォーム開発に慣れきっている人がWPF開発に移行したときに、仕様の違いによりハマりやすい点を実体験も含めてお話しさせていただきました。 こちらのサイトで元のPPTXファイルをダウンロードしていただけます。 http://sonic.blue/it/129

1. WPF開発での陥りやすい罠
講師 .NETラボ 岡田 将

13. 独断と偏見による回答
理由はこの後のスライドでわかるかもしれません
Windows8だから作るのはWPF
Windowsフォームの上位機能だから、WPFに移行すれば大丈夫だろう
C#やVB.NETなど同じ言語だからどっちも開発は同じ
新しいことができるので、WPFつかってみよう
Windowsフォームがいまいち遅いので、WPFに移行すれば早くなる
解像度が上がったので、画面に合わせて表示を大きくしたい
見た目や動きがすごいものを作りたい
灰色の画面が嫌だ
△
×
×
○
△
○
○
△

14. WPFには得手、不得手があります
２Dグラフィックを使う
３Dグラフィックを使う
アニメーション表示
データ表示
データ入力（入力制限）
大量な画面表示
細かい制御
得意
得意
得意
得意
不得意
得意
不得意
とにかくグラフィック系が充実しています。

15. WPFとWindowsフォームにはこんな差があります
UIのレイアウト方法
Windowsフォーム
•絶対配置（パネルをうまく利用して相対配置も
できる）
WPF
•相対配置（絶対配置も可）
コントロール
Windowsフォーム
•外観のカスタマイズ性が低い
•細分化されたコントロールによる高い生産性
WPF
•外観のカスタマイズ性が高い
•標準で用意されているコントロールが少ない

16. なぜこんなに違いがあるのか？
 仮説１） Adobe Flashの対抗製品として出されたから。
→今は亡きSilverlightの上位機能版、WPFを先に作り簡素化する形で
Silverlightが作られた。（Flashもいまだ全盛なのでもったいない）
 仮説２）とにかくGPUをつかって表示したかったから。
→確かに表示は早いけど搭載機能が早熟だった。
 仮説３）このスマホのタッチアプリ戦国時代を見越していたから。
→時代を先取りしすぎた。

18. WPFの罠
 XAMLの罠
→XML形式での記述方式でHTMLっぽい記述だが、HTMLとは違います。
 Styleの罠
→いろいろできて便利だが、出来すぎて複雑。もちろんＣＳＳとも違います。
 データバインドの罠
→まずはＭＶＶＭを知らないととにかく使いづらい。
デザイナ作成もサンプルデータで対応しなければいけない。

19. WPF開発でやらかしそうなこと
 デザイナで画面を作ったが、XAMLの挙動がわからなくてとにかく時間
がかかった。
→XAMLをソースで読めるようになりましょう。
 HTMLで出来るから出来るでしょといわれたことが、簡単にはできな
かった。
→HTMLレベルの知識ではぜんぜん足りなかった。。。
というよりイベントが全然足りないし、うまく動かない。
 デザインが分業できるから効率が上がる。
→XAMLに対応できるデザイナがいなかった。
※ちなみに最近までExpressionStudioとVisualStudioとデザインの表現が異
なっていた。

20. WPF開発でやらかしそうなこと
 入力コンポーネントの機能が少なすぎて結局作り直した。
→設計とか調査でもっと早く気付きましょう。
（またはグレープシティやインフラジスティックスに泣きつきましょう。）
 無理やり対応しすぎてWPFのプロフェッショナルになった。
→先生、教えてください！

21. WPF開発でやらかしたこと
 同じプログラム、FrameWorkのバージョンでもWindowsXPとVista
で表示が異なっていた。
→お手上げ。せいぜい問題となるデザインの簡素化など。
 いろいろユーザーエクスペリエンスに懲りすぎて、表示エラーが出ま
くった。（SilverlightのサンプルをWPFに変換とか。。。）
→無視して修正し、何とか正常に戻る。

22. WPF開発でやらかしたこと
 いろいろユーザーエクスペリエンスに懲りすぎて、工数超過。
→怒られた。

23. WPF開発でやらかしたこと
 閉じるボタンの無効化などが簡単にできない。
→なんとかWindowsAPIを利用して対応。
//WindowsApiを宣言して閉じるボタンを無効化する
private const int GWL_STYLE = -16;
private const int WS_SYSMENU = 0x80000;
[DllImport("user32.dll", SetLastError = true)]
public static extern int GetWindowLong(IntPtr hWnd, int nIndex);
[DllImport("user32.dll")]
public static extern int SetWindowLong(IntPtr hWnd, int nIndex, int dwNewLong);
private void Window_ContentRendered(object sender, EventArgs e)
{
//閉じるボタンを無効化
var hwnd = new System.Windows.Interop.WindowInteropHelper(this).Handle;
SetWindowLong(hwnd, GWL_STYLE, GetWindowLong(hwnd, GWL_STYLE) & ~WS_SYSMENU);
}

24. WPF開発でやらかしたこと
 ボタンクリックがイベントから普通に呼び出せない。
→画面の挙動がメインとなる動作のため、表示側とバック側の共通処理がひたす
らエラーとなった。
なので、ディスパッチャーでなんとか対応。
//画面UIのイベントを処理するためのおまじない
Dispatcher.Invoke(new Action(() =>
{
//ここに画面更新処理を記述する
} ));
 画面更新（DoEvents）が使えない。
→これもディスパッチャー使った代用コードで対応。
//DoEventsの代わり
Dispatcher.BeginInvoke(new Action(() => { }), DispatcherPriority.Background);

26. WPF開発の華麗なる未来予想
 ストアアプリ開発もたぶん対応できる！
 今後主流になっていく技術なはず！
→いまはここまでXAMLの未来が来ていると増田さんも言っています！
Windows Store App を XAML で書く。
Windows Phone 8.1 アプリを XAML で書く。
Xcode で iPhone/iPad アプリを Storyboard で書く。
Android で axml で書く。
Xamarin.iOS/Android で、storyboard, axml で書く。
Xamarin.Forms で、Xamarin製XAMLで書く。
WPF で XAML で書く。
Siverlight を XAML で書く。

28. WindowsフォームもWPFで華麗なる変身
 棲み分けが出来ているので、まだまだWindowsフォームの需要はありま
す！
→Silverlightのようには、まだまだ終わりません。
 ElementHostを使えばWindowsフォームでWPF機能が使える。
→WPFの部品をForm内に持ってくる（ElementHostを利用）
using System.Windows.Forms.Integration; //ElementHost
参考サイト
http://jsdiy.web.fc2.com/software/wpftest/

29. まとめ
 適材適所で選択しましょう。
→ビジネス系はWindowsフォーム、グラフィックス系やタッチ系はWPFで。
 今後のためにXAMLは覚えるべき。
→覚えておくと、いざというときに役立つ気がします。
 Windowsフォームはなくならない。
→棲み分けが出来ているので、お互いにいいとこどりをしましょう。

30. 参考資料
 WPF は死んだのか？
http://www.moonmile.net/blog/archives/6156
 Windowsフォームに対するWPFの真の優位性とは
http://d.hatena.ne.jp/Yamaki/20140819/1408417355
 C# WPFのImageをFormで使う ～パフォーマンス比較～
http://jsdiy.web.fc2.com/software/wpftest/

31. ご清聴ありがとうございました
このスライドの内容はフィクションであり、
実在の人物及び団体とは 一切関係ありません。
また、登場するソースコードは使えるかもしれませんが、
バージョン違いなどによる動作は一切保証しません。
以上の注意点を確認いただき、
用法用量を守って正しくお使いください。