親コンテナを無効にしても子コントロールを灰色表示にしない方法

.NETでは、通常親コンテナの Enabled プロパティを false にすると、子コントロールも自動的に Enabled プロパティが false になって、灰色表示になります。親が Enabled = false である限り、子コントロールは Enabled = true に設定しようとしても効かない様です。

普通はこれでも問題無いのですが、.NETでないアプリケーションを.NETに移行する場合等、どうしてもコントロールを通常表示の状態で、フォーカスを受け取れない状態にしたい場合もあるかと思います。

アンマネージドDLLの動的リンク(3)[最終回]

アンマネージドDLLの動的リンク(2)の続きです。前回、方法１or２による比較では、方法２の方が若干スマートに書ける、また UnmanagedLink クラスを使用すれば、かなり簡単に移植出来そうな事が判りました。
更に方法２は、標準的なやり方なので安心感もあります。

アンマネージドDLLの動的リンク(2)

アンマネージドDLLの動的リンク(1)の続きです。前回、方法１によるやり方では、Unicode 文字列を使用するには、構造体を使用する、としていました。しかし改めて、前回のANSI版一括解凍ルーチンを使用して、Unicodeファイル名を持つLHA書庫ファイルを指定しても、どうやら正常に解凍される様です。既定のマーシャリングの関係だと思いますが、どうもよく判りません。今回やろうとしていたメンバ名一覧取得では、しっかりエラーになるのですが...

アンマネージドDLLの動的リンク(1)

私事ですが、Delphi製の自作の圧縮解凍アプリを愛用しています。しかし、いかんせん所有する Delphi が Delphi5 (Delphi6 も持っているが、今はインストールさえしていない)なので、Unicodeファイルに対応していません。
そこで、C#移行出来ないかと考えたのが、C#を始めるきっかけになったのです。

当初、.NETでは、動的リンク出来ないという情報も得ていたので、回避策も含めて本当に出来ないのか探した事がありました。そのとき見つけたのが、この方法です。

MoF C#を使ってDLL内の関数を動的に呼び出す方法　…方法１

この方法はC#2003でも使用可能で、実際先程の自作圧縮解凍アプリも、C#2003で作成しはじめた事もあって、うまく動いています。

ところが、C#2005以降では、標準で動的リンクが使える様です。最近までこの事を知りませんでした。こちらの使用方法は、ここなんかに書かれています。

へろぱ的ブログ C#でDLLを動的に呼び出すサンプル　…方法２

今は、この圧縮解凍アプリは、C#2005に移行して更に開発中なので、この標準的な使用方法も可能になっています。そこで、ちょっと使用方法の差異等について、比較してみる事にしました。

なお、通常はC#2003で動作確認していますが、今回は方法２が、C#2005以降のみなので、C#2005で動作確認しています。

Intersect/Union/Inflate/Offset メソッド

ヘルプ等の文章だけによる説明だけでは一目で判りにくく、混乱しやすいので、図解付きで Rectangle の４メソッドの覚え書きを記しておく。

ListView/TreeViewにオーバーレイアイコンを表示する

ListView/TreeView には、元々オーバーレイアイコンの表示機能があります。プロパティでのサポートがされてない様なので、ここで Win32API を使用しての表示方法を書きます。

ポイントは、以下の２点です。

1. イメージリスト中登録されているアイコンの中で、オーバーレイアイコンとして使用する物を登録する。
2. 実際に表示する段階で、TreeNode あるいは ListViewItem に対して、オーバーレイアイコンの設定を行なう。

では、順に説明しましょう。

Win32APIで発生したエラー処理(GetLastError 処理相当の処理)

備忘録として書いておきます。

Win32API宣言時のDllImportに、"SetLastError=true" を付加する。

[DllImport("user32.dll", CharSet=CharSet.Auto, SetLastError=true)]

プログラムコード上で実際に、GetLastError を実行したい部分では、GetLastError の代わりに、Marshal.GetLastWin32Error() を使用する。

エラーコード一覧は、下記サイトなんかがいいのではないでしょうか(回線速度によっては使えないかも)。
http://ir9.jp/prog/ayu/win32err.htm

また、エラー発生時に例外を発生させる場合は、

throw new Win32Exception(Marshal.GetLastWin32Error());
又は
throw new Win32Exception(Marshal.GetLastWin32Error(), "(補足情報)");

といった記述のほか、以下の様な記述も出来ます。

int hResult = Marshal.GetHRForLastWin32Error();
Marshal.ThrowExceptionForHR(hResult);

※この場合、Marshal.GetExceptionForHR を使用して、より柔軟な例外コード記述も可能

構造体／クラスプロパティを展開可能にする(4)[最終回]

前回の「構造体／クラスプロパティを展開可能にする(3)」の続きです。前回、テスト用の構造体プロパティ(RectStruct)に関しては、問題無く展開出来るようになりました。しかしクラスプロパティ(RectClass)は、同じ RectConverer を介しても、子プロパティを変更しても親プロパティの文字列は自動更新されない問題がありました。
また、展開された子プロパティの表示順も制御したいと思うでしょう。親プロパティの文字列表示が、Left, Top, Right, Bottom なのに、展開順がプロパティ名のアルファベット順(Bottom, Left, Right, Top)になっているのは不満です。なので、この２点を解決したいと思います。

構造体／クラスプロパティを展開可能にする(3)

前回の「構造体／クラスプロパティを展開可能にする(2)」の続きです。前回RectStruct/RectClass を、RectConverter クラスを作成する事によって、プロパティの展開・編集が可能な状態になりましたが、RectStruct と RectClass で違う動作をする部分がありました。

前回予告通り、今回は RectConverter クラスの手本とした、MSDNの.NET Framework の PropertyGrid コントロールの高度な活用「展開可能オブジェクトのサポートを提供するには」の例題では、同じ挙動を示すのかを検証します。

構造体／クラスプロパティを展開可能にする(2)

前回の「構造体／クラスプロパティを展開可能にする(1)」の続きです。実は前回分のタイトルやカテゴリーを変更しました。また、前回最後の時点でのソース一式もダウンロード可能なように記事をに追記しました。

構造体／クラスプロパティを展開可能にする(1)

C#を始めた頃からの疑問で、Size プロパティの挙動がある。Size プロパティは、Size 構造体のプロパティとあり、Size プロパティの説明では、Size 構造体のメンバに直接値を設定するな(しても大きさは変更されない)とある。これは、構造体が値型なので当然の挙動であるといえる。実際、初めての頃はプログラムコードでうっかり、button1.Size.Width = 100; とか記述して、コンパイルエラーになった記憶がある。

しかし一方で、プロパティウィンドウ上では、右図の様にそのメンバが展開され、しかもそのメンバに対して値が設定出来る(新しい値を入れるとその値で、大きさが変わる)。

プログラムコード上では、構造体として振る舞うくせに、プロパティウィンドウ上では、まるでクラス型の様な振る舞い方をするのである。なんで？と思っていたのであった。

つまり、プロパティウィンドウ上からは、Size.Width(Height) に対して値が変更出来てしまい、しかもちゃんと幅(高さ)が変わる。一方プログラムコードからは、この様な指定がを行っても、コンパイルで拒否されてしまう。

SizeGrip コンポーネント

訳あって、こんなコンポーネントを作ってみました。

命名規則の悩ましさ

ブログにサンプルを載せたりする様になり、改めて考えたのがこの命名規則。
個人で勝手にやってる限りは、自分流の命名方法で構わないだろうが、ブログに載せる分くらいは、そうもいかない気がする。
いくらサンプルとはいえ、他人がソースを読む事を前提にしている訳だから、一般に受け入れられている命名規則に従った方がいいであろう。