« 2007年11月 | トップページ | 2008年1月 »

[P13]WPF体制下において、デスクトップ・スタンドアロン・プログラムにXAMLをどの程度使うべきか

 私は自分のプログラムをWPF化するにあたって、言語コードのみ(私はC#)でいき、XAMLは、一切使用しないという基本方針になってきました。
 XAMLは、コントロールなどの配置やサイズのコーディングを Visual に補助するものとして、単にサイドで使うに過ぎず、結果はすべてコード化して、自分のライブラリーやアプリケーションを作ることにしました。
 Expression Blend は、不要、仮に使うとしても私には IDE のデザイナーで充分で、Expression Blend を使わなければならないような事情は私に関するかぎりないように思えます。
 まだ、Visual Studio 2008 の日本語版が出たばかりの段階ですが、英語版での実験の結果も含めて、こういう結論になってしまったのです。しかも、XAMLを使用する方向で検討してみた結果なのです。
 
 これは、世間の趨勢・ムードに背を向けています。但し、私は、デスクトップ・スタンドアロン・プログラムのみを手がけている高齢のアマチュア・プログラマーであり、WEB プログラミングは一切しません。プログラミング歴は長い(MSDOS 以前、PC8001以来)のですが、およそ、50個ほどの自己使用の事務処理プログラムを作って、自分で使っているだけに過ぎませんので、デザイナーとプログラマーが分離するわけではありません。そういうプログラミング環境下だけでの話です。

  実は、この記事は最初の記事の書き直しで、最初の記事は、XAML 不使用の可能性も残っていると断りながら、「軽く」XAMLを使っていくという方針のもので、XAML を使うとどういう問題があるのかということをゴタゴタ論じておりました。しかし、その後に私の XAML 離れがさらに決定的になり、冒頭に書いたようなことになりました。

前のように、XAML を使う問題点をゴタゴタ書くのは、微妙な問題に触れることになって大変でもあるし、また各人がそれなりに自分で試してそれなりの確証を得なければ、こういう結論にも至らないでしょうから、それはヤメにいたしました。
  ただ、次の二点だけ指摘しておきます。

 ① XAMLは、『抽象化できない、どこまでも具体的・固定的・静的なままのもの』
   であり、再利用・動的生成に適しないということ。
   その点でリソースという再利用法は用意されているにせよ、抽象化され動的で
   柔軟なDLL とは全く性格を異にする。 

 ② そのような XAMLを言語コードと『二元化した上で連携させるということの代償』
      は、いろいろなところで出てくるのだということ。

 このことを各人が自分の環境下で、どう評価し、どう結論づけるかの問題がある
 のではないか、と思います。

   [注] 私は、Windows 95 の頃から、Borland C++ Builder、2002年からは、
          Visual Studio を使ってきましたが、従来のデザイナーは、言語コードを
          生成するものでした。その限りで、コンパイルに入る段階では、
          既に言語コードに一元化されていました。
      しかし、デザイナーが言語コードと連動せず、XAMLと連携するWPF体制は、
     コンパイルに入る時点では、二元化しているのですから、似て非なる仕組みに
     なったのだと思います。
            私のように、XAMLを使わないということは、今まで相当に慣れ親しんだ
         デザイナーを使わない(使えない)ということになるので、寂しい気もします。
      しかし、それは最終的に言語コードのみにするということであって、サイドで
         デザイナーとXAMLを使いながらデザインをし、確定した数値・配置・色合い等を
         言語コードに取り込むというような使い方ができるわけなので、全くデザイナーを
         失うということではないと思います。

      ただ、コンテナコントロールの大まかな配置については、デザイナーでさえ
    『はがゆい』感じがし、それだけに特化すれば、自分でおおまかな配置をより
    手っ取り早く行う補助的なアプリケーションを先に作り、それを使いながら
    プログラムの書き換えに着手したほうが効率がいいと考え、MyUIDesigner と
    自分で名づけた配置プログラムを作成しました([P9]参照)。
         XAMLを使う場合にも、こういったものを御自分で作られると役に立つのでは
    ないかと思われます。

      そうでもしないと、Canvas を使わないコンテナ・コントロールの組み合わせと
         重ね合わせの作業は、内部に多数のコントロールがひしめき合っているような
         入力画面の場合(私の場合これが多数ある)、想像しただけでも気が
    重くなります。

 では、XAML を捨てたとして、言語コードだけでどう全体を組み立てていったらいいのでしょうか。この点についての現在の私の構想を書いておくことに致します。
 
まず、プロジェクトの中は、App.cs と Window1.cs のみになり、.xaml ファイルはなくなります。 
  
 App.cs 内は、こんな感じでしょうか。partial class にする必要はなくなります。
 
   public class App : Application
    {
      [STAThread]
        static void Main(string[] args)
        {
            new App().Run();
        }
        public App()
        {
            this.Startup += new StartupEventHandler(App_Startup);
        }

        void App_Startup(object sender, StartupEventArgs e)
        {
            Window1 win1 = new Window1();
            win1.Show();

        }
 
 Window1.cs の方は、やはり partial class ではない。

    public class Window1 : Window
    {
        public Window1()
        {
        // InitializeComponent();  不要になります。
        }     
    }

[注] class Window1 について、ちょうどXAMLで扱うユーザーインターフェースの部分
    を別ファイル(UI1.cs)にする、という扱い方もできる。この場合には、partial class
     にしておくことになるが、こうするとWindow1.cs の方がたいへんすっきりする。
    私は、基本的にこの方式を採用することにした。
 
   
問題は、ここから先です。WPF では、あらゆるところがツリー構造化されているように見受けられます。
そこで、XAML ファイルに代わりうる言語コードは次のようにすべきかな、と思っております。

最初にコントロールを生成するコード

  XAML で、最初に Label を作ったところに相当致します。
  必ず、parent を指定して、何らかのコンテナコントロールの中にあるかが決まる構造です。

  public class MonoControl
  {
      public MonoControl()
      {
      }
      
      Label Label_Mono(StackPanel parent, ・・一定の引数・・)
      {//StackPanel に貼り付けるとき使う
           Label lbl = Label_Mono_Common(・・・・);
           parent.Children.Add(lbl);
           return lbl; 
      }
      Label Label_Mono(DockPanel parent, ・・・・)
      {//DockPanel に貼り付けるとき使う
           Label lbl = Label_Mono_Common(・・・・);
           parent.Children.Add(lbl);
           return lbl; 
      }
      Label Label_Mono(Canvas parent, ・・・・)
      {////Canvas に貼り付けるとき使う
           Label lbl = Label_Mono_Common(・・・・);
           parent.Children.Add(lbl);
           return lbl; 
      }
      Label Label_Mono_Common(・・・・)
      {
          Label retlbl = new Label();
          ・・・・
          ・・・・
          return retlbl;
      } 
 
  }
   

  すべて(WPFに関する部分のすべて)を、この構造で統一して作っていけば、必ず Window から階層的に繋がってまいります。
  他方、作られた Label オブジェクトは、戻り値として、上位の構造に上げていき、 最終的な(最上位の)アプリケーションエリアにまで   持ち上げられるようにしてあります。

もちろん、中間層でより大きなかたまりになったときは、戻り値でなくても、上位構造に上げられる工夫をしておけばよいわけです。)
 そうすれば、最下層(実際には、自分のライブラリに置かれることになる)で作られた Label オブジェクトが最上位のアプリケーションの位置まで持ち上がります。 

というわけで、この構造で一貫しておけば、ツリー構造がうまく反映できるのではないでしょうか。

  MonoControl クラスの中には、例えば、TextBox も Button も、また、コンテナ・コントロールである StackPanel や DockPanel なども    この要領で、作成・追加していきます。
 
  そして、例えばこの上位に、StackPanel の中に Label と TextBox が横並びになるものを作っておこうとするなら   
 
  public class SetControl
  {
      public StackPanel pnl;
      public Label lbl;
      //メソッドの戻り値ではもどせないので、上部構造に上げられるように
      public TextBox txb;
      //メソッドの戻り値ではもどせないので、上部構造に上げられるように
      MonoControl monoControl;
          
      public SetControl()
      {
          monoControl = new MonoControl();
      }

      public StackPanel StackPanelwithLabelTextBox(Canvas parent, ・・・・・)
      {//Canvas に貼り付けるとき使う
        pnl = monoControl.Panel_Mono(parent, ・・・・・・);
        StackPanelLabelTextBox_Common(・・・・・・・);
        parent.Children.Add(pnl);
        return pnl;   
      }
    
      public StackPanel StackPanelwithLabelTextBox(DockPanel parent, ・・・・・)
      {//DockPanel に貼り付けるとき使う
        pnl = monoControl.Panel_Mono(parent, ・・・・・・);
        StackPanelLabelTextBox_Common(・・・・・・・);
        parent.Children.Add(pnl);
        return pnl;   
      }

      public void StackPanelwithLabelTextBox_Common(・・・・)
      {
        lbl = monoControl.Label_Mono(pnl, ・・・・・);
        txb = monoControl.TextBox_Mono(pnl, ・・・・);
      }
 
  }

 Grid については、表に利用するため、私は独立のクラスとし、 Column, Row を作り、内部にLabel や TextBox を配置するためのメソッドを持ったものに致しました。Grid の派生クラスにすべきか迷ったのですが、最終的にはそうしないで、ここに示した構造になるように作り上げました。
  もっとも、Grid は、すべきことがいろいろあるので、単なる配置用のものも
独立のクラスにしてあります。このあたりは、人それぞれの問題であるかもしれません。
中間層は、サイズが大きくなるので、通常は独立のクラスになるでしょう。


  このような構造に作っていった場合、これらを使用していく上位構造、最終的にはアプリケーションでは、トップダウンでコーディングすることになります。
    すなわち、Window の下にくるもの、そして更にその中に置かれるもの、という順序でコーディングすることになります。
  そして、XAML コードのように、自動的にツリー構造の繋がりができあがり、わかりやすいものになると思います。 

  私は、この構造で従来のライブラリとは別に、XAML 部分に相当するようなライブラリをもう一つ作り、上記のようなコードを作りあげつつあります。
  完成は、自分のアプリケーションの書き換えと平行させながら、内容を決めていくので、いつになるのかわかりません。
  いまのところ、これで挫折することはないだろうという見通しを持っております。

[P9]の記事内で書いておいたように、この構造で私の第一号WPFアプリケーションは、完成致しました。一応、満足しております。今はその段階です。

《後記》  第5号プログラムまで完成した段階での報告として
  単に5つというのではなく、これで50近くある私のアプリケーションに対する見通しが
 すべて立ったというか、基本的問題点は印刷まで含めて解決した段階(細部の問題
 だけは残っている)です。そのように、5つのアプリケーションを選びました。

  まずは、全体として順調です。
 
 XAML部分に相当するUI部分は、どのアプリケーションも似たような形になります
 から、2つ、3つ作てみると、いわれているように「複雑になる」などという感じは全く
 ありません。まとめ方の要領も、自分のスタイル・パターンができてきます。
 それができると、モデル・プロジェクトを作っておいて、新規作成はIDEのテンプレート
 から生成するのではなく、このモデル・プロジェクトをフォルダーごとコピーし、リネーム
 して使うことができますから、手間がたいへん省けるようになります。
  
  逆に、XAMLとの二元的な管理が、コード一本に一元化され、XAMLの時は、こう
 書いたけれど、コードではどうだっけ、というような負担からも解放され、
 かえって楽で、混乱しません。

  すべて、自分の DLL 相手ですから、動的生成も自在です。
 Grid など、XAML では使いたくもありませんが、DLL で Grid を生成する自分なりの
 Class を作って、Grid の行列数や幅・高さを動的に生成し、内部に必要なコントロール
 まで配置できるようにしておけば、Grid を気楽に使えるようにもなります。
 プロジェクトフォルダーごとコピーして、別の場所に移すのも簡単。
 全体的なプロジェクト名の変更も簡単。

  XAML などは、所詮プロパティを集めただけのものなのですから、言語コードで
 書けるようになっていれば、XAMLなどは簡単に理解していけます(その逆は、
 手間がかかる)。

 要するに、本文で書いておきましたように、XAMLと二元化した代償がすべてなく
 なり、相当の自由が戻ってまいります。


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
目次に戻る ・・・・ 左欄のカテゴリー 【パソコンの窓】 をクリック
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

| | コメント (0)

[P12]WPFアプリケーション:マウスでテキストボックスをクリックした場合のイベントハンドラーは?

Mouse で TextBox を Click(MouseDown) した場合、どの EventHandler でそのイベントをとらえたらいいのか。

 MSDNフォーラムに質問を出したところ、FC-Shiro さんという方が
解決して下さいました。

http://forums.microsoft.com/MSDN-JA/ShowPost.aspx?PostID=2593002&SiteID=7


一応、結論だけ書いておきます。

TextBox では、MouseDown イベントが使えない。
以下の方法で代用するそうです。

         [注]  MouseDownHandler の部分は、自由に命名できる。

《XAML》

  <TextBox  PreviewMouseDown="MouseDownHandler"/>

《C#》

  TextBox textBox = new TextBox();
  textBox.PreviewMouseDown += MouseDownHandler;

《イベントハンドラー》

   void MouseDownHandler(Object sender, RoutedEventArgs e)
   {
       //
   }

この点に関するマイクロソフトのドキュメント

     http://msdn2.microsoft.com/ja-jp/library/ms750580(vs.80).aspx

  [以上]

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
目次に戻る ・・・・ 左欄のカテゴリー 【パソコンの窓】 をクリック
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

| | コメント (0)

[P11]WPFアプリケーション:フォーカスの設定(取得)と移動

① フォーカスの設定(取得)

  textbox1.Focus();

    まず、以下を読む。
     http://msdn2.microsoft.com/ja-jp/library/ms754010.aspx

  Focus メソッド:
http://msdn2.microsoft.com/ja-jp/library/system.windows.uielement.focus.aspx   


② フォーカスの移動

            TraversalRequest request
                   = new TraversalRequest(FocusNavigationDirection.Down);
            
            UIElement elementWithFocus = (UIElement)Keyboard.FocusedElement;
            
            if (elementWithFocus != null)   {
                elementWithFocus.MoveFocus(request);
            }

  まず、以下を読む。
      http://msdn2.microsoft.com/ja-jp/library/aa969768.aspx

  MoveFocus メソッド:
    http://msdn2.microsoft.com/ja-jp/library/system.windows.uielement.movefocus.aspx

   TraversalRequest クラス
http://msdn2.microsoft.com/ja-jp/library/system.windows.input.traversalrequest(VS.80).aspx

   FocusNavigationDirection 列挙体
http://msdn2.microsoft.com/ja-jp/library/system.windows.input.focusnavigationdirection(VS.80).aspx


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
目次に戻る ・・・・ 左欄のカテゴリー 【パソコンの窓】 をクリック
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

| | コメント (0)

[P10] WPF 体制下における Application.DoEvents() メソッドの代替手段

WPF(Windows Presentation Foundation) アプリケーションでは、GDI 体制下の

System.Windows.Forms.Application クラスの DoEvents() メソッド
         [メッセージ キューに現在ある Windows メッセージをすべて処理する]

がなくなってしまいました。

その代替手段として、名前空間: System.Windows.Threading の、
Dispatcher.PushFrame メソッドを以下のようにして使うのだそうです。

C#

public void DoEvents()
{
    DispatcherFrame frame = new DispatcherFrame();
    Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background,
        new DispatcherOperationCallback(ExitFrames), frame);
    Dispatcher.PushFrame(frame);
}

public object ExitFrames(object f)
{
    ((DispatcherFrame)f).Continue = false;
   
    return null;
}

下のMSDN クラスライブラリのページにそのまま載っております。

http://msdn2.microsoft.com/ja-jp/library/system.windows.threading.dispatcher.pushframe(VS.80).aspx

なお、上記の引用コードでは修正済みですが、MSDN クラスライブラリのページにあるものは、new DispatcherOperationCallback(ExitFrames), frame); であるべきところ、記載ミスで (ExitFrame) => 最後の[s]が抜けていますので注意してください。

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
目次に戻る ・・・・ 左欄のカテゴリー 【パソコンの窓】 をクリック
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

| | コメント (0)

[P9]WPF:どうコンテナコントロールを使ったらいいものか?--私の一つの解 MyUIDesigner --

WPF(Windows Presentation Foundation)下では、GDI(Windows.Forms)の時と同じ名前のものでも、Control のコンテナ(入れ物)の性質・機能が変わってしまっており、それぞれが、厳密に性格づけられ、役割分担するように再構成されています。

        [注] 未整理の方は、以下のリンクで

     http://msdn2.microsoft.com/ja-jp/library/ms754152.aspx

     http://uchukamen.com/WPF/XAML-Panel/

唯一の絶対座標系は Canvas のみで、多くの場合は Panel 系のコントロール(コンテナコントロール)を使い、レンダリングと呼ばれる WPF の新方式の表示配置の仕方によって、UI(ユーザーインターフェース)を作成することになっています。
スクリーンサイズに応じて伸縮できない絶対座標系 Canvas は、印刷その他特殊な局面の使用に限定され、あまり推奨されていないようなことがどこかに書いてありました。

ただ、このレンダリングというのは、やってみると結構面倒な作業です。なかなか、思うところに思うように配置できません。たかが配置だけで、と思うと、腹さえ立ってきます。しかし、まあ、そこは始めたばかりなのだからと、抑えて(?)進みます。

実験はシンプルな道具立てで行うから何も気づきません。そして、実験も兼ねて取り組んだ私の一番簡単なアプリケーション(デスクトップ・スタンドアロン)はこれで完成してしまいました。

ヤッターと思いました。第1号 WPFプログラムです。
 MyCalc という名の足し算・引き算専用の電卓のような計算プログラム。電卓と違うのは、記録が残り、誤って打ち込んだかどうか突き合わせができて、間違ったところだけ訂正すれば、すべてが自動的に修正されるというもの。要するに打ち直しをしないで済むという便利さが売り物(買い手はつかないでしょうが)。

ところが、です。

ところが、こうして進んで、いろいろな自分のアプリケーションの書き換えに思いを馳せていくと、ハタと困ってしまいました。

私の事務処理プログラムの中には、多数のLabel + TextBox, 複数の ListBox, RadioButton を内蔵する複数の GroupBox が、1つのフォーム中にところ狭しとギシギシと詰め込んであるものが多いのです。それでこそ、実生活の役に立つというものです。1レコードのデータ入力にそれだけのものが必要なのです。

こんなの、Canvasを使わないで、どうやって配置しろというのでしょうか。コンテナ・コントロールの中に、コンテナ・コントロールを入れて、またその中にコンテナ・コントロールを入れて、そしてやっと目的のコントロールをいれるのけ!!!そんなの、コンテナだらけや。一見しただけで楽(らく)そうではないから、相当複雑な積み重ねがいるし、それだけ相互間の配置関係の調整もたいへんそう。配置だけにそんなにエネルギーかけるのはまっぴら御免、と言いたくなります。

我慢できる程度の重なりならそれでいいでしょう。でも、限度を超えたら、結局 Canvas なのでしょうか。たくさんのコンテナ重ねて、順番考えて、1個1個 HorozontalAlignment が Left だとか、DockPanel.Dock が Bottomとかやって、Margin をどうこうしないとうまくないなんてやってられるか、と一方ではいいたくなります。絶対座標なら一発でかたづくものを「大味で鈍い?」配置道具をいくつも重ね合わせて一件落着するまでの道のりがまた遠いのです。こんな形で、これから50近くもある自分のアプリケーションを書き換えていくのかと思うと気が滅入ってきます。

  そんなことを悩んでいたら、一つアイディアが飛び出しました。そうだ。自分で、大まかな配置用デザイナーのプログラムを先に作って、それを使いながら、書き換えをしていこうと。
 
  それで、WPF 第2号プログラムは、この MyUIDesigner になりました。
他の方の御参考、乃至お役にたつこともあるかと思い、アイディアを紹介しておきます。

二つの Window を使います。メイン・ウィンドウで簡単に配置情報を入力し、サブ・ウインドウで実際に画面を描いてみるというものです。

メイン・ウィンドウには ListBox (必要に応じて TextBox)をたくさん作って、ListBox の一つずつに、コントロールの種類、親要素、Width、Aligment などの情報を Click するだけで選べるようにします。
  そして、その全 ListBox で選んだ情報を1レコードとしてファイルに保存できるようにします。例えば、Window に DockPanel を配置する場合、DockPanel の全レンダリング情報が1レコードです。
  そして、ファイルに保存される順番がそのままプログラミングを進めていく場合の順番(階層構造の順番)ということになります。
 
  メイン・ウィンドウで作られた情報をもとに、それをサブ・ウィンドウに描けるようにするのが、サブ・ウィンドウのプログラミングになります。私は、StackPanel, DockPanel, Grid, Canvas のみを使うという前提で、この4種類を必要な数だけ作りだし、種類ごとに『そのオブジェクトを配列で受け取り』、メイン・ウィンドウの情報をこのオブジェクト配列に結びつける形にしてみました。
 
  ちょうど、それが今完成したところです。一応、テスト段階では充分使えるという感じです。たいへん、快適です。一部、 TextBox からの入力と、後は ListBox からの選択だけで、Window がすぐに描けます。細かいところは、コーディングでいくらでも対処できますから、大まかなところがこれで解決すれば充分です。これで、よし、ということになったら、その情報でコーディングすれば簡単に自分の求めるユーザーインターフェース画面の骨格が出来上がってしまい、失敗がありません。これから、書き換えに入る段階なので、それ以上のコメントは現在できません。
   
私は、[P13] で書いていますように、XAMLを使わずに言語コード一本で組み立てる方針が既に決まっておりますが、XAML を使う場合でもこのようなプログラムは役立つのではないかと思われます。
最初に作ると、それがレンダリング関係の勉強にもなり、その結果は今後のプログラミングを楽にしますから、一挙両得です。 

[後記] 
   WPF第3号プログラム(電話帳)が完成した段階で、コンテナコントロールの積み重ねの中間段階から終盤段階にかけて、意識的に Grid を使った整理の仕方を追求すると、StackPanel の積み重ねを減らせることがわかりました。そして、Grid の一つのセル内にStackPanel を配置し、その中に Label や TextBox を配置する、というところまで発展していきます。Grid の中に RadioButton を配置するのが有効な場合もあります。
  ただ、手間のかかる Grid の作成は、そのための独立のクラスを自分で用意し、行列それぞれが可変長の長さであるものを自由に簡単に作れるように準備しておかないと作業が大変です。
  私は、この段階で最初の MyUIDesiner に少し手を加え、セル内部にもコンテナコントロールを配置できるようにして精緻化致しました。

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
目次に戻る ・・・・ 左欄のカテゴリー 【パソコンの窓】 をクリック
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

| | コメント (0)

[P8]WPF 体制下において、ImeMode を切り替える方法

Windows の描画機構が、GDI から WPF(Windows Presentation Foundation)に変わったのに伴い、IME モードの切り替え方(半角・全角の切り替え方)が変わりました。
GDI 下では、TextBox などの入力コントロールのプロパティ ImeMode で切り替えましたが、 WPF 下ではコントロールから独立した一個のクラス( InputMethod クラス )になっております。

[C#]
using System.Windows.Input;

InputMethod.Current.ImeState = InputMethodState.On;
InputMethod.Current.ImeState = InputMethodState.Off;

これだけで、切り替わります。いづれ、当たり前のことになるのでしょうが、移行時には戸惑います。

なお、特に入力時の瞬間での切り替えを厳密にしたければ、

   private void textBox1_GotFocus(object sender, RoutedEventArgs e)
   {
   }

などの当該コントロールの何らかのイベントハンドラー内に、上記コードを書けばよいでしょうが、そういう手間をかける必要がない場合もあると思います。

便宜のため、以下に整理しておきます。

[ InputMethod クラス ]

名前空間: System.Windows.Input
アセンブリ: PresentationCore (presentationcore.dll 内)

MSDN ライブラリ内の該当URL
http://msdn2.microsoft.com/ja-jp/library/system.windows.input.inputmethod.aspx

[ InputMethodState 列挙体 ]

メンバ   { DoNotCare, Off, On }

名前空間・アセンブリ ・・・・同上

MSDN ライブラリ内の該当URL
http://msdn2.microsoft.com/ja-jp/library/system.windows.input.inputmethodstate.aspx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
目次に戻る ・・・・ 左欄のカテゴリー 【パソコンの窓】 をクリック
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

| | コメント (0)

[P7]クラスライブラリ(DLL)作成にあたって、XAMLを使う方法(Visual Studio 2008 IDE)

いずれ当たり前のことになるのでしょうが、Visual Studio 2008 IDE で、『新規プロジェクト』のクラスライブラリのテンプレートを使って DLL を作成しようとした場合、WPF アプリケーションのようにデザイナーが表示されず、『一瞬 XAML を使うにはどうしたらいいのか』が問題になります。

この問題は、かなり危うい要素を含んでおります。

以下のようにすれば、一応使えるようにはなります。
(C# の例で記述します。VB の場合は、.cs を .vb に置き換えて下さい。)

① まず準備段階として、テンプレートからWPF アプリケーションのテンプレートで
  新規プロジェクトを作成し、ここでデザイナーを使ってXAMLファイルを作ってしま
  います。

② 出来上がったXAML関係ファイル(***.xaml と ***.xaml.cs)を、クラスライブラリ
  (DLL)のプロジェクトの該当フォルダーにコピーする。

     コピー後、ファイル名を変更したり(.xaml と .xaml.cs は、その前の部分を
  同名にしておくこと)、テキストエディターで内容を整えておけば、後の作業が
  円滑になります。

③ クラスライブラリ(DLL)のプロジェクトを立ち上げたIDEのソルーション・イックス
  プローラから、『 既存 Item の追加 』 として ***.xaml のみをプロジェクトに
  取り込みます(***.xaml.cs の方は、それにともなって自動的に取り込まれる)。
   
    [ 注意 ]
              『 既存 Item の追加 』 として取り込もうとすると、
           デフォルト(既定)では、***.xaml.cs だけしか表示されませんので、
           右にあるコンボボックスで、表示ファイルの拡張子を選び直してから、
           ***.xaml を選択し、取り込むこと。
  
  (一旦、XAML ファイルが取り込まれれば、デザイナーが表示されます。)

④ 必要に応じ、***.xaml と ***.xaml.cs のコーディングを手作業で修正して、
  クラスライブラリ(DLL)のプロジェクト全体と調和させる。

[要注意事項]

  以上で、一応 XAML を使って、DLL を構築することができるかに見えます。
 しかし、私が実験した限りでは、この方法は機能的に色々な限界に直面することになると思われます。限界に直面するから、使用の仕方を制限すると、そもそもライブラリに置いて使おうという目的が達成されず、たいへん中途半端な結果に終わります。
私が見極めた限りでは、XAMLをクラスライブラリ構築に際して使うということは、実際上全く有効性・有用性がない、と思われます。


 他方、WPFでは、XAMLの再利用方法として、リソースという仕組みが用意されて
 います。
従って、Microsoft としては、クラスライブラリ作成時にXAMLを使うということは問題にしていないように見受けられます。翻って考えてみれば、XAMLは、デザイナーのために用意された仕組みであって、それをプログラマーがDLLの構築に使おうというのは、
確かに筋が違います。

  なお、本稿を書いた時点では、私は『軽く』XAMLを使っていくという方針でしたが、
 その後XAML離れがさらに進み、[P13] に書いていますように、一切を言語コードで
 書き上げる方針に転換致しました。

 従って、この問題を最終的には見極めておりません。
 但し、その背景には、クラスライブラリ作成にXAMLを使うことにはかなり限界があるということが、一つの要因になっているということを付け加えておきます。

[追加事項]

 最初の時点では、一瞬XAML を DLL の構築のために使えないか、という発想が浮かぶのですが、XAML は根本的に DLL にはなじまない性格を持っています。
 DLL は、何らかの意味で Application 内にある共通の要素を 『抽象化して』 取り出し、再利用を図るものです。
  ところが、XAML には、この抽象化の要素が全く欠けております。どこまでも 『具体的な数値などのデータのまま』 であります。例えば、早い話、変数が使えません。

その意味で、そもそも、XAML と DLL は、性格的になじまないものであって
、Microsoft が予定するリソースという仕組みを使って XAML の再利用をはかるとしても、それは DLL を用いたものとは性格が異なり、具体性という枠から脱却できないものとして、柔軟性や動的性格に欠けたものに過ぎないのだと思われます。

 極論過ぎるかもしれませんが、私の出した結論は
XAMLはデザイナーが使うべき道具であって、プログラマーが使うべき道具ではないということになります。
ちなみに、先に述べました私の「P13」での、一切を言語コードで書き上げるという基本方針は
、《私のプログラミング環境下での》この見極めから出てきたものです。

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
目次に戻る ・・・・ 左欄のカテゴリー 【パソコンの窓】 をクリック
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

| | コメント (0)

« 2007年11月 | トップページ | 2008年1月 »