バイク日和だなーってことで、バイク通勤。旧17号−明治通りにはまだ慣れていないからか、ぼーっとしているとすぐに曲がり角を間違えてしまう。といっても、曲がる場所は17号→明治通りくらいしかないんだけど。あと、多少混んでいるのはあきらめるとしても、せめて池袋の駅前だけは通らないルートを開拓したいなー。あそこはバスとタクシーとがぐちゃぐちゃになっていてとても気持ち悪い。

むかつく動きをするやつらが（東京近郊では特に）多いタクシーだけど、むかつく動きの一つとして車線またぎがある。2車線（以上）ある道路の車線をまたいで、追い越し車線のスピードは維持しつつ、客がいたらいつでも停まれるように通常車線に半分はみ出しながら走る、というもの。「この道路はおまえの専有物かよ」とツッコミたくなる。

今日は車線またぎタクシーのせいで狭くなっている通常車線から抜く際に、わざとタクシーの前ぎりぎりに（車線内で）近づきながら抜いていってみた。バックミラーで確認すると、そうやって抜かれたタクシーはその後きちんと追い越し車線からはみ出さないように走っているようだった（3台確認）。こうやって無理矢理戻してやるのもいいもな。

とかいいつつも、バイクはタクシー以上にアヤシイ動きをするやつらが多いから、言い合いを始めると五十歩百歩なんだけどね。俺はバイクにしてはまともな運転（比較的車っぽい運転）をする方だけど、それでも車からしてみればじゃまくさい動きが多いんだろうし。ただ、あまりにもがちがちに車っぽく運転しているバイクは、それはそれで危険（車に混じって走り続けるよりも車の前に出た方が安全）だからなー。

ascxコントロールは、Webコントロール（カスタムWebコントロール）などの部品群とは似ているようで違う。Pageletという別名がその実体をかなり正確に表現している。

Webコントロールは独立したオブジェクト（部品）としてきちんと扱える。ページ上に配置することで、ページ上のコード（コードビハインド）からWebコントロールに直接アクセスすることができる。

しかし、ascxコントロールは一見独立したオブジェクトのようにみえるが、その実質は親ページの一部として組み込まれるincludeファイルのようなものだ。だからWebコントロールのように、親ページからascxコントロール（のオブジェクトポインタ）は見えない（自分で宣言文を書いてもダメ）。

しかし、コードからascxコントロールのプロパティを設定できないのでは困るので、いろいろ試してみたところ、Pageのコードとして、

CType(FindControl("Form1").FindControl(コントロールのID),コントロールの型)

と表現することで、ascxコントロールにアクセスできることがわかった。かなり面倒くさい（というか醜い）表記だが、これでascxコントロールのプロパティやメソッドを呼ぶことができる。

しかし、ほかにも問題がある。それはイベントハンドラの実行順の問題だ。ascxコントロール内に記述するPage_Loadなどのイベントは、ascxコントロールのLoadイベントというよりは、親ページのPage_Loadの一部のようなものだ。たとえばPage上にascxコントロールCtrlA、ascxコントロールCtrlBの二つをおいた場合、各標準イベントハンドラが呼ばれる順番は、

• CtrlA_Init
• CtrlB_Init
• Page_Init
• Page_InitializeComponent
• Page_Load
• CtrlA_Load
• CtrlB_Load

という順番になる。ページ内にある複数のascxコントロールの同じイベント（たとえばPage_Load）が発生する順番は、Page（aspx）内に記述されたascxコントロール（<uc1:〜>）の順番通りになっているようだ（特に保証はないが、試してみた限りではそうなっている）。

ここで問題なのは、Initはascxコントロールの方が先なのにもかかわらず、LoadはPageの方が先になっている点だ。Page_Loadでコントロールのプロパティを設定したとしても、その後のCtrl_Loadにプロパティ初期化コードを書いてしまうと、Pageからのプロパティ設定は無効になってしまう。そのような使い方の場合、ascxコントロール内でのプロパティ初期化処理は、Ctrl_Initの方で実行しなければならない。

しかし、その逆の使い方をしたい場合もある。ascx側で親ページのPage_Load処理の結果によって、自分自身の初期化処理を変えたい場合だ。その場合は、Page_Loadのあとに呼び出されるCtrl_Loadでascxコントロールの初期化処理を行う必要がある。

つまり、ascxコントロールおよびPageにおける初期化処理は、その初期化処理の結果が相互にどのように関係するかを考えつつ、適切な実行順序になるよう記述するイベントハンドラを割り振らなければならないことになる。

具体的にいうと、ascxコントロールの初期化処理において、その結果がPageに影響を与えるような内容はCtrl_Initに記述し、逆にPageから影響を受けるような初期化処理はCtrl_Loadに記述すればいいことになる。Page側のイベント実行順序は、Page_LoadもPage_InitもCtrl_InitとCtrl_Loadに挟まれているので、ascxコントロール側の記述場所さえ守ればどちらに書いてもかまわない。

※現象に関する記述はあっているはずだけど、現象の理解（解釈）に関する記述は間違っている可能性が高い。と一応補足しておく。

Norton AntiVirus 2002の購読サービス期限が切れたので、SymantecのWebサイトでオンライン更新。2000円＋税。

前に何かのメンテナンスをしたときに、うっかりnewlist(非gz圧縮版)を更新するスクリプトを止めてしまっていたらしい。自分ではmylistしか使わないから全然気づかなかったけど、昨日見たらnewlistの最終更新が4月で止まっていた。んであわてて復活させた。

ちなみにtextmaniaでは情報収集スクリプトを複数非同期パラレルで動かしつつ、DB上でデータを更新していって、これまた非同期に適当な間隔をおいて静的なnewlistを生成しています。mylistとかsearchとかでは直接DBの最新情報を見ているんで、そっちをメインに使っているとnewlistが更新されなくても全然気づかないわけですね。

VisualBasic.NETのカスタムコントロールなどでColorをプロパティとして使う場合のTIPS。

VisualBasic.NETでは、色要素はColor型の構造体（でもColor型にはメソッドがあるよ。これってClassなんじゃないの？　VisualBasic.NETの構造体って特殊なのか？）として利用される。構造体なのでNewする必要はない。初期化は「Color.FromName(色名)」なんて感じで行う。

プロパティをColor型として宣言しておけば、自動的にColor型としてコードに組み込まれるので、それをそのままwebコントロールのColor系プロパティに代入（したり、フロント側で「色プロパティ='<%# 色プロパティ名 %>'」と書いたり）することができる。しかし、.netの世界ではColor型が標準かもしれないが、.netの世界で完結してwebアプリケーションを作るのは難しい。なんかかんか言って、昔ながらのaspみたいにhtmlタグをハードコードする必要が頻繁に出てくる。

で、そういうときにはColor型プロパティをhtmlタグに文字列として埋め込む必要が出てくる。そういう場合、「Color.ToString」としたくなるけど、これは間違い。「Color.Name」って表現の方が、html的な意味での色を表現する文字列となる。フロント側で「<%# 〜 #>」を使って、いろんなプロパティに値を埋め込む場合、webコントロール系のプロパティにはColor型のプロパティを直接「<%# Color #>」なんて埋め込むことができるが、htmlタグのプロパティ部には「<%# Color.Name #>」と書かないと意図した色にならない（具体的には「Color {色名}」なんて文字列になってしまう）。

同様にFontSizeみたいなプロパティもIntじゃなくてFontUnit型Classとして扱わなければいけなかったりする。htmlタグと混在してwebコントロールを利用するような場合は、意識しておかないと混乱するよ。

* 追記

と書いてからさらにいろいろやってみたところ、やっぱりプロパティとして直接Color型を用意するのはいろいろ問題があるな。今作っているコントロールでは、コントロールをパラメタライズする手段として、コントロールのプロパティに直接（あるいはコードから）指定する方法＋XMLデータを使ってパラメタライズする方法、という二パターン用意しているんだけど、上記のやり方でうまくいくのは後者のXMLから文字列データを受け取って明示的に（コードで）Color型に変換してからプロパティをセットする場合だけだった。

Color型のプロパティを宣言して、直接プロパティに（aspxファイル内などで）Colorをセットしようとすると、うまくいかない。「Color="white"」なんてやったのではもちろん「"white"」はString型だから、暗黙の内にColor型に変換なんてできるわけもないのでエラーが出る。また、面倒くさく「Color='<%# System.Drawing.Color.FromName("white") %>」と書くと、エラーは出ない（内部的にはきちんと代入できている）にもかかわらず、なぜかコントロール側のコードでその値にアクセスできない。

というわけで、コントロールでColor型のプロパティを使いたい場合は、プロパティとしてはString型の「ColorS」なんてものを定義しておいて、さらにそれをColor型に変換するために

readonly property ColorC as Color
get
return Color.FromName(ColorS)
end get
end property

も用意し、文字列が欲しいときは「ColorS」、Color型が欲しいときは「ColorC」と使い分けたりするのが一番無難かも。

定期の打ち合わせ。せっかく減少方向に転じた（と信じていた）のに、昨日は再び5時間半コースだった。それだけかかるという覚悟が足りなかったせいか、後半2時間くらいは脳みそがしびれてろくに頭が働かなかった。っつーか、あと1週間しかないんだから、そろそろこんなことをやっているバヤイじゃないんだけどな。

ときどき仕事用のデモマシンとしても使っているVAIOノートSRX7だけど、さすがにMS系の開発環境をつっこむとメモリが足りないな。256Mあれば通常用途では十分だと思っていたけど、やっぱり384Mバイトまで増設しておくべきか。でも既存の128Mバイト捨てるのもバカらしいしな。

昨日は会社を早めに終わって久しぶりに麻雀。結果としてはまた員数合わせって感じな3着、2着、3着で-30くらい。それにしても（俺にとっては）いやな麻雀だった。最初の半荘から、つもり四暗刻（リーチ三暗刻ドラ3）なんてのを空振る人がいてちょっとどきどきしたんだけど、半荘2回目は大三元、半荘3回目は数え役満（リーチ、ツモ、メンホン、イーペイコウ、中、ドラ3、裏ドラ3）が出て、結局半荘2回は役満一発で勝負が決まってしまった。役満が出るまではみんな微差でトップを争っていたのに。特に半荘3回目はオーラスの親で4000点差をつけてトップ状態から一発でまくられついでに親っかぶり16000点で一気に3着まで落とされるし。

先週の土曜日に注文していたパソコンラックと棚が届いたんで、朝からばたばたと部屋の模様替え。ファックス台代わりの棚の陰に（ムスコから）隠して置いてあったサーバー類を新しいパソコンラックに移動し、ついでにADSLモデムやハブや無線LANの配線もまとめ直した。これで、ハブを100Mスイッチングに変えたり、UPSを用意したり、サーバーのHDDを二重化したり、って作業がやりやすくなるな。もう一個の棚の方も収納力がかなりあるんで、今まであちこちの棚に強引に詰め込んであったものを、きちんと整理することができた。ずいぶんすっきり。

で、引っ越しの際に小さな本棚一個分まで圧縮しておいた本も、引っ越してから半年ちょっとで本棚からあふれまくりやがっていたので、再び整理。半分くらいを処分品として抜き出す。という作業をしていたところ、この間俺が買ってきた森岡 浩之「夢の樹が接げたなら」をようやく読んだオクサンが、「まだ読んでいない「星界の○○」シリーズは捨てないでね」と言ってきた。SFを読まないうちのオクサンも興味を持ったってことは、「夢の樹が接げたなら」は十分一般人にとっても面白いできだってことだろうな。ただし残念なことに、「星界の○○」シリーズはすでに前回の引っ越しの際に処分済みだったらしく、見あたらなかった。くそ、俺ももう一回読み直したくなったのに。