DirectCastはNothingで落ちるよ
Option Strict Off で
Text = obj
とやっていたところを
Option Strict On に変更した上で、
Text = DirectCast(obj, String)
などとすると、obj = Nothing の場合は、例外で落ちる。
これまでは、Text に Nothing が代入されていて、
それで動いていたのなら、これは、ちょっと痛い。
TryCastに置き換えるのが妥当なのか... う〜む。
とりあえずDirectCastにしておこう
自分のようなロートル・プログラマにとって、
BASICは、色々な意味で、愛着のある言語の一つである。
この言語は、ゲル・ゲイツのお気に入りとも、何かで読んだ気がするが、
特にマイクロソフトの処理系としては、
形を変えながら、今でも現役であるのは紛れもない事実である。
とは言え、これには、功罪両面あり、
その為に、色々と悩まされることもしばしばあったりする。
その一つが、キャスト。
元々、BASICがインタープリタの頃は、それほど、型に対して厳密ではなく、
せいぜい、文字列を数値に変換だとか、その程度でしかなかったように思う。
つまり、ValだとかStrだとか、その類である。
後に、コンパイラタイプやVisualBasicといった世代になってくると、
他の処理系と同様、コンパイラによる型チェックが厳密になり、
Optionの設定次第ではあるが、明示的な型指定をチェック出来るようになってくる。
そこでCIntやCStr及びCType等の型変換関数が導入されたと記憶している。
VB.NETでは、これらの型変換に加え、DirectCastが導入され、
同じような機能が複数あり、どれを使って良いのか分からなくなる。
基本的にBASICは、優しい処理系というイメージがある。
優しいと書くと語弊があるかもしれないが、とにかく努力はしてくれる。
対極はＣ処理系等だろうか？
ある意味、そっけないのである。
Ｃ処理系では、単純に変換出来なければエラー扱い。
対して、BASICは、可能な限り変換しようと努力する... みたいなイメージ。
ところが、これは、場合によっては、余計なお世話になる事もある。
特に文字列からの他の型への変換の際は、驚くべき結果を披露してくれる事も、ままある。
であれば、単純にエラーで落としてくれた方が良い時もある。
特に、これらが、実行時エラーでしか拾えない不具合である場合、
エラー検出を難しくしてしまう側面もあるからである。
まぁ、そんな事で悩むのであれば、もう素直にDirectCastを使うのが一番かな... と。
最近、同じ事を何度も調べたりだとか、検証した結果をすっこり忘れてたりだとか、
どうも自分の記憶力があてにならないのでメモしておく。
スプレッドの行に対応するデータソースの行
FpSpreadのシートは、SheetView - DataModel - DataSource という構成になっているようで、
それぞれの行数や順番は、必ずしも一致するとは限らない。
つまり、データの実体は、どこか一か所で、それ以外はインデックスだけ持ち、
例えば、表示上のソートは、SheetView上で行われるが、それ以外には影響しない。
データ自体を並べ替える訳ではない... というところがポイントか。
データのソートや追加・削除を行った後、
シート上の行位置を、そのまま、データモデルやデータソースに適用すると、
全く違った内容が返ってくる場合がある。
この場合は、適切なインデックス変換を行わなければならない。
SheetView <-> DataModel
GetModelRowFromViewRow
GetViewRowFromModelRow
DataModel <-> DataSource
GetDataRowFromModelRow
GetModelRowFromDataRow
シート上からデータソースの行を取得するには、
二段階の変換が必要となる。
.NET コレクション
keyとindexが使用できるコレクションは、OrderedDictionary。
名前空間は、System.Collections.Specialized
そのGeneric版と思われる物は、KeyedCollection ジェネリック クラス。
名前空間は、System.Collections.ObjectModel
でも、KeyedCollectionジェネリックは、微妙に違ったりもする。
KeyをItemから勝手に用意してくれるのは、ありがたい場合もあるが、
まったく関係ないKeyを使いたい場合、逆に邪魔な気もしなくもない...
しかし、MustInherits って事は、このクラス的には、それを意図しているわけだよなぁ...
むぅぅぅ。
もうちょっと分かり易い命名を... と思ったりするのだが...
まぁ、今に始まった事ではないが...
ファーストサーバー
ファーストサーバーの大規模障害。
同じ？業界に身を置く者としては、他人事ではない。
正直、これは、大惨事だと思う。
でも、いつかは起きるだろうなぁ... と思っていた事でもあるし、
案外、ここまでの規模ではないけれど、良くある事だったりするかもしれないし、
また、これからも、きっと、起こり得る事なんだろうな、とも思う。
自分だって、ちょっと前に、メインマシンのＨＤＤが壊れた。
とりあえず、ＨＤＤは保管して、サルベージを試みようとは思っているが、
現状、ＨＤＤの中身は、どうにもならない状態である。
知人の息子さんも、データを保存していた２ＴのＨＤＤが壊れたと相談してきた。
話を聞く限り、どうにもならないようなので、諦めて貰うしかなかったが...
個人ユースでも、数ＴのＨＤＤが、一万円前後で手に入る時代。
データも肥大化し、なんでもかんでも、とりあえずＨＤＤに放り込んで、
気が付けば、玉石混淆、とにかく管理しきれないくらいデータが詰まっているのだよ！状態。
そんなデジタルなデータが、半永久的に、保護保管される道理もなく...
いつかは壊れる時が来るわけですよ。
壊れた理由はともかく、いつまでも正常な状態が維持される事はないと。
そんな当たり前な事、言われなくても分かっているさ... 分かっていたつもり...
バックアップは大事だよ〜！！
そんな事も、言われるまでもないさ... と思っていた。
でも、現実問題、そんなこまめにバックアップなんて残さないでしょ？
ってか、残せないに近い？
後悔先に立たずで、後から思えば、なんて事は毎度の話だけれど、
じゃぁ、具体的に、どうすりゃ良かったのかって考えると、
現実的な解として、なかなか、これだって言える手順なり手法なりが思い浮かばない。
いや、面倒くさがらずに、手間暇掛ければ良いわけなんだけど...
極端な話、停電になったら、何も出来ないわけだよね...
そりゃ、それを言ったら、身も蓋もないわけだけど。
とにかく、そういう、大きなリスクを抱えているって事は、事実なんだと思うんだ。
