泥庭

2011年4月3日

アプリケーション管理の概要 – アプリケーションの有効期間（前編）

Filed under: .NET, WPF — タグ: , , — yone64 @ 11:51 午後

さてすっかり間が開いてしまいましたが、WPFでMSDNの続きです。間が開いたので下に一覧を載せておきます。ってかまだまだじゃねぇか。

でも、アプリケーションの有効期間って長いんですよね。ざっとこんな感じ

まあサクサク行きましょう。

スプラッシュスクリーン
スプラッシュスクリーンの説明は、例によってWikipediaに譲ります。
.NETでスプラッシュスクリーン（何度も出てくると長いな）といえば、VB.NETだと思っていたのですが(@IT)、←C#にはなかった。
WPFでは表示出来るようです。 でも、その追加方法が若干特殊。詳しくは→http://msdn.microsoft.com/ja-jp/library/cc656886.aspx
※ 1プロジェクトに複数スプラッシュスクリーンが設定されているとコンパイルエラーとなります。どの画像がスプラッシュスクリーンに設定されているかは、1画像ずつビルドアクションを確認するか、csprojファイルを直接テキストエディターで確認するしかないようです。

で、そのスプラッシュスクリーンがいつまで表示されているかというと、アプリケーションの最初のウインドウのContentRenderedが終わる前までは、表示されているようです。なので、WindowクラスのLoadedやContentRenderdで時間のかかる処理を行うと、スプラッシュスクリーンが表示されているままWindowも表示されるという状態になります。

なお、スプラッシュスクリーンを追加すると、次のようにSplashScreenクラスを利用したコードが追加されます。

/// <summary>
/// Application Entry Point.
/// </summary>
[System.STAThreadAttribute()]
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public static void Main() {
    SplashScreen splashScreen = new SplashScreen("desert.jpg");
    splashScreen.Show(true);
    WpfApplication3.App app = new WpfApplication3.App();
    app.InitializeComponent();
    app.Run();
}





アプリケーションの起動・ユーザーインターフェースの表示・コマンドライン引数の処理       
これらは、Application.Startupイベントに関する記載です。     
Startupイベントは、ApplicationオブジェクトのRunメソッドが呼び出されると発生します。イベント引数にはコマンドライン引数が渡ってくるので、ココで処理することになります。また、MainWinowを作成することのできる場所の一つです。


もう一つは、StartupUriを利用する方法。通常VisualStudioでプロジェクトを作成するとこちらの方法で記述されます。


<Application x:Class="WpfApplication3.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             StartupUri="MainWindow.xaml" >



ただし、StartupUriを利用してWindowを作成した場合、StartupイベントではそのWindowのインスタンスにアクセスすることが出来ません。    
ですから、MainWindowのインスタンスにゴニョゴニョしたい場合は、StartUpで初期化、特に何もする必要がない場合はStartupUriで記載するのが良さそうです。


アプリケーションのアクティブ化および非アクティブ化       
アプリケーションがアクティブになったときおよび非アクティブになった場合に、イベントが発生します。     
MSDNによると、




アクティブになったときとは、


    

  • 

    起動され、Window を表示した。
    

    • 

  • 

    ユーザーがそのアプリケーションの Window を選択して別のアプリケーションから切り替えた。
    

    • 



非アクティブになったときとは、


    

  • 

    ユーザーが現在のアプリケーションから別のアプリケーションに切り替えた。
    

    • 

  • 

    アプリケーションがシャットダウンされた。
    

    • 





とのことです。ただし、「起動され、Windowを表示した」場合のイベントは、スプラッシュスクリーンを設定すると発生しないようです。    
（バグっぽいのでとりあえずConnectにあげておきました。）




長いのでとりあえず、前編としました。。

2011年2月22日

アプリケーション管理の概要 – 現在のアプリケーションの取得

Filed under: .NET, WPF — タグ: , , — yone64 @ 10:30 午後

第4回。現在のアプリケーションの取得。

Application.Currentを利用して、アプリケーション全体で共有されるApplicationクラスのインスタンスを取得することが出来ます。
（参照）方法 : 現在のアプリケーション オブジェクトを取得する

Application クラスのサービスはアプリケーション全体で共有されるため、Application クラスのインスタンスとして AppDomain につき 1 つだけ指定できます。

Current は、Application クラスのインスタンスへの参照を返します。 Application 派生クラスへの参照が必要な場合、Current プロパティの値を、次の例に示すようにキャストしなければなりません。

// Get strongly-typed current application
App app = (App)App.Current;

Applicationクラスはシングルトンであり、一つのAppDomain内で複数回初期化すると、「同じ AppDomain 内で、複数の System.Windows.Application インスタンスを作成することはできません。」という内容のInvalidOperationExceptionが発生します。ただし、Currentプロパティーへのアクセス時にApplicationクラスが初期化されるわけではなく、未初期化の場合はCurrentプロパティーはNullを返します。
また、戻り値の型がApplication型であるため、必要に応じキャストが発生します。ただし、デザイン時にはAppクラスが取得できるわけではなく、デザイン環境により異なるクラスが取得できます。

そのため、デザイナから呼び出されるコードでは、CurrentプロパティーのNullチェックおよび型チェックはしておきましょう。

VisualStudio2010でデザイン時のApplication.Currentの型（左上）と実行時の型（右下）
image

Expression Blendでのデザイン時
image

（参照）WPF および Silverlight デザイナー読み込みエラーのトラブルシューティング – デザイン時のコードの作成

2011年2月20日

アプリケーション管理の概要 – アプリケーション定義

Filed under: .NET, WPF — タグ: , , — yone64 @ 12:10 午前

サクサク行きましょう。第3回

WPF アプリケーション定義は Application の派生クラスで、特別な Microsoft ビルド エンジン (MSBuild) 設定を使用して構成します。

http://msdn.microsoft.com/ja-jp/library/ms743714.aspx#The_Application_Definition

というわけで、WPFアプリケーションプロジェクトまたはWPF ブラウザー アプリケーション プロジェクトには、デフォルトでApplicationクラスを継承したAppクラスのマークアップと分離コードが含まれています。

image

「App.xaml」（マークアップ）と「App.xaml.cs」（分離コード）がそれですね。内容は、MSDNにあるとおりです。
また、App.xamlはアプリケーション定義としてcsprojファイル内でApplicationDefinitionタグで指定がなされています。 

<ApplicationDefinition Include="App.xaml">
  <Generator>MSBuild:Compile</Generator>
  <SubType>Designer</SubType>
</ApplicationDefinition>

この設定により、ビルド時にMSBuildでコードが自動生成されます。
自動生成されるコードはソリューションエクスプローラーで、すべてのファイルを表示を選択することにより確認できます。（下図のApp.g.i.csがそれに当たります。）

image

作成されているコードは、以下の通りです。Application Entry Pointとして、Mainメソッドが作成されているのが確認できます。

/// <summary>
/// App
/// </summary>
[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")]
public partial class App : System.Windows.Application {
    
    /// <summary>
    /// InitializeComponent
    /// </summary>
    [System.Diagnostics.DebuggerNonUserCodeAttribute()]
    public void InitializeComponent() {
        
        #line 4 "..\..\..\App.xaml"
        this.StartupUri = new System.Uri("MainWindow.xaml", System.UriKind.Relative);
        
        #line default
        #line hidden
    }
    
    /// <summary>
    /// Application Entry Point.
    /// </summary>
    [System.STAThreadAttribute()]
    [System.Diagnostics.DebuggerNonUserCodeAttribute()]
    public static void Main() {
        WpfApplication2.App app = new WpfApplication2.App();
        app.InitializeComponent();
        app.Run();
    }
}

2011年2月19日

アプリケーション管理の概要 – Application クラス

Filed under: .NET, WPF — タグ: , , — yone64 @ 12:24 午前

MSDNを読もう第2回です。（そんな名前だったっけ？）

というわけで、Application Development Overviewのアプリケーション管理が、「詳細については、「アプリケーション管理の概要」を参照してください。」と締めくくっているため、今回はアプリケーションの管理の概要です。

かなり始まったばかりだけど、今ココ↓。

image

で、ココで書かれていることは、アプリケーションごとに固有かつアプリケーション内で共有する項目はApplicationクラスにカプセル化されて提供されていますよ。ということ。具体的には以下の通りらしい。

  • 共通アプリケーション インフラストラクチャを作成し、管理する。

  • アプリケーションの有効期間を追跡し、これと対話する。

  • コマンド ライン パラメーターを取得し、処理する。

  • アプリケーション スコープのプロパティとリソースを共有する。

  • 未処理の例外を検出し、これに応答する。

  • 終了コードを返す。

  • スタンドアロン アプリケーションのウィンドウを管理する (「WPF ウィンドウの概要」を参照)。

  • ナビゲーションを追跡し、管理する (「ナビゲーションの概要」を参照)。

http://msdn.microsoft.com/ja-jp/library/ms743714.aspx#The_Application_Class

各個別内容については、次以降の項目で解説されているので、ココでは割愛。今はふ～ん程度の認識にしておこう。

じゃあ、全く内容がないけど今回はこれで終わりかな。

 

2011年2月18日

Application Development Overview

Filed under: .NET, WPF — タグ: , , — yone64 @ 1:26 午前

WPFを使い始めて早3ヶ月ぐらい。何となくわかってきた気もするがまだまだ全然わかんない箇所も多い。
そこで、改めてMSDNを見直すことにしてみました。せっかくなので過程を残していこうかと。

Windows Presentation Foundation

http://msdn.microsoft.com/ja-jp/library/ms754130.aspx

概要（WPF）はいいよね。ってことで、Application Developmentから。

Application Development Overview

Windows Presentation Foundation (WPF) は、次の種類のアプリケーションの作成をサポートします。

  • スタンドアロン アプリケーション (クライアント コンピューターにインストールし、そこから実行できる実行可能アセンブリとしてビルドされた従来スタイルの Windows アプリケーション)。

  • XAML ブラウザー アプリケーション (XBAP) (Windows Internet Explorer によってホストされる閲覧可能な実行可能アセンブリとしてビルドされた移動可能ページで構成されるアプリケーション)。

  • カスタム コントロール ライブラリ (再利用可能なコントロールを含む非実行可能アセンブリ)。

  • クラス ライブラリ (再利用可能なクラスを含む非実行可能アセンブリ)。

http://msdn.microsoft.com/ja-jp/library/bb613549.aspx

つまり、下図で四角で囲んだ部分が関係あるわけですね。
image
WPFアプリケーションは、スタンドアロンアプリケーション。
WPFブラウザーアプリケーションは、XAMLブラウザーアプリケーション。（そういえば、今はブラウザーなのね）。
WPFカスタムコントロールライブラリとWPFユーザーコントロールライブラリ（もだよね）は、カスタムコントロールライブラリ。
クラスライブラリは、クラスライブラリ。といったところでしょうか。

せっかくなので各プロジェクトテンプレートの違いも見てみましょう。
まず実行可能アセンブリである、WPFアプリケーションとWPFブラウザーアプリケーション。
#XBAPってあまり聞かないんですが、世間ではどの程度使われているんでしょうか？やっぱりSilverlightの方がメジャーですよね。
(その1)プロジェクトに含まれるファイルの違い 左がWPFアプリケーション、右がWPFブラウザーアプリケーション
image
WPFアプリケーションでは、MainWindow.xaml。WPFブラウザーアプリケーションではPage1.xamlが含まれています。
WindowsアプリとWeb（ブラウザホスト）アプリの違いですね。
また、WPFブラウザーアプリケーションには、ブラウザ上で動作させるために必要なのでしょう、pfxファイルが含まれています。
(その２)csprojの違い
csproj内の設定項目を比較してみました。
WPFブラウザーアプリケーションは、ブラウザ内で動作するためにか、いくつか設定が増えていますね。

スタンドアロン XBAP
Configuration ○ ○
Platform ○ ○
ProductVersion ○ ×
SchemaVersion ○ ○
ProjectGuid ○ ○
OutputType ○ ○
AppDesignerFolder ○ ○
RootNamespace ○ ○
AssemblyName ○ ○
TargetFrameworkVersion ○ ○
TargetFrameworkProfile ○ ○
FileAlignment ○ ○
ProjectTypeGuids ○ ○
WarningLevel ○ ○
EnableSecurityDebugging × ○
Install × ○
StartAction × ○
HostInBrowser × ○
BootstrapperEnabled × ○
TargetZone × ○
GenerateManifests × ○
SignManifests × ○

WPFブラウザーアプリケーションのcsprojファイルの設定については、
「方法: WPF XAML ブラウザー アプリケーションのサンプル プロジェクト ファイルを作成する」にも、詳しく載っていました。
ただし、StartActionがリンク先ページと実際に作成されたデータで異なってます。なぜ～

さて次は、非実行可能アセンブリのWPFカスタムコントロールライブラリとWPFユーザコントロールライブラリとクラスライブラリの比較。
(その1)プロジェクトに含まれるファイルの違い 左からWPFカスタムコントロールライブラリ・WPFユーザーコントロールライブラリ・クラスライブラリ
image
WPFカスタムコントロールライブラリには、カスタムコントロールとGeneric.xamlが含まれています。
WPFユーザーコントロールライブラリには、ユーザーコントロールが含まれています。
クラスライブラリには、通常のクラスが含まれています。
そのままですね。
(その２)csprojの違い

カスタム
コントロール		 ユーザー
コントロール		 クラス
ライブラリ
Configuration ○ ○ ○
Platform ○ ○ ○
ProductVersion ○ ○ ○
SchemaVersion ○ ○ ○
ProjectGuid ○ ○ ○
OutputType ○ ○ ○
AppDesignerFolder ○ ○ ○
RootNamespace ○ ○ ○
AssemblyName ○ ○ ○
TargetFrameworkVersion ○ ○ ○
TargetFrameworkProfile ○ ○ ×
FileAlignment ○ ○ ○
ProjectTypeGuids ○ ○ ×
WarningLevel ○ ○ ×

WPFカスタムコントロールライブラリとWPFユーザコントロールライブラリには設定項目に違いはありません。
対して、クラスライブラリは一部設定項目が少ないです。中でも一番大きな違いは、ProjectTypeGuidsですね。
（ProjectTypeGuidsについてはhttp://www.mztools.com/Articles/2008/MZ2008017.aspxがくわしいです。）
WPFカスタムコントロールライブラリとWPFユーザコントロールライブラリには、WPFを表す{60DC8134-EBA5-43B8-BCC9-BB4BC16C2548}と、Windows (C#)を表す{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}が設定されていました。
この違いがどこに現れるかというと、プロジェクトの追加メニューの中身が変わるようです。（そのほかにもあるかもしれません。）
image
ProjectTypeGuidsでWPFが指定されていないクラスライブラリでは、追加メニューで表示される項目がWinFormの項目になっています。

とりあえず今回はここまで。最初からこの量とか、絶対このペースでは続かないなきっと。

WordPress.com Blog.