Visual Studioは一つのマシンで複数のインスタンスを同時実行することができるが，これらが同一のOCXを参照している場合などにはうまくゆかない．この不都合を回避するためにコンパイルオプションでOCXのuuidとversionを切り替えるようにして並列実行を可能とすることができるようになった．修正前のバージョンと修正後のバージョンを同時実行して，1本のファイルを開くまでの間に200万回くらい呼び出されるような呼び出し頻度の高い汎用関数の呼び出し回数が両者で厳密に一致することが確認されたので，修正の正当性は高度に保証された．このオプションは今後大いに役立ってくれるだろう．
一つ気になっている点としてMARGBOX::nodegeneは不用なのではないかと推測しているのだが…不用なロジックは可能な限り排除しておきたい．MARGBOX::nodegeneが不用と考える根拠は，書き込まれてはいるが，読み出されていないように思われるからだ．単純にMARGBOX::nodegeneを隠蔽してコンパイルエラーを見ることにしよう．まず，最初にMARGBOX::getnodegeneを止めてみた．コンパイルエラーは発生していないが，SIMPLEGRAPH::TightenHasseDiagramのループでMINMOVが不定値になってしまう．つまり，動作が変化している．どういうことだろう？
NAMEBOX::nodegeneでは確かに修正ミスを冒していたが，その原因はNAMEBOXの場合には多少あいまいな点があったためだ．MARGBOXの場合は誤りようがないように思われるのだが…⇒原因は分かった．サンプルが源氏に切り替わっていた．源氏には「避けられない多重」が6個もあるので多重グラフ検定を打ち切ってループの外に出る必要がある．ここで停止するのは意図的にそうしているのだから問題ない．これで懸案の一つは片付いた．ここでバックアップを取っておこう．
これで次に進めるのではないだろうか？ゼルコバの木では人名枠の配置を大きく垂直検定と水平検定に区分している．重婚同類グラフ検定は前者を担当し，メインループで後者を処理していると言ってよい．ただし，例外的にメインループの中で垂直方向の操作を行うことも一部認められている．さて，ぼちぼちと始めることにしよう．連結線の途切れをチェックするための検査を系線グラフ検定，そのために使うグラフを系線接続関係グラフと呼んでおこう．
系線グラフの節点は線分端点の座標，枝は座標の対であるとする．系線グラフが一旦構築されると，今度はそれを描画に用いることもできるようになるが，系線には色や太さなどの属性を持たせなくてはならないのでその辺りはまた後日ということにしておこう．既存のグラフはすべてTOPOLOGY（系図解析木クラス）が管理している．この方がわかり易い上に安全なのでこの方式を踏襲することにする．グラフの本体は人名テーブルや結婚テーブルを保持しているLINKTABLEが所有する．グラフ処理の一般的手順は以下の通り．
- グラフの生成 TOPOLOGY::initialize→new
- グラフを初期化 TOPOLOGY::ResetExperiment→initialize
- ノードリストを生成 ノードリストは枝リスト生成時に自動生成される
- 枝リストを生成 両端点を指定して枝を生成 SIMPLEGRAPH::add
- 連結リストを生成 DecompConnectedComponent
- グラフ処理 ．．．
- 参照カウントの調整 TakeRemainSansyo
- グラフを廃棄 delete
描画オブジェクトを扱うクラスとしてDrawingObjectクラスを新設する．DrawingObjectのインスタンスはTreeViewが管理する．座標値は内部ではCPointとして表現されているので，任意長のCPointテーブルを扱えるようにする必要がある．固定サイズのlongテーブルを扱うlongtableというクラスはあるが，これではカバーできない．線描画関数には座標対と線の属性が渡される．DrawingObjectクラスの中に座標対と属性を保持するテーブルを持つということも考えられる．これがあれば，DrawingObjectが単独で系線の描画を実行できるようになる．これは描画を高速化する効果があるだろう．まず，DrawingObject.h, DrawingObject.cppという2つのファイルを作ってみよう．
TREEVIEWはTRIBELISTの下にあり，TOPOLOGYはTRIBELISTの上にある．いや，少し違うのではないか？最上層はCOUPLINGであり，その下にKAKEIZU, FAMILYTREE, TREEVIEW, PAGESETUPがある．参照と接続を区別しなくてはならない．KAKEIZUは系図データベース，FAMILYTREEは系図木構築，TREEVIEWは系図画面出力，PAGESETUPは印刷出力に関係する．FAMILYTREEの下にはUNDOSYSTEM，TOPOLOGY，LINKTABLE，NAMESORT，PARTIALNAME，COUPLINGがある．最後のCOUPLINGは追加読み込み用スロットだ．
開発機にインストールされているゼルコバの木を起動したらエラーになってしまった．再開発スタート版というバージョンをインストールしておこう．インストールされている版はZelkova-Tree 2021となっている．この版をアンインストールしようとしたら，「WindowsにZelkova-Tree 2021を設定しています 必要な情報を集めています」でハングしてしまった．かなりまずいのではないか？
キャンセルボタンを押しても終了しない．再起動しかないようだ．再起動したら以下のパネルが出た．
11178c24.msiなんてどこから来たのだろう？放置しておいたら，別のパネルが出た．
Administratorではないかもしれないが，管理者権限を持ったユーザとしてログインしているのだが…OKでようやくすべて閉じた．ともかく再起動しておこう．⇒多分このトラブルは一つ上のパネルが下に隠れているのに気付かなかったというケアレスミスだろう．今度は簡単にアンインストールできた．⇒とりあえず問題なく起動できた．しばらくゼルコバの木を使っていなかったので準備運動を兼ねて，ゼルコバの木プログラムのモジュール構成図を作ってみることにする．
▲子ども並び替えでドラッグ移動が効かない．カーソルキー操作はできる．⇒これは操作の仕様が変わっているのに説明文が改訂されていないためではないか？ドラッグはできないが，その代わり上下のスピンボタンが表示されている．⇒説明文を改訂する
▲人名枠氏名欄の左側に説明文を出したい．できれば任意配置できるとさらによい．表示項目の範囲を広げて取捨選択できるようにしたい．
▲pagesetupはTREEVIEWを参照しているだけなのに，子ども欄に記入したらCOUPLING→TREEVIEWの親子関係が切れてしまった．確かにこの方が便利な場合もあるが…画面設定→カード画面設定→既定で養子チェックオンというのがあるが，これで親子関係の自動切断動作を回避できるのだろうか？⇒確かにそうなっている．これはこれで便利ではあるが，養子チェックをいちいち外すのは厄介だ．むしろ，実子関係がすでに存在している場合には実親を切り替えるのではなく，養子関係で接続するという方がよい．この操作法をオプションとして提供し，①対象ノードがすでに外部に実子関係を持っているときは養子関係で接続，②対象ノードを実子として登録する場合にはそのノードがすでに実子関係を持っている場合にはその関係を切断するの中から選択できるようにするとさらによい．養子チェックは氏名を入力したあとでないと入力できない仕様になっているが，これでは上のような誤動作を避けることができない．空行を敢えて入力不可とする必要はないのではないか？裏技として，一文字入力して消すと使えるようにはなるが…そこのところは，これでも間に合わないことはないとして…⇒実子関係を切断する前に警告パネルを出すというのが実際的かもしれない．
▲「画面設定」メニューは「設定」とした方がよい．
▲人名カード画面の子ども氏名欄でホイールでスクロールしたときのスクロール量が大き過ぎる．ページスクロールの動作になっているようだが，次行に書き込めない．最小限一行分のダブリが必要だ．
▲子どもが親を2つ以上持っているとき，必ずしも実親の直下に配置されることにはならないが，その方がバランスがよい場合もある．直下に配置することを指定できてもよいような気がする（できない場合があるかもしれないが）．しかし，実親を基準ノードでソートしているのに直下に来ないというのはかなりおかしい．⇒ある意味でそれを実現しているのが，「血統軸線図」と言えないこともないが…
▲血統軸線図で下図になるのはおかしいのではないか？UndoChainが軸線上に来ない理由がわからない．⇒これはバグと言ってよいと思う．
作りかけのゼルコバの木プログラムのモジュール構成図．ほんの気まぐれで作り始めたのだが，どうもかなり大きなものになりそうだ．実際のところゼルコバの木ではすべてのオブジェクトは１本の木を構成しているので，これを最後までやるとかなり大きなものになることは間違いない．途中でtreeviewという名前のカードが2つできてしまったので，カード合併を実行したところで「親子連結線の途切れ」が出現した．
しばらく動かしていなかったので多少とまどいはあったが，少し動かしていると慣れてきて，「ストレスなく入力できる」というキャッチフレーズも（上記の実子関係が切断されてしまうという点を除けば）あながち誇張と言うほどのものではない．UNDOで合併前の状態まで戻れることを確認しておこう．UNDO/REDOは動作しているようだが，REDOでそのまま続けてREDOしていたら，エラーパネルが出て止まらなくなってしまった．操作する直前にバックアップを取っているのでデータは失われないが，UNDOの不良動作を再現できるかどうかは分からない．
どこかでループしているもののように思われる．タスクマネージャで落とすしかなさそうだ．このアプリはZelkova Tree 2019（32ビット）(2)という名前で登録されている．デスクトップ上には大量の反例サンプルが発生しているが，すべて同内容なので一つを残して削除しておこう．これらのファイルを開くと以下のパネルが出る．
反例サンプルを開くと余分の白紙カードが生成されている．
オリジナルは66点なのに対し，反例サンプルは67点なので白紙カードと枚数が合わないが，オリジナルから消えているカードが2枚あるので一応帳尻は合っている．もう少しデータ入力を続けよう．
▲検索ボックスに名前を入力して虫眼鏡をクリックしてもジャンプしない．⇒無選択状態ならジャンプできる．これはかなりおかしい．確かに選択状態を変化させずにジャンプしたい場合はあるかもしれないが…無選択状態のときはそのカードにジャンプしてそのカードが選択された状態になる．人名カードはカード選択と同期しているから，ジャンプしたときカード選択が移るのはやむを得ないと思われるが，無動作というのはまずいと思う．⇒つねにジャンプでよいのではないか？
▲純血統図では養親子関係のノードは無色カードとして表示されているが，むしろ非表示の方が用途があるのではないだろうか？実際，いま作成しているモジュール構成図では「接続関係」が「実子関係」，「参照関係」が「養子関係」に対応すると考えるとうまく表現できるのだが，「構成図」の場合には純粋な（参照関係の系線を省いた）木としての表現が見たいので，「養親子関係は非表示」とした方がフィットする．
coulingを基準ノードとして親族図→直系血族図を描画しても思ったような図が出てこない．treeviewには親が3つあるが，実親は頂点のcouplingなのでこの図面ではcoupligの直下にあることを期待しているのだが，tribelistの下に配置されている．これは図面範囲を直系血族図としたとき，図面に配置される人名ノードの範囲は直系血族になっているが，表示されているカード間の関係はすべて温存されているために起こっている．確かに，この図面では表示されているカードの関係情報はすべて網羅されているが，ユーザが期待しているのは別のことなのではないだろうか？それができれば，登録時にはすべての情報を登録しても，表示するときには単純な木として表示することができるようになるのだが…純血統図では（養親系を除く）と表示されている．これを文字通り理解すれば，（養親系の関係は表示しない）となるはずであり，その方がわかり易いような気がする．このオプションの動作をそのように変更すれば，他のところをいじらなくても要求されているような図式を出力することが可能になると思われるのだが…
■カード番号の左右のスピンボタンで移動するとき，飛び番になることがある．これはスピンボタンの動作が一覧表の順序になっているためで，不良ではない．
ともかく，入力を続けることにしよう．
▲カードに個別に色を付けることができるというオプションもあっていいと思う．また，個別に「関係を非表示する」ことができるとさらによい．⇒カードに任意の属性を与え，それを色別表示することが考えられる．⇒部分図という概念があるが援用できないだろうか？ある部分図に属すること＝ある属性を持つことという解釈だ．
▲カード一覧表でいくつかの列を非表示にしたあと，一覧表セル幅→均等分割するとまたもとの全列表示状態に戻ってしまう．これはうれしくない．⇒表示領域は現在のウィンドウの横幅とし，現在表示されている列で均等分割するというのがよいのではないか？
この図面は人名枠左に説明を表示できるようになってから，その部分の日本語テキストを補充することを考えているので，今回の入力では実親関係データだけを入力するということにしてみよう．あるいは，全データを入力しておいて，その派生版として複数親を持つノードだけ修正したバージョンを作ることも考えられる．複数の親を持つノードはそれほど多くないので原本としてまずすべてのデータを入力しておこう．
▲#33 baselistの子ども氏名欄に「NLIST <GENEBOX, ‘g’>」と入力→登録でエラーが発生した．この欄にはNLISTという名前が登録されていたが，それを上書きして登録でエラーになった．
UNDOで元の状態に戻せる．この状態で一度保存しておこう．(ERR1)とした．UNDOではエラーは発生しなかった．UNDOの種が切れるとメニューは不能状態になるのでそれ以上のUNDOはできない．CTRL+Yを押しても反応しない．とすると，上のエラーはかなり特殊ケースだったのかもしれない．⇒このエラーはゼルコバの木モジュール構成図(ERR1).ZELで再現できる．⇒上書き入力だけでなく，baselistの子どもNLISTを抹消登録だけで再現する．他のノードでも起きる場合がある．extraslot2の子どもCOUPLINGを削除しても同じエラーになった．1人だけの子どもを削除しようとしたときに発生するようだ．エラーパネルが出なくなった後は，エラーなしでUNDO/REDOできる．⇒この障害は子どもが一人だけになったときには確実に発生する．⇒このエラーは子どものカードで親を抹消したときにも発生する．
▲UNDOメニューがすでに不能状態になっているときにCTRL＋Zを押してエラーになった．
どうもメニューではリミットが検出されているのに，CTRL+Z/Yのキーが入ってしまうことがあるような気がする．OKで次のパネルが出た．
これを2, 3回反復してパネルは消えた．メニューではUNDO/REDOのどちらも使える状態になっている．ただし，CTRL+Zを押しても画面上には変化が現れない．CTRL＋Yではエラーが出た．スクリーンショットは取らなかったが，「配偶者不在」のようなパネルもあった．そのあと，CTRL+Yで以下が出た．
どうもUNDOシステムが壊れてしまったようだ．CTRL+Yを押すたびに上のパネルが出る．一度終了してもう一度始めることにする．クローズボタンで警告なしにアプリが閉じてしまった．最後の状態がなんであれ，ファイルを修正しているのだから，保存しますか？が出なければおかしい．⇒「配偶者データがありません」のあとは正常に動作する．
VS2017を再起動→ソリューションを開いて，変なパネルが出た．
確かにVS2017を2つ開いてしまっている．キャンセルしてアプリを落としておこう．どうも細部はまだ完成にはほど遠い状況だが，入力を続けよう．下図まで入力して気付いたのだが，この図には2つの因子が混在している．一つはcouplingを頂点とするオブジェクトの実体的な包含関係，もう一つは実体を持たないクラスの親子関係だ．
上の図の赤枠はインスタンス（オブジェクト）で実体として存在するもの，白枠はクラスで実体を持っていないか，あるいは実体を統括した表象とでも言うべきものだ．この図ではコンポーネント（名前を持った実体）はすでにすべて描画されている．しかし，このシステムがそんなに単純なものであるはずがない．それはなぜかと言えばこれ以外にも名前を持たない無数のオブジェクトが存在しているためだ．言ってみれば上図は「骨格図」であり，すべてのサンプルの共通部分と言えるが，それに付随して無数のオブジェクトがさまざまなトポロジーによってリンクされている．そのような実態を一枚の図で描画することは不可能に近いが，上の図にはまだ決定的に不足している部分がある．
それはあるコンポーネントが保持する下位要素にはそのコンポーネントの基本クラスの要素がすべて含まれているという点だ．上図で白枠で表示されている部分はこのような下位要素の一部を展開したものと言える．従って，もし，この図が完成されたとすれば，頂点にはcouplingがあり，真ん中から下の白い領域にも最下層の頂点としてNODULEが来るという構成になるはずだ．これは図式的に見ると「束（lattice）」と呼ばれているものにかなり似ている（意味はまったく違うが…）．
現状のゼルコバの木を使ってこの意味での「完全な構成図」を描くというのは不可能に近いという気もするが，ゼルコバの木のような複雑なシステムをもし仮に一枚の図式で示すことができるとしたら，それはかなりすごいのではないかと思う．原理的にはそれほど難しくないし，もしそのような図面が手元にあればプログラムのデザインや実装のときに大いに重宝するのではないかと思う．
ゼルコバの木を使ってゼルコバの木システムを図式化するという試みは以前も（途中まで）やったことがある．このときの対象は「関数の呼び出し関係」つまり，「関数木」を作ろうとしていた．Visual Studioには「呼び出し階層」というツールがあってある程度このような関係を図式化できるようになっているが，あまり使い勝手がよいものではない…「ゼルコバの木システム構成図」がどんなものになるかというイメージがつかめたところでまた明日ということにしよう．
■以前は実親は親ページの先頭に配置されていたはずだが，現行ではどのページでも実親として設定できるようになっている．
▲これから手直しというのも大変だが，先祖ノードに結婚枠を与えなかったというのは敗因であったような気がする．結婚枠は背景色のべた塗りしかできないが，枠線というものがあってもよかった気がする．
下図は実親子関係だけを抽出した派生バージョンだが，システム構成図としてはこれが正しい．上半分のピンクは完全な木になっている．
この図にはシステムの大きな構成要素である描画オブジェクトリストのようなものは出てこない．なぜか？描画リストはBobjectの4つのスロットを使った三元木として構成されている．TREEVIEWクラスの基本クラスはBobjectだが，上の図のtreeviewにはそれが含まれていない．Bobjectはほとんど抽象クラスだが※，その派生クラスは当然オブジェクトとしての実体がある．上の図ではそれが見えてこない．⇒たとえば代表的な描画オブジェクトクラスとしてNAMEBOXとMARGBOXの場合を考えると，NAMEBOXはCARLINKに保持されている．CARDLINKのnamboxスロットにはNAMEBOXのリストがリンクされる．MARGBOXも同様MARGLINKのmargboxスロットにリンクされる．
※BobjectやNODULEを「抽象クラス」として再定義してみるがよい．
MARGLINKとMARGBOXは一対一に対応するが，CARDLINKとNAMEBOXは一対多の関係になる．CARDLINK自体は上の図で言えばPDBという名前のCARDTABLEに格納されているし，MARGLINKはMDBというMARGTABLEに格納される．従って，上の図をもう少し詳細化すれば基本的にはシステム全図を（一枚の図面として）描くことが可能になると考えられる．（原理的にはゼルコバの木でもそれを描画可能だが，見易い図面にはならないだろう）
デバッグ用のツールなどどこにあるのか上の図からは見えない※．⇒デバッグ用のツールというオブジェクトは存在しない．デバッグ用ツールはほとんどすべてさまざまなクラスの関数で，それを適宜コードに挿入して使っているに過ぎない．たとえば，ShowUnderWearというのはマクロで，例外を発生してあるエラートラップにジャンプしているだけだ．関数の依存関係は関数木として表現できる．ゼルコバの木はアラン・ケイのオブジェクト志向とは真逆の発想だけど，誰か世界中に一人くらいそれを継承しようなんて突飛な人はいないものだろうか…たとえ人間国宝になれたとしても，継承者がいなければ何の意味もない．
※いや，たとえば現在取り組んでいる「抽象グラフ検証系」などはオブジェクトとしての実体がある．現行ではこれらはTOPOLOGYのスロットに格納されているから，詳細化すれば図面にも出てくる．
