▲源氏物語全系譜6.1.ZELの全体図を#5 紫の上（若紫）で開いて，NAMEBOX::IsPossibleBTWLeftHand Sc=884 左手本人が不可視で停止した．障害ノードは #15496 明石中宮(1)で消去された仮ノード．ゼロ復帰しないとしたらどのような動作になるのか確認しておこう．⇒「右手配偶者カードリンク不一致」でゼロ復帰している．右手結婚枠はMARGBOX #1098：#1225 明石中宮(0)＋#1277 今上(0)→#1234 春宮(0)で，左手本人と右手本人が同一というシチュエーションだ．「左手本人が不可視」の検査を検査ルーチンの末尾に置いてみよう．
▲同上サンプルを#235 常陸介の前の北の方で開いてTRIBEBOX：hasPhysicalConnectionで停止した．(primenod->bigamist != realnode)というエラーが起きている．障害が起きているのは系列枠：snum=1544 primetype=3:婚姻関係 senzo=#424 一院 ＠10で，優先仮ノードはNAMEBOX #1382 浮舟の母(0)．優先実ノードはNAMEBOX #1732 常陸介(1)だ．浮舟の母(0)はBTW右手配偶者，常陸介(1)はBTW左手本人だが，primenod->bigamistには浮舟の母(1)が入っている．これはかなりおかしい．
確かにMARGBOX #1150：#1777 浮舟の母(1)＋#1778 常陸介(2)→#1398 蔵人右近将監(0)というBTWは成立している．逆に常陸介(1)が左手本人となるBTWは見当たらない．いや，#1778 常陸介(2)が右手配偶者となるBTWは発生している．このとき，#1732 常陸介(1)は左手本人になっている．とすれば，間違っているのはむしろ浮舟の母(0)がBTW右手配偶者ということになるのではないだろうか？いや，このBTWも存在している．#1382 浮舟の母(0)が右手配偶者，#1777 浮舟の母(1)が左手本人だ．このときの右手枠はMARGBOX #1082：#1270 八宮(0)＋#1382 浮舟の母(0)→#1291 浮舟(0)だ．
この結婚枠は後から，もう一度BTWになっている．どこかで解除されているのだろうか？浮舟の母(1)はMARGBOX #1150：#1777 浮舟の母(1)＋#1778 常陸介(2)→#1398 蔵人右近将監(0)のときには右手本人になっている．つまり，浮舟の母(1)は左手本人だが，右手本人でもある．何が問題となっているのだろう？右手本人と左手本人は複数のBTWに関係し得るが，右手配偶者の関わるBTWは一つしかないと考えられる．実際，浮舟の母(0)が右手配偶者となる結婚は#1082：#1270 八宮(0)＋#1382 浮舟の母(0)であり，常陸介とは直接関わりはない．
優先仮ノードの浮舟の母(0)は右手配偶者で一院系列，その左手本人である浮舟の母(1)は大臣（橋姫）系列で同時に右手本人，その右手配偶者の常陸介(2)の左手本人が優先実ノードの常陸介(1)で，所属系列は常陸介の前の北の方だ．浮舟の母(0)のbigamistつまり左手本人は浮舟の母(1)，浮舟の母(1)の右手配偶者の常陸介(2)のbigamistが優先実ノードの常陸介(1)になる．系列接続種別は婚姻関係となっているが，現行ルールではこのようなルーズな接続を認めている．ただし，それを正当化するのは難しい．今の場合で言えば
- 優先仮ノードがBTW右手配偶者で，その左手本人が優先実ノードでない場合でも，もし，その左手本人が同時に右手本人であるとすれば，
- その右手配偶者の左手本人が系列優先実ノードであれば正当と言える
のような感じになる．右手配偶者が同時に左手本人ないし，右手本人となる場合はあるだろうか？右手配偶者は原則として消去されているはずであり，逆に左手本人ないし右手本人は可視でなくてはならないと考えられるから，右手配偶者・左手本人ないし右手配偶者・右手本人ということはあり得ないと考えてよいはずだ．従って，優先仮ノードが右手配偶者で，その左手本人が優先実ノードでない場合には，左手本人が同時に右手本人である可能性を考えるのは妥当であるように思われる．
優先仮ノードが右手配偶者で優先実ノードが右手配偶者というケースはあり得るだろうか？一般には優先仮ノードは不可視，優先実ノード可視がノーマルな状態と考えられるので，実ノードが右手配偶者となるケースは除外してよいように思われる．従って，上の例外規則を適用すればある程度まではカバーできるのではないかと思われる．多少ややこしいが，実装してみよう．⇒動作している．
▲上記サンプルの画面で浮舟の母のカード画面上の子ども氏名欄で浮舟をダブルクリックしてTOPOLOGY::MakeActiveListのエラーが出た．(treeview->validcard != ActiveList->count)というエラーだ．validcard=319に対し，ActiveList->count=318になっている．氏名欄のダブルクリックで系統並び替えが発生するというのもおかしい．⇒再現しないが，ダブルクリックで新規カードを発行した後，UNDOで戻ると同じエラーが出る．浮舟の母の配偶者氏名欄に「7777常陸介」というのが入っているので，どこかで誤操作した可能性がある．
確かに，浮舟の母の配偶者氏名欄を「7777常陸介」のように書き換えて「登録」すると似たような事象が起きる．この後，UNDOしても元の状態には戻らない．これはUNDOの不備に依るものと思われるが，カウント不一致と合わせて別の機会に調べることにする．⇒この操作を行った後，ファイルを一旦閉じてもう一度開こうとしてハングする．freeblock::_releaseall_で失敗しているようだ．これはUNDOの不良と関係あるように思われる．⇒この版（ZT BASIC）ではUNDOをサポートしていないのにUNDOボタンが作動するというのがそもそも問題だ．
▲源氏物語全系譜6.1.ZELの直系親族図を#3 桐壷の更衣で開いて，「無効カードの仮ノード取り出し」エラーが起きた．⇒TRIBEBOX：GetAlternativePrimeNodeで無効カードを弾いていない．⇒対処した．
▲同上Ｚ木家系図を#5 紫の上（若紫）で開いて，出口検査のTRIBELIST::CheckTribeListで，TRIBEBOX::CheckTribeのエラーが発生した．結婚リンク無効/結婚リンクの先祖不在が発生している．10系列でこのようなエラーが発生している．⇒GetAlternativePrimeNodeで無効結婚リンクを弾いていない．⇒対処した．
源氏物語全系譜6.1.ZELの完全木テストが完了した．Basicエディションを開発機上でテストした．
この後は舞台をVAIO2に移してテストすることにする．Mouse Without BordersではLAN上の別のマシーンにドラッグ＆ドロップでファイルをコピーできる．これはすごい！他のマシンのデスクトップ上にドラッグするとMouseWithoutBordersという名前のフォルダを作ってそこに放り込んでくれる．…残念ながら，フォルダごとコピーすることはできない．「ZELKOVA 2021-02-26-1 – Folder is not supported, zip it first!」ZIPで圧縮しないとダメだと言われてしまった．⇒それでも，ZIPして解凍の方がLAN上(WiFi)でファイル転送より速い．最近の修正をフィックスしておこう．
- 系列のSPOUSESENZO属性を廃止する＠20210224 25箇所
- 仮修正 1箇所，#if 0 5箇所，#if 1 3箇所
上記の「7777常陸介」という問題を調べておこう．最初に「カード登録」で(treeview->validcard != ActiveList->count)のエラーが発生するが，その後のUNDOの問題を先に見ておこう．VB側ではZ.mUndoStatusの値を読み取ってそれを表示しているだけだ．mZelkova::mUndoStatusではCallGetUndoStatで状態を取り出している．⇒CallGetUndoStatでUNDO未サポートの場合は，引数のUNDOSTAT *undoの内容をゼロクリアして返すようにした．
以前，Ctrl+ZでUNDOが誤動作していたので，チェックしておこう．Ctrl+Zが押されると，CardUndoRedoが引数FALSEで呼び出される．Ctrl+Yが押されるとCardUndoRedoが引数TRUEで呼び出される．この関数では状態に関わりなくZ.mUndoRedoを呼び出しているが，状態を判定してから実行するように改めておこう．⇒対処した．併せて，UNDOSTATの定数を整備した．
▲上記サンプルでUNDO/REDOの操作を実行していて，freeblock：_delmem_で例外が発生した．freeblock *mblockの値がおかしい．REDOを実行中で，delete unode->addressで削除操作を実行しようとしたところだ．unode->addressに入っているオブジェクトは正常であるように見える．障害は~CARDLINK→ ~CARDBASEで起きている．記録ページを解放しようとしているところだ．
削除しようとしているカードは@176の常陸介でこの人名リンクのcardbase.notepageの内容がおかしいようだ．カード合併などもやっているので，その影響があるかもしれない．オリジナルのZELファイルでは常陸介の記録ページは白紙になっている．というか，UNDOシステムはゴミ箱が整備されていないと正しく動作しないのではないだろうか？カードの削除や追加などは一応動作しているようではあるが…
freeblockにはShadowというのがないのでストレートに削除されている可能性がある．この問題は別途調べることにしたいが，再現できるだろうか？以下の手順を試してみたが，再現できなかった．
- 浮舟の母の配偶者欄で7777常陸介を登録→ 7777常陸介の新規カード
- 浮舟の母の配偶者欄で7777常陸介→常陸介→登録→ 常陸介新規カード
- 常陸介の新規カードとオリジナルの常陸介をカード合併
- 常陸介と7777常陸介をカード合併
- UNDO→UNDO→UNDO→UNDO→REDO→…
7777常陸介というカードが発生した原因は数字キーの7をHOMEのつもりで押していたためだ．テキストボックスにフォーカスがない場合には「7」キーでHOMEキーを代用できるのだが… 間違い易いかもしれない… この辺りも少し調べる必要がある．(treeview->validcard != ActiveList->count)のエラーが起きるのはUNDOシステムを実装していない場合に限られるようだ．
VAIO2でZTシステム構成図7.ZELの完全木テストが完了している．
このサンプルは開発環境では7.1.ZELの名前になっているので，リネームしておこう．ZTシステム構成図7.ZELをVAIO2にコピーしてテスト開始したところ，早速エラーが出た．
▲ZTシステム構成図7.ZEL 親族図:すべてのカード 基準ノード=#11 extraslot2を開いて，TRIBEBOX::DecidePrimaryNodeで停止した．系列優先仮ノードが空になっている．