ファイルに関連付けられたアイコンの取得
滅多に使用する事ではないが、ファイルに関連付けされたアイコンを表示したい場合、.NET Framework2.0以降であれば、簡単に取得出来る。この取得の仕方については、@ITの.NET TIPS 「ファイルに関連付けられたアイコンを取得するには?[2.0のみ、C#、VB]」に書かれている。
日 | 月 | 火 | 水 | 木 | 金 | 土 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |
滅多に使用する事ではないが、ファイルに関連付けされたアイコンを表示したい場合、.NET Framework2.0以降であれば、簡単に取得出来る。この取得の仕方については、@ITの.NET TIPS 「ファイルに関連付けられたアイコンを取得するには?[2.0のみ、C#、VB]」に書かれている。
タイトル通り、コントロールIDを知りたかったので、SPY++にて調査。滅多に必要となるものでもないが、せっかくだから調査結果を覚え書きとして残しておく。
※コントロールID指定で、WindowsAPI の GetDlgItem を使用すれば、そのコントロールのウィンドウハンドルが得られます。ウィンドウハンドルが得られれば、そのコントロールの各種制御や情報取得が出来ます。
(11/5:Vista英語版での調査分を追記しました)
汎用的な自作コントロールを作成したら、ツールボックスに登録して使いたい筈だ。アイコンを指定せずに、自作コントロールを使い易くする(説明表示系)で使用した、CurrencyTextBox コントロールを登録してみる。
ツールボックスへの登録を行うと、VS2003なら、 VS2005なら、 と登録される筈だ。この様に、特にアイコンを指定せずとも、デフォルトのアイコンが表示される。
前回からの続きで、今度はドロップダウン形式のプロパティエディタを作成してみる事にする。
これもまた前回同様、CurrencyTextBox クラスを使用し、FileAttributes の列挙体型を持つ同名プロパティを追加して、これにドロップダウン形式の独自プロパティエディタを作成してみる。
なぜ金額入力用の TextBox に FileAttributes プロパティが必要なのか?と突っ込みたくなるかもしれないが、そこは勘弁願いたい。
「自作コントロールを使い易くする(説明表示系)」で例に出したCurrencyTextBoxクラスを使って、独自のプロパティエディタを定義してみる。
プロパティエディタには、大きく分けてダイアログボックス形式とドロップダウン形式の2種類が存在する。この形式の違いは、実際のエディタ作成の過程において、大きな違いがある。簡単な違いを下の表にまとめてみた。
編集画面の形式 | 作成元クラス | 補足 |
---|---|---|
ドロップダウン形式 | UserControl | 閉じる指示を行うボタン等は一般的にはつけない(?) Flags属性のない列挙型の場合は、1つ項目を選択したら自動的に閉じる。 |
ダイアログボックス形式 | Form | モーダル表示のダイアログなので、通常OKボタン(DialogResult.OK)とキャンセルボタン(DialogResult.Cancel)を付ける。 |
自作コントロールを作成した場合、一般的な組み込み型のプロパティなら、特に何もしなくてもプロパティウィンドウで普通に値の設定が出来ます。
前回サンプルに使用したCurrencyTextBoxを例にとると、数値の設定・取得はCurrencyValueプロパティを使用する。Textプロパティは存在しなくてもいい事になる。それどころか、Textプロパティを使用して、数値にならない文字列を設定する事が出来てしまう。なるべくなら、Textプロパティを非公開プロパティにしてしまいたいところだ。
しかし、C#は既に公開されているものを隠せない仕様になっている。ここでは、それでも隠すやり方、あるいは実用上は隠したも同然にならいかを考えてみる。
.NETで自作コントロールを作成した場合、完成度を高めるためにも説明表示系の対応は、やっておくべきだと思う。
リテラル定数の記述に不安があって、確認しようと思ったら意外にも苦労してしまった。
なので覚え書きとして、まとめておく。
ファイルを開く/名前を付けて保存のダイアログは、それぞれ OpenFileDialog,SaveFileDialog を使用する事は周知の事である。しかし、微妙にWin32APIベースで表示したコモンダイアログと違う事は御存じだろうか。
この事は、既にこのブログで詳しく述べられている。
このブログ内容の補足としてダイアログから実際に表示されるエラーメッセージボックスの違いをまとめてみた。
アプリケーションのINIファイルに相当するデータを格納するには、Application.CommonAppDataPath または Application.LocalUserAppDataPath を使えば良い...と思ったら、
ベースパス\CompanyName\ProductName\ProductVersion
を返すという。CompanyName と ProductName は良いとして、何故 ProductVersion まで含めるのだろう。
これだとアプリケーションをバージョンアップしたら、いきなりINIファイルを読めなくなってしまう。バージョンアップしたら、INIファイルを新しく要求するフォルダへ移動しろとでもいうのだろうか。
ずっとそう思っていたが、改めて検索してみたら、@ITの.NET Tips「アプリケーション設定情報はどこに保存すべきか?」で、このバージョン番号を含まない独自クラスのサンプル・ソースが公開されていた。
やっぱりそうだよね。バージョン番号はいないよね。
非同期デリゲートを使うと、ちょっとした事をお手軽にバックグラウンド処理が出来る。
そう思っていざ使ったところ、はまった事があったので、非同期デリゲートについてまとめておく。
最も基本的なポイント
実際のコードは、だいたいこんな感じ。
using System;
namespace ConsoleApplication1
{
delegate void AsyncDelegate(string msg);
/// <summary>
/// アプリケーション主実行クラス
/// </summary>
class Ap
{
[STAThread]
static void Main(string[] args)
{
Console.WriteLine("主処理を開始しました。");
AsyncTest at = new AsyncTest();
Helper helper = new Helper();
helper.asyncProc = new AsyncDelegate(at.OutputMessage);
IAsyncResult iar = helper.LongProc();
System.Threading.Thread.Sleep(1000);
while (!iar.IsCompleted)
{
Console.Write(".");
System.Threading.Thread.Sleep(1000);
}
Console.WriteLine("主処理を終了しました。");
}
}
/// <summary>
/// 非同期デリゲートを実行するメソッドがあるクラス
/// </summary>
class AsyncTest
{
internal void OutputMessage(string msg)
{
Console.WriteLine("OutputMessage処理を開始しました。msg = {0}", msg);
System.Threading.Thread.Sleep(3000); // 3秒待つ
Console.WriteLine("\nOutputMessage処理を終了しました。");
}
}
/// <summary>
/// 非同期実行を行う為のヘルパークラス
/// </summary>
class Helper
{
internal AsyncDelegate asyncProc;
internal IAsyncResult LongProc()
{
Console.WriteLine("LongProc処理を開始しました。");
IAsyncResult ias = asyncProc.BeginInvoke("受け渡し文字列"
new AsyncCallback(EndLongProc), asyncProc);
Console.WriteLine("LongProc処理を終了しました。");
return ias;
}
internal void EndLongProc(IAsyncResult ar)
{
AsyncDelegate ad = (AsyncDelegate)ar.AsyncState;
ad.EndInvoke(ar);
}
}
}
正直自分がブログを始めるとは思ってもいなかったのです。
動機は昔やってた事をなかなか思い出せない事があり、技術的な事位は記録しておくべきだと考えたからです。覚え書きをブログにしちゃえ、って事です。
こういう背景もあって、当ブログでは雑談的な内容は一切しない方針です。そのうちネタ切れになるのが心配ですが、それはそのとき考える事にします。
プログラミング暦は結構長いものの、途中ブランクなんかもあったりして、経験度数は?です。
.NETは、本格的には2010年1月から始めたのですが、手持ちの製品版はVS2003までしかありません...あとはExpress Edition で 2005も使ってますが、実質それ位ですね。これ以降のやつは Windows2000 で使えない、重すぎ、がネックとなって Express Edition も使う気はないです。開発環境を、VirtualPCに追いやっているせいもあるのですが。
今時、C#2003/2005の話題でいいのか、ってのはありますが、まあその辺は許して下さい。C#2008/2010への応用は可能な筈ですしね。
という訳でよろしく。