どうもはかばかしい進捗がない．Shirley（VAIO 4インチミニノート）はむちゃくちゃ遅いし，Tamoz（3インチタブレット）はタッチペンを使わないと誤動作するくらい文字が小さい．Tamozはそこそこ動いてくれるが，唯一の32bitCPUマシンであるShirleyは泣きたくなるほど遅い．どこかで中古品を見つけてきたいくらいだがともかく辛抱して使うしかない．32bit/64bitというのが問題になっているが，一つ勘違いしていたことがある．32/64という区別はOSの場合とCPUの場合があるという点だ．つまり，32ビット機と言ってもOSが32ビットでCPU64ビットということがある．64ビット機というのは概ねOS64ビット，CPU62ビットと考えて間違いないと思われるが…
これまで確認した限りではVisual Studio 2017でビルドしたパッケージはCPU62ビット機では「ソリューションプラットフォーム」の設定如何に関わらず動作するが，CPU32ビット機では「ソリューションプラットフォーム」の設定如何に関わらず動作しないという状態になっているように思われる．この点を確認するためにはどうしてもCPU32ビット機というのが必要になってくるが，現状唯一のCPU32ビット機であるShirleyは遅過ぎてほとんど使いものにならないというレベルだ．タスクマネージャで不要と思われるバックグラウンドタスクをいくつか殺してみたが，あまり効果はなかった．姉貴の旦那が持っているノートを貸してもらうということも考えてみたが，このノートのOSは多分Windows 7のはずだが、CPUは64ビットである可能性が高い．
今後は32ビット機というときはCPU32ビットのPCを指すものとし，32ビットOSを意味する場合には明示的に示すことにする．（これは通常の用語と少し違うかもしれない…）ShirleyにはVS2017をインストールしてあるが，コンポーネントが不足しているため満足な動作になっていない．Visual Basicに関わるコンポーネントを改めてダウンロードしてインストールしてみたが，どうもまだ思わしくないところがある．Visual Studio 2017自体は32ビットアプリケーションなので32ビット機でも64ビット機でも同様に動作しなくてはならないはずなのだが…
Windows Formの追加で新しい項目の追加が開いてしまう
インストールを妨げる要因として，.NETのバージョンが合わない（必要なバージョンがインストールされていない）場合と，C++がインストールされていない場合がある．必要な.NETがインストールされていても「有効化」されていないと同じようなエラーになる．このような場合はMSからダウンロードしても「すでにインストールされています」と言って弾かれてしまう．ランタイムをMSサイトからダウンロードするsetup.exeも失敗することがある．
Windows 10タブレットは前から使っているが，2 in 1 ノートで通常はキーボード付きで使っているため，キーボードのないタブレット上でゼルコバの木がどのような挙動を示すかという点に関してはほとんど知らなかった．今回tamozさんのタブレット上でZTを起動して初めてかなり悲惨なことになっていることに気付いたが，この辺りはすでに相当昔にkamui氏から指摘されていたところだ．「タッチ操作」をサポートすることはもはや喫緊の課題になっている．
作戦タイムが必要だ．ここでは一旦開始点まで退却するしかないのではないだろうか？つまり，「当面はターゲットを64ビット Windows 10 搭載機に限定する」という当初方針だ．この条件ならインストール可能なバージョンはすでに確保されている．あとはリリース可能な程度までデバッグするだけだ．ここでこれ以上深入りしていたら持ち時間を使い切ってしまう可能性がある．実際，天皇家系図だけでも相当な不具合が生じているのでまずこれを片付けないことにはお話にならない．
ShirleyではVSを一度アンインストールしてもう一度今度はVisual Studio 2017をフルインストールしてみることにする．どのくらい時間が掛かるかわからないが，放置しておけばよいので作業の妨げにはならない．タブレットTamozは32ビットOS（CPU64ビット）だが，64ビットOSのメイン機とまったく同じ動作になっているので動作上の問題はない．「タッチ操作」は「次期課題」としておこう．
デスクトップ上にはこれまでのランニングテストで発生した障害ファイルが11本もある．まず，これを片付けておこう．⇒いや，特に問題なくすべて開ける．おそらくリリース版でSTOP文が残っているバージョンがあったのだろう．もうひとつ気になっているのは，ヘルプ画面の下の方が切れているという不良だ．
デザイン画面ではもちろんこんな風にはなっていない．このパネルは最前面に表示されるフロートパネルでサイズ変更はできないから，レイアウトの計算などは一切行っていないはずなのだが…MaximumSizeとMinimumSizeを固定したら，とりあえず画面が切れることはなくなった．ただし，デザイン画面とはレイアウトが微妙に異なる…高さはほぼ一致するが，横幅がかなり詰まっている．おそらくそのためではないかと思われるが，フォントが少しぼやけて見える※．Max, Minをデフォルトに戻した場合は縦横ともに均等に縮小する．どういうことだろう？
※これは画面を解像度の高い（ピクセルサイズの小さい）モニターから低いモニターにドラッグ移動して比較しているためではないか？
カード画面もデザインより縦横ともに詰まっている．ただし，横幅の方が少し縮み方は大きい．カード画面は可変サイズなので調整すればデザインとほぼ同等の見え方にはなる．ファイルを開き直したとき，系図画面は前回と同じサイズ・位置に表示されるが，カード画面は位置は同じでもサイズは標準のサイズに戻される．タイトル枠設定画面も可変サイズだが再起動時には標準サイズに戻される．手動で変更したサイズと標準サイズはボタンで切り替えできるので，仕様的にはこれでもよいのかもしれないが，使い勝手からは閉じたときの画面がそのまま表示された方がよいような気がする．
▲表示→タイトル枠表示で系図画面にタイトルの表示/非表示を切り替えるようになっているが，違和感がある．ここは表示→タイトル枠設定画面を表示ではないだろうか？この場合はタイトル枠設定タブがタイトル情報タブより先に来るべきだろう．
描画処理系では座標・サイズとも物理単位（ピクセル）で操作しているが，元々のプロトタイプでTwipという単位を使っていたため保存数値はTwipになっている．Twipは絶対単位で1Twip=1/20ポイント=1/1440インチ=0.01763888mm=17.6μmに当たる．絶対単位では画面上のサイズと印刷出力のサイズは厳密に一致するが，ピクセルの場合はアスペクト比というものがあるため調整が必要になるという点に配慮したものだ．しかし，事実上ピクセルで扱った方がずっとわかり易いので現在ではTwipなどの単位はほとんど廃れてしまっているのではないだろうか？
Twip⇔ピクセルの変換でこれほど大きな誤差が出るとは考え難いので何か別な理由を考える必要がある．フォームのサイズはGetWorkingAreaという関数から取得しているが，この関数が返す値は「ディスプレィの作業領域」とされているので，タイトルバーなどの領域が除外されているのではないだろうか？⇒フォームのWidthとHeightを直接取り出しても同じ結果だ．デザイン画面ではSizeは554×381だが，ヘルプ画面のLoad関数の入口ではこの値は411×282に変わっている．およそ0.74くらいに縮小している．これから推測すると，静的なデザイン画面と実行時の内部（System.Drawing）では座標単位が違うような気がする．
LoadWndPostにも多少疑問はあるが動作は変化しないので，オリジナルに戻しておこう．いまのところ対処策としてはMaxとMinを固定するという方法しかない．ただし，この方法ではカード画面のように実行時に変化する画面を扱えない．カード画面も画面下部が少し切れている．
カード画面のデザイン時のサイズは695×476，Max＝任意, Min＝527×238となっている．カード画面サイズという関数でサイズをランタイムに決定しているが，既定値は現在516×370となっている．修正履歴的に変化しているのに対応していないのではないだろうか？⇒どうもますますわからなくなってきた．695×476を既定値とすると，下図のように下部に広い空白が生じてしまう．
この図面は縮小されているので実際にはもっと大きい．⇒原因がわからないので，暫定的に高さを調整して516×382としておこう．バージョンパネルはもうちょっと縦が詰まってもよいので554×371とする．
▲タモリんちで人名枠線なしのとき人名下部の垂線が人名描画域に越境している．
系図画面設定パネルはとりあえず問題なさそうだが，タイトル枠設定画面はすこしだけ下が切れている．プロパティ画面その他のパネルもサイズ的な問題はなさそうだ．系図画面設定パネルとタイトル枠設定画面の違いはFormBoderStyleで，前者はFixedDialog，後者はSizeableとなっている．タイトル枠設定画面もSizeableとすれば多少の難はあるが，文字が切れたりすることはなくなる．⇒これから言えることは，画面をサイズ変更可に設定すると，システム側で何か余分なことをしてくれるということのようだ．何をしているのかわからないが，ありがた迷惑だ．
タイトル枠設定画面はタイトル設定画面サイズという関数でサイズを決定している．SetupTitleSizeには既定値の516×370が入っている．これは正確にカード画面と同寸だ．というか，①カード画面，②系図画面設定，③タイトル枠設定の3つの画面は完全に同寸というのが元々の設計なのだが…現状ではタイトル枠設定画面は516×373という数字になった．しかし，奇妙なことにこれらの横幅は同じ値を取っているのに不揃いな林檎たちになっている．
調整すれば完全に同一サイズに「見える」ようにすることは可能とは思われるが，これは後日ということにしよう．タブレットで「タッチ操作」を実装しようとするときにはいずれこの辺りをみっちりやるしかなくなるはずなので…一応これで一番気になるところは調整できたことにして，現状で目につく最大の瑕疵である切れ切れの垂線の問題に移ることにしよう．かなりひどいことになっている．
何が原因かよくわからないがブツブツに切れてしまっている．この図面では多重カードは発生していないので，少数の先祖ノードを除けばほとんどすべてのノードには親からの垂線が入って来なくてはならない．途中で線分が切れていることをプログラム的に検出することは可能だろうか？各線分がオブジェクトとして管理されていればそれもそれほど難しい話ではないが，ゼルコバの木では描画出力はすべて描画関数によってディスプレイに直接描画されているため，事後に検査するというのはかなり難しい．しかし，今後このようなことが二度と起きないようにするためにはなんらかの検査関数を作ってチェックする必要がある．
系図図面は人名枠と水平線および垂直線から構成されるが，人名枠を１個の垂線とみなせば，かなり単純な線分の集合とみなすことができる．従って，グラフG(V, E)としてV=｛線分の端点｝，E=｛線分｝からなるグラフを考えることができる．Vの部分集合ｐ={人名枠線分の端点}とし，ｐに属する2つの点pとp’が「親子関係」にあるとき，pからp’に至る経路があるかどうかを探索すればよい．座標計算には誤差があり得るので完全一致できない場合には近傍探索でもよいが，むしろ誤差が発生する原因を追求する端緒としても活用できる．同様のことは夫婦関係についても言える．原則的に夫婦は同じ世代に属すると考えられるが世代差が出る場合もあり得るので同じ手法で一般的に解いた方がよい．
グラフ理論的なアルゴリズム（抽象グラフ検証系）はこれまでにもある程度実装しているので多分それほど難しくはないのではないかと思う．これはあくまで部外の検査であり，リリース版ではそこまでやる必要はないが，描画図形をオブジェクトとして扱えるようになると，たとえば線分をくリックしたときそれに接続する経路の全長をハイライトしたりなどのことができるので，その方向性も考えておく必要がある．さらには線分をクリックして選択→削除で（親子・夫婦）関係を切断したり，人名枠を2つ選択して関係付けなどの直観的操作も実装可能になる．
