何か創りたい。
http://toshirr.blog13.fc2.com/
* Toshi's Recess Room - Toshi Creates. - 2008年02月 の記事 /
<< 2008/01 - 2008/02 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 - 2008/03 >>

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

[ No. ]
[ 日時 : --/--/-- (--.) --:--:-- ]
[ カテゴリ : スポンサー広告 ]


段落(BlogPet)

きょう、段落へ要約するはずだったみたい。

*このエントリは、ブログペットの「Overhand」が書きました。
スポンサーサイト

[ No. 675 ]
[ 日時 : 2008/02/29 (Fri.) 07:58:44 ]
[ カテゴリ : BlogPet / 未分類 ]
[ コメント : 0 ]
[ トラック バック : 0 ]


RichTextBox の扱い

作ろうとしているのはプレーン テキスト エディタであり、RTF エディタではありません。
というか RTF の需要が私にはありません。
しかし、TextBox ではなく RichTextBox を使おうと思います。機能的に充実していそうだからです。
でもやっぱり選択範囲の色を変えたり太字にしたりという RTF な機能は付けません。

で、RichTextBox は何かとじゃじゃ馬なところがあり、フォントがいい例だと思いました。
Font プロパティに日本語のフォントを指定しても、英字を入力すると明らかに Arial に見えます。
MSDN で探せばありました、LanguageOption プロパティ。これを AutoFont にすれば、ひとまず解決。

他に気付いたところでは、IME をオンにして何か入力して、
未確定のまま Esc しても TextChanged イベントが来ます。
そういうもんだと思って気にしてませんが、TextBox との違いは思ったより深いですね。
RichTextBox の扱いには注意した方が良さそうです。

あと実装したいと考えている機能に、カーソル位置の行・桁のリアルタイム表示があります。
KeyDown イベントはカーソル位置が内部的に更新される前に来るようなので使い物にならない予感です。
カーソルが移動した後を検知するイベントもないようなので、
これは Win32 伝家の宝刀、サブクラス化様にお出ましいただくしかないのでしょうか。

それは遠慮したいところですが、そういう方向に行かないと無理っぽいので若干ネガティブに。
とにかくやってみます。

[ No. 674 ]
[ 日時 : 2008/02/28 (Thu.) 23:43:46 ]
[ カテゴリ : プログラミング ]
[ コメント : 0 ]
[ トラック バック : 0 ]


関連のあるものは関連付ける

テキスト エディタ、いよいよ実際のタブの作成の部分に手を伸ばします。

タブそのものに関する情報を格納するクラスの一つ一つのインスタンスと、
フォーム上の TabControl の持つ TabPages コレクションに格納される TabPage クラスの
一つ一つのインスタンスは密接であるべきです。一対一で対応しているからです。
こういうとき、それぞれを別々に管理してしまってあらぬミスを生む必要が無いように、便利なものがあります。

TabPage クラスの派生元 Control クラスが持つ Tag プロパティです。
Win32 でいえば、GetProp API などの土俵であるウィンドウ プロパティや GWL_USERDATA にあたります。
これは object 型なので、どんなものでも入ります。ここにタブそのものに関するクラスを入れましょう。
どちらもまとめて管理することができますね。

こういった部分が行き届いている .NET Framework、非常に楽です。

しかしまあ IDE はどうにかして推奨動作環境の水準を下げてくれないものでしょうか。
終了に 1 分ぐらい待たされることもあります。
でも無理でしょうね...。

[ No. 673 ]
[ 日時 : 2008/02/27 (Wed.) 21:28:34 ]
[ カテゴリ : プログラミング ]
[ コメント : 0 ]
[ トラック バック : 0 ]


Main が複数あったとき

C# では、エントリ ポイントは何かのクラスにある Main という静的メソッドと定められています。
じゃあ、クラスを二つ作ってどちらにも Main という静的メソッドを定義したらどうなるでしょう。

コンパイル エラーになります。
コンパイラは、どちらの Main メソッドをエントリ ポイントにしたらいいか分からないからです。

こういう場合は紛らわしくならないように、エントリ ポイントにしないメソッドには
極力 Main なんて名前を付けなければいいのですが、どうしても Main と名付けたい場合、
コンパイラのコマンド ライン オプション /main を利用します。具体的には、
プロジェクトのプロパティ - [アプリケーション] - [スタートアップ プロジェクト(O):] から設定します。

C# を勉強し始めた当初から気になっていたことですが、解決しました。
でも基本的にはこんなこと考えなくてもいいように、
やっぱり Main メソッドは複数作らないようにした方がいいですね。

ちなみに大文字小文字を区別するので、main メソッドならエラーになりません。

C# ならではの疑問でした。

[ No. 672 ]
[ 日時 : 2008/02/26 (Tue.) 22:49:00 ]
[ カテゴリ : プログラミング ]
[ コメント : 1 ]
[ トラック バック : 0 ]


総称性

ジェネリクス・ジェネリックス・ジェネリックと呼ばれている概念です。
詳しいことは専門的な解説をしているサイトを参照してください。
要約すると、何と言ったらいいのか、型の安全性を保つための機能。
危ない型キャストを食い止めてくれる、という説明で合っているのかもしれません。
細かいことは分からないにしても、利便性は分かります。

System.Collections.ArrayList より System.Collections.Generic.List を使っていこうと。
ArrayList は object 型を持つが故に型に関して不安な部分を残しますが、
List なら型を限定して持つことができます。無用な心配は杞憂です。

それでもって高校最初の学年末テスト期間が迫っています。
ガンバりますというか、努力します。

[ No. 671 ]
[ 日時 : 2008/02/26 (Tue.) 20:39:23 ]
[ カテゴリ : プログラミング ]
[ コメント : 0 ]
[ トラック バック : 0 ]


Toshiは呼吸したの(BlogPet)

きのうOverhandが、Toshiと公開するはずだったの。
それできのうOverhandが、Toshiは呼吸したの?
だけど、Toshiで環境へ大別されたみたい…

*このエントリは、ブログペットの「Overhand」が書きました。

[ No. 670 ]
[ 日時 : 2008/02/22 (Fri.) 07:34:40 ]
[ カテゴリ : BlogPet / 未分類 ]
[ コメント : 0 ]
[ トラック バック : 0 ]


partial があるのは

イベントの処理を別ファイルに~云々~の問題ですが、
結局イベントを元のファイルに収めることで解決としました。

そんなんでいいのか?
まあいいでしょう。よく考えるとそのためのファイルでもありますし、やはり IDE との連携もありますし。

フォームに関すること、フォームにしてみたら自分に関することは自分でやるのが筋、であると。
それだけなら partial で分離すれば済んだのですが、ソリューション エクスプローラ上の表示と、
ファイルに対する IDE の動作をどうしても変更できなかったので、ここは妥協します。
でもスマートな解決方法があればそれを実践したかったところです。

そして C# は、C++ のようなヘッダという考え方が無く、
P/Invoke の宣言やそれを利用する部分を分離しようという考えもちょっと反するかなと思い、
宣言と定義や使用を一つのファイルにまとめることにしようと考えます。
アウトライン機能もあるので躊躇はありません。

今まで partial partial と叫んでポジティブに使っていくような姿勢でいましたが、そもそも
大規模なクラスの開発時や、デザイナが自動生成するコードとプログラマが手動入力するコードの切り分けが
partial を partial としての存在たらしめる存在意義であることを今認識しました。

てなわけでポリシーに則ったプログラムを書いていきます。

[ No. 669 ]
[ 日時 : 2008/02/19 (Tue.) 22:56:43 ]
[ カテゴリ : プログラミング ]
[ コメント : 0 ]
[ トラック バック : 0 ]


イベントの処理を別ファイルにした際の問題

前回の記事で編み出したイベント処理の別ファイルへの分割。
コード上は何ら問題ないものの、IDE 上でちょっと困ったことが発生しました。

前回の記事の通り、別ファイルに記述するイベント処理のコードは、
元々のイベント コードと全く同じ名前空間、クラスに属するメソッドとして書いています。
すると、ソリューション エクスプローラ上でのそのファイルに付いているアイコンが
普通の C# コード ファイルのものではなく、フォームのアイコンになっていたのです。

元々のイベント コードを記述したファイルもフォームのアイコン。
これは、コード内に System.Windows.Forms.Form を継承したクラスが存在することで
「このファイルはフォームに関するコードが書いてある」と IDE が認識するため、のようです。
属するクラスを同じにしたので、別ファイルの方もそうであるとみなされたのでしょう。

これだけならまあアイコンが違うという話で済みますが、ここからが問題。
ソリューション エクスプローラで別ファイルの方をダブルクリックすると、
先述の理由から IDE の判断によってフォーム デザイナが開かれてしまうのです。

フォーム デザイナを開いてほしいのは元々のファイルだけなので、
別ファイルは直接コード エディタを開いてほしいところですが、こうなってしまいました。
では、コードの記述を変えずに別ファイルを単なるコード ファイルと認識させるには
どうすればいいのでしょうか。

一つ試してみたのが、ソリューション エクスプローラ上で別ファイルを右クリックし、
[ファイルを開くアプリケーションの選択(N)...] をクリックし、
そこで [CSharp エディタ] を既定のエディタに設定する方法。
元々は [CSharp フォーム エディタ] だったのですが、これで直接エディタが開くようになります。

ところがこれは「ファイル毎の設定」ではなく「ファイルの種類毎」の設定のようで、
この設定にすると「フォームに関するコードが書いてあるファイル」という種類のファイルの
全てに対して適用されてしまうため、元々のファイルもエディタで開くようになってしまいます。
まあ元々のファイルをデザイナで開きたいときだけ、右クリックして [デザイナの表示(D)] を選べば
いいのでしょうが、ちょっと妥協です。もっとスマートな方法が無いか探します。

また試してみたのが、.csproj ファイルを直接編集し、
別ファイルをただのコード ファイルとして IDE に認識してもらうようにする方法。
ところが、それっぽいところを編集してみるものの、IDE で開くと勝手に元に戻されます。
やっぱりコード内を解析しているようです。

では、コードの中身を変えるのはどうでしょうか。
中身を変えた上で .csproj ファイルを編集し、IDE にただのコード ファイルとして
認識してもらえばいいのです。つまりメソッドを別なクラスにしてしまうのです。
System.Windows.Forms.Form を継承しないクラスにすれば、おそらく IDE もちゃんと認識してくれるはずです。

その状態で、フォームにある MenuStrip やその他のコントロールを名前空間や親クラスからの参照無しに
コードに書ければ解決します。ですが今のところ難しそうです。

更に、コントロールの Modifiers プロパティが Private だと他のクラスからアクセスできません。
このために Public に変更するのも若干腑に落ちないところがありますし、仮にそうしてアクセスするにも、
クラス名.コントロール名 のような書き方をしなければならないのです。

コントロール名だけを書いてアクセスしたい、更に Modifiers は Private のままにしたいなら、
やはり同じクラスのメソッドとして実装しなければなりません。となるので、

別ファイルでも結局同じクラスのメソッドとして実装し、ダブルクリックしてもデザイナが開かないように
[CSharp エディタ] を既定のエディタにし、デザイナを開く場合は元のファイルを右クリックして
[デザイナの表示(D)] をクリックするという妥協案に甘んじるしかないのかもしれません。

同じクラスのメソッドにしつつただのコード ファイルとして認識させるのが最良ですが、
その方法が見つからない限りはこうするしかなさそうです。

どうしても納得がいきそうにないです。

[ No. 668 ]
[ 日時 : 2008/02/14 (Thu.) 20:37:06 ]
[ カテゴリ : プログラミング ]
[ コメント : 2 ]
[ トラック バック : 0 ]


イベント コードの別ファイルへの分離

しばらく VC# on VS2008Pro でテキスト エディタ開発のネタが続くかと思います。

フォーム デザイナから作ったイベント コード、後々増えていくでしょう。
すると一つのファイルにずらずらその処理が書かれていくわけで、精神衛生上異議ありです。
じゃあ別ファイルに分離しようという運びになります。

じゃあ、イベント コードそのものを別ファイルに分離しようかと思うとどうやら問屋は卸さないようです。
一応はフォーム デザイナの管轄下であるファイルなので、そこに書かれていたものをどっかへ持っていくのは
気が引けるものです。なので、別ファイルには実際の処理だけを分離して、
イベント コードからそれを呼び出すようにします。

このとき、イベント コードに処理を書くのと同じ感覚でコードが書けるよう、
別ファイルのコードもイベント コードがある名前空間、クラスと全く同じレベルのメソッドにします。
必然的に partial class です。じゃないとそのコード上でクラスなどの名前を書くとき、
相対的な名前の指定ができないので、冗長的になってしまいます。

そしてメリットがまだあります。
MenuStrip と ToolStrip に、同じ役割を持つ ToolStripMenuItem なり ToolStripButton なりを置いて、
それぞれの Click イベントでさあ処理をしようとすると、同じ処理を書くことになります。
じゃあ関数作って呼んじゃえばいいじゃん、てなわけで、
処理の統一という視点からもこのファイルを分割する方法はなかなか有効なようです。

デザイナを使わずに書けばそんなこと気にしなくてもいいのですが、
デザイナを使ったときのメリットが半端ないので、デザイナが書いたコードと仲良く共存し、
その隣で自分がコードを書いていく、その手立てを思案し、実行していきたいものですね。

[ No. 667 ]
[ 日時 : 2008/02/13 (Wed.) 22:43:49 ]
[ カテゴリ : プログラミング ]
[ コメント : 0 ]
[ トラック バック : 0 ]


機能(BlogPet)

きょうは、機能するつもりだった?
だけど、きのう、Toshiのレシーバーっぽい反応したいなぁ。
それで表示したいなぁ。

*このエントリは、ブログペットの「Overhand」が書きました。

[ No. 666 ]
[ 日時 : 2008/02/13 (Wed.) 08:20:00 ]
[ カテゴリ : BlogPet / 未分類 ]
[ コメント : 0 ]
[ トラック バック : 0 ]


便利すぎる

C# で Get / SetWindowPlacement を呼び出してみました。P/Invoke (プラットフォーム呼び出し)に依ります。

static partial class WindowManager
{

static public bool SavePosition(Form f)
{
WINDOWPLACEMENT wp = WINDOWPLACEMENT.Default;
GetWindowPlacement(f.Handle, ref wp);
/* ... */

return true;
}

static public bool LoadPosition(Form f)
{
WINDOWPLACEMENT wp = WINDOWPLACEMENT.Default;
/* ... */
SetWindowPlacement(f.Handle, ref wp);

return true;
}
}

必要な宣言はまた別なファイルの static partial な class WindowManager の中で行っておけば、
こっちには実装のみを書けるのでスッキリします。

必要な宣言は pinvoke.net から引っ張ってきました。こちらのサイトにある宣言集は実に便利で、
Win32 API の RECT 型と System.Drawing.Rectangle 型の間を取り持ってくれます。
最初はメンバ毎にコピーする必要があるかなと思っていたら、あっさり丸ごとコピーできました。

更に驚きがありました。
wp に WINDOWPLACEMENT 構造体を new して、length を Marshal.SizeOf(wp) で埋めようとしたところ、
WINDOWPLACEMENT 構造体の静的プロパティである Default が、
既にそれをやった上での構造体を返してくれるらしく、これまた非常に便利だなと思ったところです。

.NET で Win32 API を呼ぶのに抵抗が無くなりますね。
むしろどんどん活用していきたいところです。.NET ではできないという部分で。

IntelliSence は面白いですね。
数文字入れて Enter 押してピリオド入れて Enter 押してピリオド入れて Enter 押して、
ピリオド入れて上か下押して Enter 押して、て感じでスイスイ行が文字で埋まっていきます。

他にも、
・リアルタイムで波線引いてエラーを教えてくれる機能(分かりやすい)
・セミコロン入れたらイコールの左右にスペースを入れてくれることに始まるフォーマット機能(書きやすい)
・プラスとマイナスが長いコードをまとめてくれるアウトライン機能(もはやエディタの域ではない)
・BMP だろうが JPG だろうが GIF だろうが PNG だろうがリソースに取り込める(困りようがない)
・フォームをデザインしまくりな大量のフォーム デザイン機能(多すぎて書けない)
・かゆい所に手が届くコントロールのプロパティ(かゆい所が見つからない)

至高ですね。軽いなら。

[ No. 665 ]
[ 日時 : 2008/02/12 (Tue.) 21:37:32 ]
[ カテゴリ : プログラミング ]
[ コメント : 1 ]
[ トラック バック : 0 ]


代替方法が無い時

昨日から C# on VS2008 にてテキスト エディタを作ってみようという目標の下目下奮闘中です。

フォーム デザイナで UI を構築する作業。
コードをひたすらに書くよりも簡単なのは自明ですが、にしても
メニュー バーなどの WYSIWYG っぽい編集は便利になったものですね。
大体の形づくりを終えて実行して確認し、次に取り掛かるはウィンドウ位置の保存と復元。

なんでも .NET では、「ウィンドウ位置などのプロパティをアプリケーション設定にバインディングできる」。
端折ると要は、プログラマが「このプロパティを保存しておけ」と IDE 上で指定しておくだけで、
自分でコードを書く手間がかなり削減され、保存と読み込みをよろしく任せておけるようです。
早速やってみます。

確かに保存と復元はされますが、自分の望んでいるものとは違いました。
ウィンドウ サイズが固定のアプリケーションなら有効ですが、可変の場合、話が違います。

そういうアプリケーションはほとんどの割合で最大化も可能になっています。
それで実際、最大化されていないウィンドウを最大化し、その状態で終了させて、また起動したとき、
ユーザーの望む挙動はどのようなものでしょうか?

まず間違いなく、再び最大化された状態で起動されることを期待します。
更に最大化を解除した場合、「以前起動したときの最大化されていない状態の位置とサイズ」も
再現されていることを期待するでしょう。

ところがしかしですがだけれども、.NET の提供している手段ではこの挙動の実現は不可能でしょう。
「最大化されていない状態の位置とサイズ」というものは、「最大化された状態」では得る手段が無いからです。

Win32 API のネイティブなアプリでは、GetWindowPlacement / SetWindowPlacement API がそれを担います。
(実際はこれを利用していないアプリもあるようですが、大概は利用されています)

この問題の解決法は、この 2 つの API をダイレクトに呼ぶ、ということになります。
.NET でもできないことだってあるという認識はありましたが、
ここらへんの挙動ぐらいは実装してくれたら楽なのに、という思いです。

.NET のことを書くとネタが尽きそうにないので、しばらくこのブログは
.NET 備忘録・メモその他貯蔵庫になりそうです。日に二回以上更新することもあるやも知れず。
それなりの時間を見つけたうえで、で。

[ No. 664 ]
[ 日時 : 2008/02/11 (Mon.) 13:46:55 ]
[ カテゴリ : プログラミング ]
[ コメント : 0 ]
[ トラック バック : 0 ]


まず触れてみること

Microsoft Visual Studio 2008 Professional Edition アカデミックが届きました。
大規模な製品なだけあってインストールが長いのなんの、でも異常なく完了。

こうなったら何か触れなければ意味がありません。
とりあえず .NET で何が出来るかを試したいので、テキスト エディタを開発することにしました。
王道の中の王道の中の(中略)王道ですが、
やっぱり未知を既知に変えるにあたって非常に分かりやすいのが大きいです。
これに味を占めて発展させていければいうことなしです。

で、Visual Studio 用の MSDN ライブラリがあるわけですが、日本語の記事が揃ってて、
中身も充実してたので読み物としても利用できる内容になってます。

でもそのあまりの量に動作がもっさりしてます。
XP で 512 MB のメモリがあればまあ足りると思ってた時代でしたが、最新の開発環境を前にしては
さすがに限界を突き付けられた感じでしょうか、HDD もせわしなく動いています。仮想メモリは切れないです。

これから何年と付き合っていくであろう Visual Studio でしょうから、大事にします。

[ No. 663 ]
[ 日時 : 2008/02/10 (Sun.) 22:15:59 ]
[ カテゴリ : プログラミング ]
[ コメント : 1 ]
[ トラック バック : 0 ]


V.S. 冬

御無沙汰しております。何かとイベントが絶えない日々であるが故に、
生存の報告代わりになっているこのブログを放置してしまっていました。申し訳ないです。

今は二月です。冬の寒さが留まるところを知ってくれません。知ってほしいです。
自転車通学ですが、登校時は時間制限があるので、寒くてもどうにか颯爽と走っていけます。
といえるのも雪が減ってきたこの時期ならではなことであり、
雪がどっさり残ってたり氷が日の光を浴びてたり、中途半端に凍った雪、中途半端に融けた雪、
水と混ざってシャリシャリと進路妨害の音を立てる雪、などを目にしてしまった以上は、
どうしてもペダルの回転作業を躊躇せざるを得ません。難しいものです。
ところが雪が減ってしまえば、夏場と同じ顔をしたアスファルトが走れといわんばかりに広がっています。
これならまず「転倒の危険」を避けることができるわけです。

ですけれども、問題はここまでで終わりません。
走行のしやすさは確保されたものの、前段落の冒頭、「冬の寒さ」はまた違ったダメージを与えてきます。
これは下校時の問題になってきます。下校時はとりあえず帰宅できれば時間は気にしません。
じゃ、ゆっくり安全最優先、左側通行で車通り極少なロードを行こうと決意、
と、ここでうっかり素手で相棒のハンドルを握って走ろうとすれば、モロに冷風が指に刺さります。
空気が途轍もなく冷たいのです。
口呼吸だろうが鼻呼吸だろうが呼気はホワイトテイストに様変わりするような気温の低さです。
信号待ちで止まっているときは多少マシですがそんなの関係ありません。
じゃあこんな凍えるようなところに長くいられるかこの寒波め、と文句の一つでも付けて、
速度を上げて一刻も早く帰宅しようとすればするほど奴らの速度も上がります。
当たり前です。向かい風に向かって走れば、体感上の風速は自分の速度の分だけ上昇します多分。
早く帰ろうとすればするほど寒さが増すという説明のできない葛藤、
結局それなりのスピードでそれなりの寒い思いをしつつブレーキをかけることになります。

要するに、早く春が来てほしいです。

[ No. 662 ]
[ 日時 : 2008/02/04 (Mon.) 23:29:00 ]
[ カテゴリ : 学校ライフ ]
[ コメント : 2 ]
[ トラック バック : 0 ]


プロフィール

Toshi

  • Author:Toshi
  • 何かを創りたい Toshi の記録


ブログ内の検索


最近の記事


最近のコメント


最近のトラック バック


カレンダー

01 | 2008/02 | 03
- - - - - 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 -


月別の記事


カテゴリ別の記事


RSS フィード


<< 2008/01 - 2008/02 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 - 2008/03 >>
* Toshi's Recess Room - Toshi Creates. - 2008年02月 の記事 /
http://toshirr.blog13.fc2.com/
(C) 2005 - 2009 Toshi, All Rights Reserved.

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。