諦めていませんよ〜!!

自分は、人の二倍三倍、やる事が遅い。
必然的に、人の二倍三倍、時間を掛けなければ、結果が伴わない。
いや、結果が伴えば、まだ幸い。
それだけ時間を掛けても、まだ、とっかかり状態、だったりする... (^^;;;
ただただ、諦めが悪いだけで、なんとか、ここまで、続けてきている。

そんなこんなで、自分の中では、ずっとずっとROSeプロジェクトは継続中。
いつになったらファイルの読み書きが出来るようになるのか、自分でも分からないけど、
とりあえずは、今でも、それを直近の目標に、悶々と日々を過ごしている。苦笑

で、自分の過去記事など読み返しつつ、知識の整理をしていたりすると、
当時はそれで十分だったと思った記述が、まるで意味不明だったりする。
良くある事と言えば、良くある事... とも思う。
書いている本人は、色々と調べつつ試しつつ、記述している訳なんだけど、
それらの知識を前提にしつつ、要点を書き出しているような状態だ。
前提とした知識が抜けてしまった状態、もしくは、まっさらな状態で、
その要点だけを読んでみても、なかなか、その内容を理解出来るものでもないな... と。

とりあえず、ここでは、日記半分、記録半分なので、それはそれで良いとして、
まとめ方を考えていかないと自分でも読めない内容ばかりになってしまいそうだ。
要注意...

だからメーカー製は!!

現在、自分のところでは、主に二台のノートパソコンが稼働しています。
一台は、ひょんな事から貰っちゃった Dynabook で、過去にも色々と問題のあった子。
もう一台は、去年の頭に、ご乱心気味の勢いで購入した、Faith の重量級。
Faith マシンは、これまでも何台か購入していて、実にお気に入りなのである。
余計なソフトはほとんど入っておらず、見た目も渋く、オシャレさとは全く無縁。
客に媚びず、時代に媚びず、正に言葉通り質実剛健なマシンです。
まぁ、一般受けなんて、これっぽっちも考えていない、玄人向けの構成ですね。
だから良い。
これまでの歴代マシンも含めて、とにかく安定している。
PEN4時代の爆熱マシンだって、ちょっとやそっとじゃフリーズなんてしなかった。
それなのに... それなのに...
Dynaときたら、なんやかんやで、頻繁にフリーズするんですよ!!
やたら敏感な揺れ検出機能とか付いていたり、ＨＤＤプロテクションとか付いていたり、
何か起きた後に、付いてて良かった！って思う事もあるかもしれないけれど、
きっと、９９：１で、こんな無駄な機能は要らん！って思う事の方が多い気がする。

で、最近、何気なくネットを調べていたら、ありました。
こんな記事が。
「cymon.sysが原因と思われるブルースクリーン」
なんと、このドライバーが、諸悪の根源であった可能性が！
これが、プレインストールされている「BookPlaceReader」というソフトにくっついているらしい。
早速、アンインストール！
さて、これで安定してくれれば、万々歳なのだが...

VARIANTの文字列をByRefで渡す

SWTのVARIANT型を普通に使う分には、特に悩む事はないと思うのだが、
ByRef渡しのVARIANTを扱う際には、ちょっと不親切かも知れない。
プロトタイプ的には、

public Variant(int ptr, short byRefType)

なのであるが、ptr が指す先に、何を設定するかが問題である。
これがプリミティブ型であれば、

public void setByRef(int val)

だとか

public void setByRef(float val)

だとかがあるので、データサイズ分の領域をOS.GlobalAllocで確保してあげれば良いのだが、
文字列については、このようなメソッドが用意されていない。
とりあえず、ptr が指すアドレスから、NULL終端文字列を配置してみたが、これはＮＧ。
ならばと、同じタイプを戻り値とするメソッドを呼び出してみて、その中身を調べてみると、
どうも、ptr の指すアドレスにもポインタが設定されており、
文字列の実体は、その先に配置されているようだった。
しかし、同様にやってみたつもりでも、自分がやると、何故かＮＧとなってしまう。
何故だ？
結論から言ってしまうと、文字列の場合、ptr に設定すべき値は、
COM.SysAllocStringの戻り値であるアドレスとなるようだ。
一見、通常のメモリアロケートとなんら違いが無いように見えるが、
BSTRは、文字列データの前に文字列長が配置される構造となっており、
COM.SysAllocStringは、その領域を含めてアロケートを行っている。
戻るアドレスが、文字列データの先頭(文字列長データの直後)となっているので、
通常のNULL終端文字列を扱うように使えるが、実は別物という、曲者である。

そもそも、Javaで、アドレスを駆使するようなプログラムを書かなきゃいけない時点で、
何か間違っているような気がしなくもないのだが...

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 って事は、このクラス的には、それを意図しているわけだよなぁ...

むぅぅぅ。
もうちょっと分かり易い命名を... と思ったりするのだが...
まぁ、今に始まった事ではないが...