ダッチノート

組み込み型だと配列の定数を作れる？

ダッチ — Wed, 11 Jun 2008 23:06:00 GMT

　配列を定数で宣言しようとした場合に、配列は Class であるため定数にすることが出来ません。

　一方 String は Class であり、内部に Char 型の配列（？）を持っていますが、定数にすることが出来ます！　改めて考えてみるとすごいです。仕組みなどは、よくわかっていませんが、なんだかすごいです。これが組み込み型の力なのでしょうか。

　この「なんだか」さを例えるなら、テストの答えを適当に書いたら正解していた感じでしょうか。

　私も組み込み型を作りたくなってきました。

Spy 大失敗

ダッチ — Sun, 01 Jun 2008 20:08:00 GMT

　先日 Windows Vista 64bit マシンを手に入れました。

　64bit ということでアプリケーションが正常に動作するのか不安だったのですが、大抵のものが動作して安心しました。

　Visual Studio は 2003 がサポート対象外ということで、Visual Studio 2005 をインストールしました（2008 は持っていません）。ただ、毎回管理者として起動したりと、ちょっと手間ですが開発できるだけ幸せです。ただ、一つだけ問題が発生してしまいました。

　それは Spy++ でメッセージをフックすることが出来ません。2003 で作成されたアプリケーションはフックできるのですが、2005 で作成したアプリケーションをフックしても何も反応しません。Spy++ を管理者で起動すればと思ったのですが、それでもダメでした。

　なにが原因かわからないのですが、そういうものなのでしょうか？

ToolTip の表示場所を指定したい

ダッチ — Sun, 18 May 2008 23:16:00 GMT

　ToolTip をバルーン表示した時に、上側に表示されたり下側に表示されたりして気持ち悪いので、どっち側で表示するかを指定したいです。

　TextBox に ToolTip.SetToolTip メソッドで表示すると、このように上側に表示されるのですが、

図1：ToolTip を SetToolTip メソッドで表示

　TextBox に ToolTip.Show メソッドを使用して表示されると、必ず下側に表示されてしまいます。これでは ToolTip の裏側にどんな文字列が表示されているのかが隠されて見えません。それに私は上側に表示させたいんです。

図2：ToolTip を Show メソッドで表示

　ToolTip.Show メソッドでは表示する位置を指定できるのですが、指定した位置が ToolTip の左上部分だったり、矢印の部分だったりとまちまちになることがあります。こうならないようにするためにも、ToolTip を上側に表示するか下側に表示するかを選択できて、表示位置は矢印の部分を指定できればいいのになぁと思いました。

GDI+ は文字が苦手？

ダッチ — Sun, 11 May 2008 23:09:00 GMT

　.NET Framework のアプリケーションは GDI+ で描画されています。GDI+ はアルファブレンドを手軽に利用できるなど大変便利です。

　しかし GDI+ にはパフォーマンスとローカライズに関する問題があるそうです。.NET Framework 2.0 から文字を描画する際は、GDI を使用して描画されるようになっています（GDI+ で描画することも出来ます）。これによりパフォーマンスが向上するようです。しかし、これはパフォーマンスが向上するだけではありません。GDI+ が抱える次のような問題も解決してくれます。

GDI+ が抱える問題

「GDI+ で文字列を描画するアプリケーションにて全角ハイフンが表示されない」
文字を中央寄せや右寄せにすると、末尾の空白が描画されません。（これに関しては情報を見つけることが出来なかった為、なぜかは不明です。）

　パフォーマンスの問題と言いつつも、こっそり文字に関する問題も解決？されています。GDI で文字を描画するように思いついた人は、うまいことを考えたなぁとニヤニヤしてしまいました。

*次期 Visual Basic は赤くなります

ダッチ — Tue, 01 Apr 2008 22:00:00 GMT

　（4 月 1 日もあと少しですけどいいですよね）

　コードが青い、プログラマも青い、といわれ続けてきた Visual Basic ですが、次期バージョンからは赤くなるようです。

　これは単にコードが赤くなるだけではありません。次期バージョンでは、プログラマの要望を一切無視した改変が行われ、プログラマの怒りが爆発し、プログラマ自身が赤くなる機能が搭載されるようです。また Visual Basic に関するブログに炎上するようなコメントを自動で投稿したり、炎上を目的とした Visual Basic の記事が自動生成される機能が搭載されるとのことです。

モーダルダイアログである必要性

ダッチ — Mon, 17 Mar 2008 23:25:00 GMT

　前回の「モーダルダイアログを快適に表示するためには」では、モーダルダイアログを表示すると他のアプリケーションの操作に影響が出るということを書きました。

　モーダルダイアログであるメリットはもちろんありますが、少なからずデメリットもあります。そのデメリットを与えてまでモーダルダイアログで表示する必要があるのか、という疑問が浮かびました。そこでモーダルダイアログを表示する必要性について考えてみたいと思います。

モーダルダイアログである必要性

　そもそもモーダルダイアログを表示する目的というのは、アプリケーションの操作が出来なくなることから、アプリケーションの状態とダイアログの状態の同期を取ることだと思います。逆を言えばダイアログを表示中にアプリケーションの状態に変更が合ってはならない時に、または変更させたくない時にモーダルダイアログを表示するものだと思います。

　モーダルダイアログとして表示される代表的なものとして、アプリケーションの設定を行うオプション画面が上げられます。では、オプション画面はモーダルダイアログである必要性があるのでしょうか。オプション画面はアプリケーションがどういう状態の時でも表示できると思います。ということはアプリケーションの状態とオプション画面の状態に同期を取る必要性が無いのではないでしょうか。

　オプション画面をモーダルダイアログとして表示しなければならない場面はもちろんあります。また、モーダルダイアログである必要が無い場合もあると思います。そういう場合はモードレスダイアログとして表示すれば、モーダルダイアログであるデメリットが無くなり、快適に操作が出来るようになると思います。

モーダルダイアログを快適に表示するためには

ダッチ — Sun, 16 Mar 2008 23:02:00 GMT

　ダイアログはユーザと対話するために非常に便利で欠かせない存在です。そんなダイアログでも頻繁に表示するとわずらわしかったりと、使い方を誤ると不便なものとなってしまいます。特にダイアログを表示中はアプリケーションの操作が出来なくなってしまいます（それがモーダルダイアログの特徴でもあります）。そこでダイアログを快適に表示する方法を考えてみたいと思います。

モーダルダイアログを表示することで発生する問題

　先にも述べましたが、ダイアログを表示しているとアプリケーションの操作が出来なくなります。これはフォームの移動や最小化など、直接アプリケーションの操作とは関係のない、ウィンドウの操作についても同様です。

　こんな状況を想像してみてください。入力フォームの、ある項目をダイアログから入力しています。入力する内容の参考となるファイルがデスクトップに置かれていたり、ダイアログの裏に表示されている場合、どうやったらそれを見ることができるでしょうか？

　通常はウィンドウを最小化したり、移動したりすることで、デスクトップや裏に隠れているウィンドウを表示することができます（このような操作をされる方を中心に話を進めていきます）。しかし、ダイアログが表示されている場合はそうはいきません。特にダイアログの親ウィンドウが最大化していた場合は、通常の操作でデスクトップや裏に隠れているウィンドウを表示することは不可能です。一旦ダイアログを閉じるしか方法がありません。

　もちろん「デスクトップを表示」するアイコンをクリックしたり、タスクバーのウィンドウを選択、エクスプローラの表示などでデスクトップや裏に隠れているウィンドウを表示することは可能です。しかしこれらの操作をユーザは普段から行っていません。普段行っている操作でいつもと変わらない結果をユーザは望むと思います。それがダイアログを表示することで思わぬ結果となってしまいます。

　モーダルダイアログというのは、それを表示させたアプリケーションだけの操作を出来なくするものです。しかし、実際は他のアプリケーションの操作にも十分影響が出てしまっているのです。

モーダルダイアログにウィンドウ操作を

　では、どうすれば他のアプリケーションに影響が出ないようにダイアログを表示することが出来るのでしょうか。それはダイアログを表示している最中でも、その親ウィンドウに対してウィンドウの操作（移動・最小化・最大化・サイズ変更など）を行えるようにすればいいのではないかと思います。

　しかし、そのような操作は出来ません。もしダイアログの親ウィンドウに対してウィンドウ操作が行えたとして、何か問題が発生するのでしょうか。発生する問題はほとんど無いと思います。確認できている問題としては、親ウィンドウを無理やり最小化するとダイアログが閉じてしまうことです。どうやら根本的にウィンドウの操作は認められていないようです。

　それでも出来ることとして、ダイアログの裏に表示されているウィンドウにアクセスする手段はあります。それはダイアログを最小化することです。ダイアログを最小化すると親ウィンドウは常に非アクティブ状態になります。そうなると裏で表示されていたウィンドウが前面に表示されるようになります。これで裏に隠れているウィンドウを表示することが出来るようになります。

　普段表示しているダイアログにはいろいろと制限を設けていることが多いのではないでしょうか。具体的にいうと「フォームの最小化・最大化・サイズ変更ができない」「タスクバーにフォームが表示されない」「フォームのアイコンが設定されていない」などです。

　果たしてダイアログの表示にそのような制限は本当に必要なのでしょうか。必要なケースはかなり限られるのではないかと思います。その制限をなくすことでダイアログが表示されても、快適に操作ができるようになると思います。

ダイアログを快適に表示するために行うこと

フォームの最小化・最大化・サイズ変更を可能にする
タスクバーにフォームを表示する
フォームのアイコンを設定する

　やり過ぎかもしれませんが、出来ることならメッセージボックスにも上記のことを行えるようにしてもいいのではないかと思います。

　今回いろいろと考えてみて、ダイアログを表示中にデスクトップのファイルにアクセスする方法を見つけられなかったのが残念です。また、タスクバーを右クリックして表示されるメニューの「～表示」を選択すると、最大化していた親ウィンドウも一緒に「～表示」されます。これが出来るならウィンドウ操作をやらせて欲しいものです。それと、是非ともダイアログの最小化に合わせて親ウィンドウも最小化して欲しいと思います。

Code Complete 第 2 版が当たりました！

ダッチ — Sat, 15 Mar 2008 19:57:00 GMT

　「オンラインセミナー視聴キャンペーン」に応募したところ「Code Complete 第 2 版」が当たりました。しかも上下巻セットです。

　懸賞とかに当たった経験がほとんどなかったので、今回当たってとてもうれしいです。それも Code Complete というプログラミングに関わる人は誰でも欲しくなる良書中の良書ですから、うれしさ倍増です。上下巻セットでさらに倍。もう一つおまけに倍。

　上下巻合わせると 1200 ページにも及ぶ大ボリュームで、読み終わるまで何ヶ月かかるかわかりませんが、ゆっくり読み進めたいと思います。

　今回当たって思ったのですが、応募する時に感想などを書き込む箇所があると思います。その感想の量が多ければ多いほど当たる確立が上がるのかなぁと思ったりしました。これからも応募する時は書き込む量を多めにしようと思います。

Enabled が False のチェックボックスの意味は？

ダッチ — Sun, 09 Mar 2008 23:02:00 GMT

　チェックボックスは状態を切り替えるのに適したコントロールです。例えば「ボタンを表示する」と表示されているチェックボックスにチェックを付けるとボタンは表示され、チェックを外すとボタンは非表示になります。

　では、Enabled が False になっているチェックボックスにチェックがされていた場合は、ボタンは表示されるのでしょうか？

図1：Enabled が False のチェックボックス

チェックボックスは無効

　これはチェックが外されている状態（ボタンは非表示）になるのが適切だと思います。Enabled が False の場合はユーザに対して応答しないだけではなく、チェックボックス自体が無効になると思うからです。

チェックボックスは読み取り専用

　しかし、Enabled が False に設定されているのを読み取り専用として扱いたい場合もあります（ありますよね？）。読み取り専用にしたいのであれば AutoCheck プロパティを False に設定してやればいいのですが、見た目上読み取り専用であることがわかりません。また昔の言語（VB6 など）は AutoCheck プロパティが存在せず、しかたなく Enabled を False に設定しています。（これはどのコントロールにも言えることですが、読み取り専用であることがわかる画期的なユーザインタフェースが必要なのだと思います。）

ユーザの混乱を避けるには

　このように Enabled が False のチェックボックスには、二通りの解釈の仕方が存在してしまっています。これではユーザも混乱してしまうのではないでしょうか。

　そこでどうすれば混乱が避けられるのかを考えたのですが、いいアイディアが浮かびませんでした。徐々に「チェックボックスは無効」であると考える方向に統一することも考えたのですが、そう簡単にはいきません。しかし、これから作成されるアプリケーションは「チェックボックスは無効」である、という考えで作成されていけば、その考えも広まり統一できるのではないかと思います。

ControlStyles.Selectable を False に設定してもフォーカスが設定される場合がある

ダッチ — Tue, 26 Feb 2008 23:10:00 GMT

　ControlStyles.Selectable スタイルを False に設定すると、そのコントロールにはフォーカスが設定されなくなります。マウスでクリックしても、Tab キーを押してもフォーカスは設定されません。

フォーカスを受け取らないコントロール

Public Class ButtonEx
    Inherits Button

    Public Sub New()
        Me.SetStyle(ControlStyles.Selectable, False)
    End Sub
End Class

　しかし、次の処理を行った場合はフォーカスが設定されてしまうようです（この他にもあるかもしれません）。

Focus メソッド
Select メソッド
ActiveControl プロパティ

　Focus メソッドやコントロールを選択出来るかを判定する CanSelect プロパティには次のような内容が記載されています。

Control.Focus メソッド - MSDN より引用

コントロールは、一定の条件がすべて true の場合に、選択可能であり、入力フォーカスを受け取ることができます。一定の条件とは、ControlStyles の Selectable 値が true に設定されていること、コントロールが別のコントロールに格納されていること、およびすべての親コントロールが表示されており、有効であることです。

Control.CanSelect プロパティ - MSDN より引用

System.Windows.Forms.ControlStyles の Selectable 値が true に設定されていて、別のコントロールに含まれており、コントロール自体とすべての親コントロールが表示されていて有効である場合、このプロパティは true を返します。

　ControlStyles.Selectable の値が False の場合はフォーカスは受け取れないと記載されていますが、Control.Focus メソッドを使用するとフォーカスが設定されてしまいます。また Control.CanSelect プロパティは False を返すのですが、Select メソッドを使用するとコントロールにフォーカスが設定されてしまいます。ちなみに Control.CanFocus プロパティは True を返します。

　ControlStyles.Selectable を False に設定した時の動きがどうもしっくりきません。いかなる場合でもフォーカスが設定されないことを望んでいたんですが、簡単にはいかないようですね。