.NET Framework 2.x

レーティングをお願いします。

はなおかじった — Tue, 29 Apr 2008 22:24:00 GMT

VS2005 SP1をマージしたものを希望

ライブラリや OS 機能の追加、変更、削除を RSS として配信して欲しい。

VB 使うな、開発者なら。

はなおかじった — Wed, 02 Apr 2008 22:40:00 GMT

せめて、Option Strict On にしてくれ。。。

件名：join でフリーズ（Insider.NET 会議室）より：

コードはこんな感じです。


class TestA
    dim obj as object
    public sub new()
        obj = new object()
    end sub
    public sub main()
        dim t as thread
        t = new system.threading.thread(new system.threading.threadstart(address of do))
        t.start()
        t.join()
    end sub
    public sub do()
        obj.start()
    end sub
enc class

件名：Validatingでは（Insider.NET 会議室）より：


Private Sub txtTCD_Validating(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles txtTCD.Validating
    Dim blnSUTI As Boolean
    Dim sb As New StringBuilder
    '*****
    If ActiveControl Is sender OrElse ActiveControl.CausesValidation = False OrElse sender.Text.Length = 0 Then
        Exit Sub
    End If
    '*** 入力ﾁｪｯｸ **************
    blnSUTI = Int32.TryParse(txtTCD.Text, mlngKEYTCD)
    If Trim(sender.Text).Length = 0 OrElse mlngKEYTCD = 0 Then
        MessageBox.Show("得意先を正しく入力して下さい", _
        Me.Text, MessageBoxButtons.OK, MessageBoxIcon.Exclamation)
        e.Cancel = True
        Exit Sub
    End If
    '*** ﾃﾞｰﾀ取得 **************
    Call mData()
    '*** ﾃﾞｰﾀ表示 **************
    Call mDisplay()
End Sub
'***
Private Sub 索引ﾎﾞﾀﾝｸﾘｯｸ
    Dim frmSAKUIN = New frmSAKUIN
    '*****
    If frmSAKUIN .ShowDialog = Windows.Forms.DialogResult.OK Then
        txtTCD.Text = frmSAKUIN .pTCD
        Call txtTCD_Validating(Nothing, Nothing)
    End If
    '*****
    frmAEIGS020.Dispose()
End Sub

勘弁してくれ。。。

上の方。obj は Object なので、start メソッドを持っていません。Strict Off にしているから実行時まで「start メソッドがあるかどうか」が延期され、、、って、おい！これ、なに？まさか、Thread.Start をしているとか？延々と自己呼び出しをやってんじゃないの？…StackOverflow で落ちるか？何にしても、動かないコードを出して「これが動かない」といわれても、そりゃ、動きませんよ、と。

下の方。sender.Text って、そりゃないよ。。。きっと、On Error Resume Next とかも指定してあるに違いない。Sender に Nothing にして呼び出して、その中のプロパティを呼ぼうとしたら、そりゃ、落ちるよ。

開発者なら。コンピュータと対話をする人なら。もっと、自分がコンピュータに対して何をお願いしようとしているか、自覚をしてください。

Windows Form：警告の表示

はなおかじった — Sat, 15 Dec 2007 22:06:00 GMT

件名：[VB2005] Validating イベント内で MsgBox を使えないジレンマ（Insider.NET 会議室）より：

>項目ごとにダイアログが出るとうっとうしいと苦情を言うユーザー

　項目毎にダイアログを出せ、というですよ
　たとえば、0～100 の範囲で入力しないといけない場合に、範囲外は「0～100の範囲で入力してくださいよ！」的なダイアログ（e.Cancel = True）を出せ、というですよ。

　更に80以上だったら「え？本当に80以上なの、すごいね！」みたいなダイアログ（e.Cancel = False）で御節介を焼いて欲しいそうな。

なるほどねぇ。。。

入力中に、ダイアログでメッセージを表示するのは、基本的に賛成できません。入力の流れを妨げるからです。よくある質問で、「Enter キーでフォーカスを移動させるには？」というのは、これに似た理由ですね。[Tab] キーはテンキーにはありませんので、手の移動が大きい＝入力の流れが妨げられる、と。この場合、Windows 標準のキー操作と衝突を起こすわけですが、どちらかというと、流れを妨げる方が大きな問題となるでしょう。フォーカス移動を「テンキーの [Enter] キーのみ」に絞れるなら、その方がいいとも思いますけど。

あるいは、わかってやっている場合もあります。例えば、伝票入力です。伝票はすでにどこかで作られていて、それをコンピュータに入力するのかもしれません。このとき、エラーはともかく、警告で入力の流れを妨げられると、ユーザはイライラするでしょう。特に、公共事業などではデータの入力を業者が行う場合があります。業者さんは指示されたとおりに入力するのが仕事なので、指示元のデータの正誤については責任がありません。このとき、指示元のデータと違うことを指摘するならともかく、入力値が正常な範囲でありながら入力の流れを阻害するような動作は、集中力を欠かせることになります。

特に、発注者と使用者が同じでない場合は、注意する必要があります。システム課などが業務の流れを知らず、「こうしてあればいいだろう」「こう使って欲しい」と思って発注しても、実際に使う場面にそぐわなければ、使われないシステムの仲間入りをする可能性が高くなります。

と、だめだめ言っていてもなんなので、提案です。

ToolTip を使ってみました。エラーメッセージは、ErrorProvider を使いました。

Visual Studio 2005 にて、Windows アプリケーションを作成します。
Form に、TextBox を2つ置きます。（ひとつは、フォーカスを遷移させるためだけのもの）
ToolTip と ErrorProvider も置きます。
ToolTip の、ToolTipTitle プロパティに、「警告」と入力します。また、IsBaloon プロパティを True にしておきましょう。ただの ToolTip だと、どこのコントロールに対して表示されたのかわかりにくいので。
TextBox1 にフォーカスし、プロパティウインドウで稲妻ボタンをクリックします。Validating イベントをダブルクリックします。
できたイベントハンドラに、後述のコードを書きます。
さて、実行してみましょう。

Validating コードの例:
private void textBox1_Validating(object sender, CancelEventArgs e) {
    Int32   chk;
    errorProvider1.Clear();
    toolTip1.Hide(textBox1);
    if (Int32.TryParse(textBox1.Text, out chk) == false || (chk > 100 || chk < 0)) {
        e.Cancel = true;
        errorProvider1.SetError(textBox1, "0以上100以下の数値を入力してください。");
    } else {
        if (chk >= 80) {
            //　see: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98281
            toolTip1.Show("", textBox1);
            toolTip1.Show("80以上です。本当にいいですか？", textBox1);
        }
        e.Cancel = false;
    }
}

ErrorProvider は、規定では設定したコントロールの右側に、Icon プロパティで指定したアイコンを表示します。ここで指定したアイコンが表示できるだけの幅を、コントロールの右側に確保しておく必要があります。う～ん、ErrorProvider に、「ベルを鳴らす」機能があれば良かったのに．．．

toolTip1.Show メソッドを2つ並べて書いているのは、修正されていないバグのためです。こうしていても、たまに表示されるツールチップの位置がずれます。

表示されたツールチップを消すためには、フォーカスを他のフォームに移してやる必要があります。ツールチップをクリックしてもいいです。

ツールチップが表示された状態で、フォームを動かすと、ツールチップが付いてきません。その後、ツールチップにフォーカスを移してツールチップを消し、もう一度ツールチップが表示されるような操作をすると、表示される場所がずれますorz あはは。。。バグ見つけちゃったよ。

Validating イベントではこんな感じにしておいて、登録のアクションで、エラーなら登録させない。警告なら登録する、しないを選べるようにしておく。そんな感じかな。でも、ToolTip のバグのおかげで、使いにくいやorz

VB マイグレーション ByRef と ByVal - その２

はなおかじった — Thu, 31 May 2007 22:28:00 GMT

参照型については刈歩菜良さんに振ったので、参照渡しと値渡しを行きましょう。

ByRef, ByVal で渡したプロシージャ内で、変数そのものを書き換えた場合、ByRef と ByVal がどのような結果を返すか、です。実行結果はどのようになるでしょうか。

その前にですね、この前のコードを、C++ で書いてみます。C++/CLI でも Managed C++ でもない、C++ です。Visual Studio 2003 のプロジェクトの追加で、「C++ コンソールアプリケーション」を選択しました。

#include "stdafx.h"
#include <iostream>

class HogeClass {
public:
    int Value;
    HogeClass() {
        Value = 0;
    };
};
void ByValFunc(HogeClass hage);
void ByRefFunc(HogeClass* hage);

int _tmain(int argc, _TCHAR* argv[])
{
    HogeClass hoge1;

    hoge1.Value = 1;
    std::cout << hoge1.Value;  // [A]

    ByValFunc1(hoge1);
    std::cout << hoge1.Value;  // [B]

    ByRefFunc1(&hoge1);
    std::cout << hoge1.Value;  // [C]
}

void ByValFunc1(HogeClass hage)
{
    hage.Value = 2;
    //hage = new HogeClass();    // [イ]
    //hage.Value = 3;
}

void ByRefFunc1(HogeClass* hage)
{
    hage->Value = 4;
    hage = new HogeClass();
    hage->Value = 5;
}

なんと、[イ]のところで、コンパイルエラーが出ます。ということで、“全く同じ”ではないのですが、実行してみます。

結果は、114 です。

やっとスタート地点だよ。。。

「値渡し」は、引数「の値」を渡します。この場合、新しい HogeClass の為にメモリが確保され、全く同じ内容になるようにコピーされたものが、ByValFunc の hage になります。
hage は hoge のコピーなので、ByValFunc 関数内で変更した内容は、ByValFunc で宣言された hage にのみ適用され、_tmain に伝わることはありません。このため、ByValFunc 関数の中での変更は反映されず、[B] では "1" が出力されます。

「参照渡し」は、引数「への参照」を渡します。この場合、新しい HogeClass の為のメモリは確保されず、全く同じ場所を参照するものが、ByRefFunc の hage になります。
hage は hoge と同じ場所を指すので、ByRefFunc 関数内で変更した内容は、_tmain で宣言された hoge と同じ場所を変更するため、hoge の内容も変わります。つまり、ByRefFunc 関数の中での変更は、hoge を直接操作したのと同じとなり、[C] では "4" が出力されます。

では、なぜ[イ]の部分がコンパイルエラーになるのでしょうか。

C++ では、変数の宣言時に、値を保持するもの、アドレスを保持するものとして宣言できます。HogeClass hage; という宣言では、HogeClass という入れ物の、値を保持する変数と宣言します。しかし、new HogeClass(); は、HogeClass という入れ物を保持するために用意した場所を指す値を返します。
入れ物と、入れ物のある場所。
言い換えれば、「コーヒーカップ」と、「コーヒーカップは戸棚にあるよ」。この２つに互換性はありません。互換性がないことをコンパイル時に検出し、エラーとします。

ざっくりと。変数宣言に "*" が付いていたら、「場所」を指す。付いていなければ「そのもの」を指す。こんな感じで。C 言語で必ず躓くポイントなので、さらっと次に進む。

さて、今回のエントリの C++ によるコードと、前回のエントリの VB7.0 によるコードを比べてみましょう。
まず、結果を比べます。おっと、VB7.0 での結果をまだ書いてなかったですね。VB7.0 では "125" となります。VB7.0 のコードをもう一度書きますね。

Public Class HogeClass
    Public Value As Integer
End Class

Private Sub ByValAndByRef(ByVal sender As Object, ByVal e As EventArgs)
    RemoveHandler Application.Idle, AddressOf ByValAndByRef
    Dim hoge As New HogeClass

    hoge.Value = 1
    TextBox1.Text = hoge.Value.ToString()    ' [A] 1 を表示

    ByValFunc(hoge)
    TextBox1.Text += hoge.Value.ToString()   ' [B] 2 を表示

    ByRefFunc(hoge)
    TextBox1.Text += hoge.Value.ToString()   ' [C] 5 を表示
End Sub

Sub ByValFunc(ByVal hage As HogeClass)
    hage.Value = 2         ' [B] で表示される
    hage = New HogeClass   ' [あ]
    hage.Value = 3
End Sub

Sub ByRefFunc(ByRef hage As HogeClass)
    hage.Value = 4
    hage = New HogeClass   ' [い]
    hage.Value = 5         ' [C] で表示される
End Sub

ここで注目なのは、変数 hoge を宣言しているところにある、New というキーワードです。C++ のコードには、 _tmain 関数での宣言にこのキーワードがありませんでした。

ということで、C++ のコードにこのキーワードを入れようとすると、あっちこっちでコンパイルエラーが出るようになりますorz

そして、コンパイルエラーをとって、VB7.0 のコードと等しい動きをするようになったのが、次のコード。

#include "stdafx.h"
#include <iostream>

class HogeClass {
public:
    int Value;
    HogeClass() {
        Value = 0;
    };
};

void ByValFunc2(HogeClass* hage);
void ByRefFunc2(HogeClass** hage);

int _tmain(int argc, _TCHAR* argv[])
{
    HogeClass* hoge2;
    hoge2 = new HogeClass();

    hoge2->Value = 1;
    std::cout << hoge2->Value;

    ByValFunc2(hoge2);
    std::cout << hoge2->Value;

    ByRefFunc2(&hoge2);
    std::cout << hoge2->Value;
}

void ByValFunc2(HogeClass* hage)
{
    hage->Value = 2;
    hage = new HogeClass();
    hage->Value = 3;
}

void ByRefFunc2(HogeClass** hage)
{
    (*hage)->Value = 4;
    *hage = new HogeClass();
    (*hage)->Value = 5;
}

まず、hoge2 の宣言が、"*" 付き、すなわち「場所」を指すように変わりました。

ここです。

VB7.0 では、というより、共通型システム（CTS）では、ですね。CTS では、System.Object を継承した型はすべて、参照型となります。つまり、「場所」を指すようになっています。ここ、突っ込むと刈歩さんのセッションとバッティングするので、これくらいにしておく。

ByVal で引き渡す場合、引き渡すのは変数の値なのですが、その「値」とはつまり、「参照」なのです。「この変数の実体は、この場所にあるよ」という場所への参照情報を値渡しするので、引き渡された関数からでも、引数の内容を変更することができるのです。

そして、C++ のコードと見比べていただきたいのですが。あっと。ここには VB7.0 でのコードを載せましたが、C# でもそう変わらないコード内容になります。気をつけるのは、ByRef が、ref になることくらいでしょうか。

さて、強調してあるところが違うところだと、気づいていただけたかと思います。気づいて欲しいから強調しているわけですが。

hoge2 の宣言に "*" がついて、場所を指すようになったのと同様、ByValFunc, ByRefFunc の引数にも "*" がついて、ByRefFunc なんか２つも付いちゃってます。引き渡すところも、"&" が付いていたりしています。つまり、こうやって変数の内容を、値そのものなのか、値が格納してある場所なのか、人が指定しているわけです。ややこしいですね。

VB7.0 や C# では、このようなややこしいことを、言語仕様によって人が指定しなくていいようにしてあります。便利ですね。

え？なに？
「どうして、わざわざ int 型を持つクラスを定義するの？int 型を直にやればいいんじゃない？」
ですって？その辺は、刈歩さんがたっぷり説明してくださるでしょう。そうすると…

私が考える、部分定義のメリット

はなおかじった — Sat, 07 Apr 2007 21:03:00 GMT

部分型定義（その２）（R.Tanaka.Ichiro's Blog）より：

ところで、

デザイナ

を使ってフォームを作るとファイルが二つに分かることはご存じでしょうか？

実は、これもパーシャルクラスによるものです。
以下は、C# で Form1 というフォームクラスを追加した時に、自動的に作成されたファイルのサンプルです。

ファイル名：Form1.cs
　　public partial class Form1 : Form
　　{...

ファイル名：Form1.Designer.cs
　　partial class Form1
　　{...

さて、話を元に戻します。

私としては、フォームだけで終わって欲しくなかったので、私が考えるメリットを書きます。

Visual Studio.NET、および 2003 にも、DataSet デザイナがあります。こいつでデザインすると、XML Schema と、DataSet, DataTable, DataColumn, DataRow クラスを生成してくれます。便利ですね。でも、ちょっと待ってください。このクラス、かゆいところに手が届かないのです。

たとえば、「このテーブルに定義されている列名の一覧が文字列配列で欲しい」と思ったとします。すると、外部から DataTable を取り出し、そこから DataColumn クラスを引き出して、列挙してやらなければならない。ちょっと待ってください。オブジェクト指向は「自分のことは自分でする」が基本じゃないですか？DataTable の中に定義されている列名の一覧を、DataTable 自身が提供せずにどうします？

もちろん、生成されたコードを修正すれば、そういうことも可能です。しかし。そうしてしまうと、今度はデザイナで修正するごとに、コードを修正し直さなければならない。

ああ、面倒くさい！！

ここに有効に働くのが、パーシャルクラスです。

フォームの修正をしても、そんなのは所詮、Initialize メソッドと宣言あたりですんでしまいます。つまり、7.x バージョンでは region で囲まれていた範囲ですね。しかし、DataSet デザイナや CrystalReports は、ファイルを書き直してしまいます。こういうものに対しても、独自の宣言を追加できてしまうのです！！

もちろん、ここで止まりません。独自のコードビルダーを作ったとしても、そのコードビルダーの使用者は、あなたが生成部分をどのように実装していようが、あなたにお構いなしに独自の宣言を追加できるのです。

ね？便利でしょ？

επιστημηさんが危惧されているように、やり過ぎると「いったいこのクラスは、いつ完成するの？！」ということになります。私は、「自動生成コード」と、「そこに手動追加するコード」くらいの切り分けにしておく方がいいんじゃないかと思います。

月日は百代の過客にして行き交う技術もまた旅人なり

はなおかじった — Mon, 12 Mar 2007 22:38:00 GMT

先日の「再帰呼び出しの代わり」ですが。。。

すみません。思いっきり間違いを含みまくっています。一つに、古い情報を更新せずに、そのままの感覚で書いていました（タイトルは、ここにかけてみた）。一つに、書きながら、ほかのことを考えていました。シャノンさんのつっこみをベースに、修正。

プログラムポインタ → PC レジスタというので、「プログラムカウンタ」の方が正しく、Pentium では「EIPレジスタ」。

プログラムポインタのスタック領域→これは、書き方が悪かった、かな？これだと EIP レジスタ専用のスタック領域があるように理解できますね。そういうつもりではありません。「スタックセグメント」ですか。あ、IL ベースではなく、ネイティブベースです。って、例外を生成するのは IL ベースじゃないかorz

CL → IL が正しい。CL だと、コンパイルされてないじゃないか。
あれ？「共通言語」って、「共通言語仕様」という言葉でしか使わないの？
そういえば、CLR と CLI の違いもよくわからなかった。CLI は「共通言語基盤」。CLR が「共通言語ランタイム」。マイクロソフトによる CLI の実装が CLR、という理解でよかったはず。
いや、だから、頭文字略語はやめてほしい。。。あ、ここで使っているのは、acronym 要素を使っています。ポイントしてみてください。

ngen.exe → JIT コンパイラ。何を考えていたんだろう？たぶん、「どうやってアセンブリを見ようかなぁ？」とか考えていたんだと思う。で、何で「アセンブリを見よう」なんて考えていたかというと、チラホラ話題にあがっている「"=" は等号か、代入演算か」のスレに書いているコメントを考えていたから。

再帰呼び出しの代わり

はなおかじった — Fri, 09 Mar 2007 21:28:00 GMT

関数（メソッド）が、自分自身を呼び出すことを「再帰呼び出し」といいます。ディレクトリの一覧を取得するときなどに重宝します。

// 指定したディレクトリを再帰的に表示
[STAThread]
static void Main(string[] args) {
 if (args.Length == 0) {
  Console.WriteLine("ディレクトリを指定してください。");
 } else {
  OutputDirectory(args[0], 0);
 }
}
static void OutputDirectory(string directoryName, int depth) {
 if (Directory.Exists(directoryName) == false) {
  return;
 }
 DirectoryInfo dir = new DirectoryInfo(directoryName);
 PrintLeader(depth);
 Console.WriteLine("-{0}",dir.Name);
 DirectoryInfo[] dirInfo = dir.GetDirectories();
 foreach (DirectoryInfo item in dirInfo) {
  OutputDirectory(item.FullName, depth + 1);
 }
 FileInfo[] fileInfo = dir.GetFiles();
 foreach (FileInfo item in fileInfo) {
  PrintLeader(depth + 1);
  Console.WriteLine(item.Name);
 }
}
static void PrintLeader(int depth) {
 for (int level = 0; level < depth; level++) {
  Console.Write("｜");
 }
}

// 実行結果
D:\DataFolder\Projects\TestSolution\tree\bin\Debug>tree ..\..
-tree
｜-bin
｜｜-Debug
｜｜｜tree.exe
｜｜｜tree.pdb
｜-obj
｜｜-Debug
｜｜｜-temp
｜｜｜-TempPE
｜｜｜tree.exe
｜｜｜tree.pdb
｜｜｜tree.projdata
｜App.ico
｜AssemblyInfo.cs
｜Tree.cs
｜tree.csproj
｜tree.csproj.user

このプログラムの考え方の一例を示します。

指定されたディレクトリに存在する、ディレクトリの一覧を取得します。取得したディレクトリ一覧について、それぞれのディレクトリでまた存在するディレクトリの一覧を取得します。ディレクトリ内にディレクトリが存在しなければ、ファイルの一覧を取得し、表示します。そして、上のレベルへ制御を戻します。

ところが、この方法は少し注意が必要です。

ここの例では C# でコードを作っていますが、コンピュータは C# を理解できません。そこで、コンピュータにわかる言語にコンパイルします。C# の場合、コンパイルした結果は CL という言語になりますが、この言語を直接実行することは出来ません。実行時に、ngen.exe というツールでもう一度、今度はネイティブ（コンピュータが直接理解できる言語）にコンパイルされます。

ネイティブ言語、すなわち CPU が理解できる言語を実行するとき、“プログラムポインタ”（または、プログラムカウンタ）というレジスタがあり、このポインタで、次に実行するべき命令の位置を示します。関数呼び出しを行うと、このプログラムポインタの現在の値（および、他のレジスタの現在値）をスタックへ積み、呼び出される関数のアドレスで上書きします。そして、関数の実行が終わったら、プログラムポインタの値をスタックから取り出し、元の処理を続けます。

関数の呼び出しが多くなって、スタックする領域がなくなると、「スタックオーバーフロー」という実行時エラーが発生することになります。

反対に考えると、「スタックオーバーフロー」が発生したら、どこかで関数呼び出しがループしていると考えられます（あるいは、単に深すぎる）。このエラーは次のようなプロパティ設定をすると、簡単に発生させることが出来ます。

// スタック オーバーフローが発生する例
private int someValue;
public int SomeValue {
    get { return SomeValue; } // 大文字と小文字を間違えた！！
}
// SomeValue プロパティへのアクセスは、SomeValue プロパティを呼び出すため、無限再帰する。

このように再帰呼び出しは、ある処理をするためには必要なのですが、プログラムポインタのスタック領域という、比較的小さなエリアの大きさによって制限されます。また、CPU の実行レベルで考えても、レジスタ群のスタックやプログラムポインタの書き換えは、コストがかかる方法です。

そこで、再帰呼び出しと同じ結果を、別の方法で実現します。

こういう時に用いるのが、System.Collections.Stack クラス／System.Collection.Queue クラスです。スタックは、後入れ先出し（LIFO）の記憶領域を提供してくれます。キューは、先入れ先出し（FIFO）の記憶領域を提供してくれます。

どうするかというと、もう一度コードを見ます。ここで、再帰呼び出しをしているのは、foreach ブロックの中です。このループで、再帰呼び出しをしているところで、ループ内で使っている変数のスナップショットをとり、そのスナップショットをスタックに待避、新しい値で変数を上書きして処理をやり直せば、再帰処理をしているのと同じ動きをすることになります。

・・・面倒です。

なので、使いません。（おい）

ケースバイケース。ものは使いようなのです。

このコードでは、ディレクトリ構造を表示しました。表示するためには、今表示している内容がなんなのか、覚えておかなければなりません。覚えておかなければならないものがあるため、自分で覚えておかなければならないものを待避させなければならない場合は、再帰の方が楽です。

しかし、「ディレクトリ中のすべてのファイルを、{アタッチしたい | 更新日付が知りたい | フルパス名が知りたい}」という場合、ファイルにアクセスする順番は関係ありません。順番が関係ないなら、覚えておくものはありません。こういう場合、再帰呼び出しよりも低コストなので、使います。

// Main を少し変更
static void Main(string[] args) {
    if (args.Length == 0) {
        Console.WriteLine("ディレクトリを指定してください。");
    }
    else {
        DateTime start = DateTime.Now;
        OutputDirectory(args[0], 0);
        DateTime t1 = DateTime.Now;
        Console.WriteLine("----------");
        OutputDirectory(args[0]);
        DateTime t2 = DateTime.Now;
        Console.WriteLine("{0} / {1}", t1.Subtract(start), t2.Subtract(t1));
    }
}
// 指定したディレクトリ以下のフルパス名を表示
static void OutputDirectory(string directoryName) {
    // Queue に、次に列挙したいディレクトリを放り込むことにする
    System.Collections.Queue q = new System.Collections.Queue();
    DirectoryInfo dir = new DirectoryInfo(directoryName);
    // 初回が回るように、トップを放り込む
    q.Enqueue(dir);
    while (q.Count > 0) {
        // キューから取り出して、書く
        DirectoryInfo info = q.Dequeue() as DirectoryInfo;
        Console.WriteLine(info.FullName);
        // ディレクトリ内のディレクトリを、キューに放り込む
        DirectoryInfo[] dirs = info.GetDirectories();
        foreach (DirectoryInfo item in dirs) {
            q.Enqueue(item);
        }
        FileInfo[] files = info.GetFiles();
        foreach (FileInfo item in files) {
            Console.WriteLine(item.FullName);
        }
    }
}

// 実行結果
-tree
｜-bin
｜｜-Debug
｜｜｜tree.exe
｜｜｜tree.pdb
｜-obj
｜｜-Debug
｜｜｜-temp
｜｜｜-TempPE
｜｜｜tree.exe
｜｜｜tree.pdb
｜｜｜tree.projdata
｜App.ico
｜AssemblyInfo.cs
｜tree.cs
｜tree.csproj
｜tree.csproj.user
----------
D:\Visual Studio Projects\TestSolution\tree
D:\Visual Studio Projects\TestSolution\tree\App.ico
D:\Visual Studio Projects\TestSolution\tree\AssemblyInfo.cs
D:\Visual Studio Projects\TestSolution\tree\tree.cs
D:\Visual Studio Projects\TestSolution\tree\tree.csproj
D:\Visual Studio Projects\TestSolution\tree\tree.csproj.user
D:\Visual Studio Projects\TestSolution\tree\bin
D:\Visual Studio Projects\TestSolution\tree\obj
D:\Visual Studio Projects\TestSolution\tree\bin\Debug
D:\Visual Studio Projects\TestSolution\tree\bin\Debug\tree.exe
D:\Visual Studio Projects\TestSolution\tree\bin\Debug\tree.pdb
D:\Visual Studio Projects\TestSolution\tree\obj\Debug
D:\Visual Studio Projects\TestSolution\tree\obj\Debug\tree.exe
D:\Visual Studio Projects\TestSolution\tree\obj\Debug\tree.pdb
D:\Visual Studio Projects\TestSolution\tree\obj\Debug\tree.projdata
D:\Visual Studio Projects\TestSolution\tree\obj\Debug\temp
D:\Visual Studio Projects\TestSolution\tree\obj\Debug\TempPE
00:00:00.0312500 / 00:00:00.0781250

表示されている順番を見ると、再帰の例のように、ツリー表示には向かないことがわかると思います。何度かトライして、できなかったというわけでは、断じてあります。

しかし。。。実際に実行してみると、再帰処理の方が速かったorz...

K&R 本あたりに、関数を呼び出すことによる、プログラムポインタの書き換えと、ローカル変数の待避、および再生成のオーバーヘッドの方が大きい、と書いてあったと思うんだけど。すると・・・キューやスタックを使うメリットがない？？？

ちょっと気になったので調べてみた（HTML でフォーカス移動）

はなおかじった — Mon, 26 Feb 2007 22:25:00 GMT

某所を見ていて、ちょっと気になったので調べてみた。

W3C による、HTML 4.01 の仕様→ http://www.w3.org/TR/html4/

17章が FORM に関する仕様→ http://www.w3.org/TR/html401/interact/forms.html

ここの11項に、tabbing navigation が定義されている。

で、その原文。

Tabbing keys. The actual key sequence that causes tabbing navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a selected element).

User agents may also define key sequences to navigate the tabbing order in reverse. When the end (or beginning) of the tabbing order is reached, user agents may circle back to the beginning (or end).

フォーカス移動は HTML の仕様では決められておらず、ユーザーエージェントに任せられている。

つまり、「タブキーでフォーカス移動」は、InternetExplorer の仕様ということ。

そして、「tabbing navigation」だから、[TAB]キーが割り当てられたのではなかろうか。

ASP.NET で悲観的ロック

はなおかじった — Mon, 05 Feb 2007 22:10:00 GMT

ふと思ったんだけど、出来るんじゃないだろうか。以下、断定形で書くけど、想像だけで検証はしていません。

ログイン後に、フレームを作成する。仮にユーザに見せて遷移を行うフレームを「普通フレーム」、ロック情報を保持するためのフレームを、「ロックフレーム」とする。

ロックフレームは、幅1とかで見せないか、あるいは「ログアウト」ボタンのみを置いて、遷移をさせない。このフレームに表示する HTML で、body の onunload にて、ログアウトなどのロック解除を行う。これで、「ブラウザを閉じられたら？」に対応できる。

画面遷移は普通フレームだけで行い、ロックフレームは書き換えない。あるいは、これが書き換えられるときはログアウトするときだよ、と。

あとは、タイムアウト。チケットの有効期間とセッションの有効期間を同じ長さにしておけば、対応できるんじゃないかと。んで、ログインフォームは、_top に必ず一度リダイレクトするようにしておく、と。

やってみたいんだけど、分類の振り分けが、あと30近く残っているんだなぁ。。。全然減らないよぉ(T^T;)

スプラッシュウインドウだそうです

はなおかじった — Fri, 12 Jan 2007 21:49:00 GMT

スプラッシュウィンドウより:

さて、これを実現するために、僕は今まで Program Class の Main()メソッドでスプラッシュウィンドウを開いていました。
しかし、Application.Run(); でメインフォームを開くまでは不用意なことはできません。
何故なら、Application.Run() によってメッセージポンプが起動されるため、この前に何らかの処理を行おうとすると、メッセージポンプが正常に働かない危険性があるらしいのです。
（この辺りは、僕も詳しくないので、詳細は MSDN 等でご自身で確認して下さい）

ということで、作ってみた。まず、Program.cs


namespace SplashWindowSample {
    static class Program {
        internal static ApplicationContext ThisContext;
        [STAThread]
        static void Main() {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            ThisContext = new ApplicationContext(new FrmSplash());
            Application.Run(ThisContext);
        }
    }
}

太字が、標準のコードに対して変更した行です。メインフォームのすげ替えが出来るように、ApplicationContext を用意しました。こいつに、まず、スプラッシュウインドウをメインフォームとして表示してもらいます。

次、スプラッシュウインドウの方。


namespace SplashWindowSample {
    public partial class FrmSplash : Form {
        public FrmSplash() {
            InitializeComponent();
            Application.Idle += new EventHandler(Application_Idle);
        }
        void Application_Idle(object sender, EventArgs e) {
            Application.Idle -= Application_Idle;
            FrmMain frm = new FrmMain();
            frm.Shown += new EventHandler(frm_Shown);
            Program.ThisContext.MainForm = frm;
            frm.Show();
        }
        void frm_Shown(object sender, EventArgs e) {
            this.Close();
        }
    }
}

コンストラクタで、「アプリケーションがアイドル状態になったとき」のイベントを拾うようにしました。なぜ？コンストラクタや Shown, Load イベントで時間のかかる処理をやると、場合によってはスプラッシュウインドウの描画が完了しないうちに時間がかかる処理に入ってしまったので。はい、描画が止まります。他のウインドウを、上に重ねないでください。

アイドル処理の最初で、登録したイベントを削除し、二度と通らないようにしておきます。そして、本当のメインフォームを作成します。表示が完了したときに、スプラッシュウインドウを消せるように、イベントをハンドルします。メインフォームのすげ替えを行ってから、表示させます。

ん。。。internal でも、ApplicationContext を外部公開するのはやだなぁ。まぁ、サンプルということで。

とりあえず、このソリューションに追加してみた（作りかけのプロジェクトもあるので注意）。サンプルは、あくまでサンプルです。この意味がわからない人は、使わないでください。