2021年3月 – ページ 2 – さあ，もう一度ゼロから始めよう

2021年3月5日2021年3月5日

描画領域サイズオーバーの問題が片付いた

VAIO2に（一昨日）仕掛けてあった渋沢一族の完全木テストの結果がダンプされていたので記録しておこう．所要時間1時間57分となっているが，時計の針は少なくとも一周しているので26時間掛かっている．

包括テストＩ完全木テストを完了しました．
ご協力ありがとうございました．

C:\Users\babalabo\Desktop\渋沢一族8.ZEL
サンプル点数： 829　経過時間：01:56:51　検定図面数： 7461面
計算時間：12.52 秒/面　99.81 ms/点　延べ点数： 935925点

描画領域サイズオーバーの問題が片付いた．かなりあちこち調整する必要があった．主な点を挙げてみると，

ZoomListTool_SelectedIndexChanged　SendKeys.Send(“{ENTER}”)を廃止し，SendKeys.Send(“{BACKSPACE}”)を実行する
MDIForm_KeyDown　Keys.EnterではSetZoomRateを実行し，Keys.BackではResetZoomRateを実行する
SetZoomRate　Zelkova1.ZoomSetを引数ZOOM_RESETで呼び出す
ResetZoomRate　Zelkova1.ZoomSetを引数ZOOM_NOMSGで呼び出す
CZelkovaCtrl3::ZoomSet　CtrlZoomSetの戻り値がERR_ZOOMOVERRANGEのときはActionCenteringを実行する
CtrlZoomSet　引数がZOOM_RESETのときは，TreeView->OVERSIZEをリセット，ZOOM_NOMSGでは保持してZoomSetを実行する
TREEVIEW::CheckDispSizeOver　OVERSIZEがオンのときは，「この図面は～以上には拡大できません」の表示を抑制する
TREEVIEW::LimitSizeOver　描画領域サイズオーバーが発生した場合には，OVERSIZEをオンにする
TREEVIEW::Zoom　OVERSIZEならERR_ZOOMOVERRANGEを返す
TREEVIEW::ZoomIn，ZoomOut　ZoomSetを呼び出す前にOVERSIZEをリセットする

要点は，①エラーコードERR_ZOOMOVERRANGEがアプリ側まで伝達されるように経路を整備（渡せないところではTREEVIEW::OVERSIZEを使う），②警告パネルが重複表示されるのを抑制，③ズーム倍率リストのテキスト変更でリターンキーが押された場合，④ズーム倍率リストのインデックスが変更された場合の動作を（外形的に）統一する．⑤エラーが発生した場合にズームタイマーを確実に止めるなど．コンボボックスのSelectedIndexChangedイベントをキャンセルできないという不都合に対処するために，キーイベントを送ってイベントハンドラで遅延処理するという仕掛けを作り込んだのは2017年頃のようだ．デバッグモードではこの操作が止めてあったため気付かなかった．

系図画面ないし一覧画面上での選択動作にいろいろと不具合がある．選択操作と部分図操作は切っても切れない関係があるので，正しく動いてくれないと甚だ都合が悪い．特に一覧画面上の動作が悪い．まず，最初に一覧画面上に表示されているレコード数をチェックできるようにしておこう．⇒ModeNameChangeの末尾で以下を実行するようにした．

CardTable.Text = TitleName + “　《” + ModeName + “》” + “　” + Str(CardTable.CardGridView.Rows.Count) + “点”

これでほとんどカバーできるようだ．数字も合っている．選択されているカードの数も出しておこう．CardGridView_SelectionChangedでModeNameChangeを実行するようにして同期が取れるようになった．

一覧画面上での選択操作は系図画面上の選択されたカードと同期している．また，カード画面に表示される主選択カードも同期している．問題は，系図画面上での操作が一覧画面に反映しないという点だ．カードが1点だけの場合は一覧画面にも反映される．また，選択解除も同期しているが，複数選択になるとまったくダメだ．

しかし，「まったくダメ」という訳でもない．入る場合と入らない場合がある．しかし，ほとんど入るという場合がない．親族図で複数選択して部分図に移動すると一覧画面でも複数選択になる場合がある．ただし，このとき部分図は無選択状態になっている．また，何かの拍子で選択が反転して「訳が分からない状態」になる場合もある．⇒渋沢一族ではサンプルが大き過ぎる．親族呼称図を使うことにしよう．

▲系図画面設定の動作がおかしい．結婚マークを表示する→ 人名枠線を表示するとして結婚点が下枠の高さに表示されてしまう．⇒ただし，この事象は再現しない．また，結婚マークを表示するをオン・オフしても画面に反映されない．

2021年3月3日2021年3月4日

GetHasseDiagramの論理を見直し

▲岩崎彌次郎系列を選択して部分図に切り替えようとして，SIMPLEGRAPH：GetHasseDiagramで停止した．この関数を呼び出すときの引数seedが空になっている．⇒SIMPLENODE::AddOyakoEdaで枝が生成されていない．⇒「系列分解図の場合は始系列のみ処理する＠20171125」となっている．これはかなりまずい．クラスタ図は婚姻と親子関係だけで構成されるので，「系列」は無関係のはずだ．

いや，そういう訳にもゆかない．確定世代番号を得ることがクラスタ図の目的だが，系列間の結婚によってそれが歪められてしまう．かなり厄介な話になってきた．系列分解図の場合は重婚クラスタ検定はパスするというのが現実的であるような気がするが，この問題は棚上げして，部分図の場合はつねに系列分解図オフとすることで逃げることにしよう．

渋沢一族が5つのブロックに分解している事情を解明する手がかりとして，岡部長景の傍系親族図と渋沢栄一の傍系親族図の接点となっている尾高豊作＠22の傍系親族図を取ってみた．246人を収容するかなり大きな親族図だ．尾高豊作は尾高惇忠（藍香）の子どもの尾高次郎と大内ふみの間の子で，尾高家は渋沢一族の中でも渋沢家に次ぐ大きな氏族だ．尾高豊作の配偶者の岡部豊子は岡部長景とは異母兄弟に当たる．

尾高豊作の娘尾高泰子からすると，岡部長発は直系血族，岡部長景は傍系血族に当たるから現行アルゴリズムでもトレース可能なはずなのだが… クラスタ図の枝は親子関係だが，婚姻関係は1個の節点（クラスタ）として集約されているので，尾高豊作→ 岡部長景のパスが検出できないということは考え辛い．SIMPLEGRAPH::GetHasseDiagramの論理を見直してみよう．

確かに，現行では到達できないパスが発生するのは避けられないように思われる．現行アルゴリズムは以下のようなフローになっている．

起点から上流/下流検定を実施する
すべての先祖ノードから下流検定を実施する
すべての末裔ノードから上流検定を実施する

この論理では傍系に到達できない可能性がある．書き直してみよう．先祖ノードからの下流検定と末裔ノードからの上流検定を一体化して，下流検定→ 上流検定→ 下流検定を反復する必要がある．⇒解決した．

▲MARGBOX::CheckMargBoxChangedで＠20渋沢市郎右衛門の先祖リンク不良が反復発生するのはなぜか？⇒該当する結婚枠が複数存在するためだ．⇒ダンプを抑制した．

▲現行では重婚クラスタ検定の入口で多重カードをカウントし，多重カードゼロの場合は重婚クラスタ図を生成しないようになっているが，つねに生成するようにすべきではないか？⇒多重カードゼロのサンプルは比較的単純なものが多いのでクラスタ検定を実施してもそれほど負荷が掛かる訳ではないのでやった方がよいと思う．やらなくても弊害はほとんどないとは思われるが，やっておいた方が安全だ．

画面サイズオーバーの問題が出ているので調べておこう．

▲系列分解図で栄一の系列を選択→新規部分図で部分図に切り替えようとして，TREEVIEW：CheckDispSizeOverのエラーになった．系列分解図でズーム倍率46%のとき，尾高磯五郎系列のカードを拡張選択して部分図：新規部分図で「現在の選択範囲を部分図に設定」した後，「部分図モードに切り替えますか？」→「はい」を押して，TREEVIEW：Zoom→ SetOuterFrameでエラーが発生する．OuterFrameには系図外枠が入っているが，幅が上限の32000を超えている．

しかし，選択された部分図の領域はそれほど大きなものではないので，全体図の領域と間違えているものと思われる．「部分図に設定」しただけでは描画領域は確保されず，部分図モードに切り替えて系統並び替えが実行されて初めて部分図の領域が確定するので，ZoomSetが掛かるタイミングが早過ぎる．ズーム倍率は描画に先立って切り替えておく必要があるが，適用される領域が間違っている（まだ計算されていない）．

TREEVIEW::CheckDispSizeOverはGetTitlePositionから呼び出されているが，GetTitlePositionの呼び元は2つある．①CallGetTitlePositionと②SetOuterFrameだ．前者はという外部関数から呼び出されているが，後者はLButtonUp, SetDispParm, SetTitleBox, UpdateDiagram, Zoomなどいろいろなところから呼び出されている．

TREEVIEW::ZoomSetにはapplyという引数があって，Zoomを実行するか否かを選択できるようになっている．これをオフにして呼び出せばよいのではないか？TREEVIEW::ZoomSetは，CtrlZoomSet, MakeLeastWindow, ZoomIn, ZoomOutから呼び出されている．今の場合は，CtrlZoomSetからの呼び出しだが，この関数ではモードがZOOM_RESETとZOOM_KINDREDの場合にのみ，ZoomSetを呼び出している．ZOOM_KINDREDは今の場合のような「図面種別の切り替えに伴うズーム倍率の変更」だからapplyオフでよい．ZOOM_RESETはVBのSetZoomRateで呼び出されるケースだが，これもオフでよいのではないかと思う．⇒これでこの問題は一応片付いたのではないかと思う．

しかし，今度はTRIBELIST::ShiftDirectAbsoluteでエラーが出るようになってしまった．先祖ノードのシフトを実行して，確定世代番号と人名枠の物理世代番号の不一致が起きている．下図は尾高磯五郎系列の「一部」を部分図としたもので，4系統に分離している．

関係の一部がカットされたために系列がバラバラになるのはやむを得ないというより，当然だが，出力がかなりおかしい．それぞれ独立系統なので先祖ノードが物理世代ゼロに配置されるのは当然だが，下流系との間にギャップが出来てしまっている．各カードに表示された確定世代番号を見ると，画面上の垂直位置と一致しているので，確定世代番号に従っていると言える．カード数は全76点だ．

GetHasseDiagramで距離数を確定世代番号に変換するところで失敗しているのだろう．系統ごとに基準点が異なるので一括して処理したのでは正しい値にならない．どうすればよいか？SIMPLEGRAPH：GetHasseDiagramの中で系統ごとに処理が閉じるようにしなくてはならないだろう．この修正は結構クリティカルなので，一度バックアップを取って最近の修正をフィックスしてから着手することにしよう．

RetrieveGhostではCHAOTICSTATEまではノーマル処理する＠20210301　1件
CHAOTICSTATEまではつねにノーマル処理する＠20210302　12箇所
NOMULTICARDを廃止する＠20210303　12箇所
仮修正 1箇所，暫定 2箇所，#if 0 4箇所

SIMPLENODEにはすでに使われなくなったdownwardとupwardという2つの変数があるのでこれらを廃止して，代わりにstrain（系統）という変数を導入することにする．⇒実装した．動作している．

渋沢一族の系列分解図は横幅が上限を超えてしまうため，「92.2%以上には拡大できない」が，その動作があまりよくない．ズーム倍率リストで100%以上を指定しても拡大されないが，警告も出ない上，画面が崩れる場合がある．倍率表示は100%，200%などになっている．ズームトグルボタンで100%に戻そうとすると初めてメッセージが出て92%に自動調整されるが，画面は左端に移動してしまう．ズームインボタンで拡大しようとしたときの動作はトグルボタンの場合と同じだ．⇒ズームリストツールを操作したときのコマンドが，ZOOM_RESETだ．

しかし，ズームトグルの場合のように自動調整は実行されず，メッセージも出ない．ざっと見た限りではトグルとリストツールで動作には差異がないように見える．どちらもTREEVIEW::Zoomを呼び出しているだけだ．VB側の動作もZView.Zelkova1.ZoomSetを実行した後，UpdateZoomRateしているだけだ．どこかで書き戻されているようだ．⇒これは結構難しい．ズーム倍率リストのSelectedIndexChangedイベントの中でテキストを書き換えても上書きされてしまう．ComboBoxではe.Cancelのような方法が使えない．

2021年3月3日2021年3月3日

渋沢一族のクラスタ図が5つに分離している

開発機とVAIO2で並行して渋沢一族の完全木テストを実行していたのだが，開発機の方はスリープから立ち上がれずに電源の再投入になってしまったため結果は分からない．VAIO2の方は遅々として進んでおらず，まだ全体図をやっている．開発機はZT Acvanced，VAIO2はZT Basicだが，どちらも遅い．開発機ではREFERENCECONTROLを止めた状態で走らせているが，それでも一面当たり15秒くらい掛かっている．

リリース版でテストするということも考えられるが，現行ではSTOP文をほとんどDEBUG_NEVERマクロに置き換えているので，リリースモードでは細かいエラーはほとんど捕捉できないのではないかと思う．開発ステージ的にはすでに「致命的ではないエラーはすべて無視」という段階に入っているのかもしれないが…

▲VAIO2で実行中の渋沢一族の完全木テストで例外が発生している．

例外がスローされました: ‘System.ArgumentOutOfRangeException’ (System.Windows.Forms.dll の中)

親族図:すべてのカード基準ノード=#759 佐藤菊子だ．エラーを無視して続行は可能．ZT Basicをリビルドしてテストしてみたが，再現できない．このエラーはVBで出しているものと思われが，スリープ中のアプリを起こしたときに何か画面上の操作が入ったのではないだろうか？

「RetrieveGhostではCHAOTICSTATEまではノーマル処理する＠20210301」というオプションを拡張して，「CHAOTICSTATEまではつねにノーマル処理する」としてみよう．

▲渋沢一族で部分図（中の家）を選択してNAMEBOX：RestoreExtractBoxで停止した．PartialMapCommand実行後の系統並び替え→ EraseTreeViewで系列枠不在が発生している．NAMEBOXのデストラクタに入ってきた時点ですでに系列枠への参照を失っている．TREEVIEW::EraseTreeViewでは無差別に描画要素を削除しているので，NAMEBOXより先にTRIBEBOXが削除されているのだろう．⇒フェーズがCHAOTICSTATE以下では系列枠不在を無視するようにした．

▲渋沢一族は完全に連結だと思っていたが，GetHasseDiagramのダンプで見ると，5つの系統に分離している．①渋沢栄一＠1，②岡部長景＠191，③吉阪俊蔵＠770，④正田建次郎＠624，⑤末松謙澄＠793だ．本当にそうなっているのかどうか確認する必要がある．⇒一見した限りではすべてのノードはどこかしらで連結しているように見える．

ゼルコバの木には「系統」という概念ないしオブジェクトは存在しないので，「系統を色別表示」などのことは直ちにはできないが，始系列は色別表示できるのでそれを見れば判定できるだろう．明らかに始系列は1個しかない．つまり，系図図面は連結でなくてはならない．ということは，重婚クラスタ分解に穴があるということを意味する．

▲渋沢一族の系列分解図を取ろうとして，TRIBELIST::MakeUpTreeで停止した．非始系列で系列優先実ノードを持たない系列がある．⇒いや，これはノーマルな状態だ．系列分解図ではすべての系列が優先実ノードを持たない状態になっている．つまり，始系列と非始系列を区別する意味がない．MakeUpTreeにはこのようなブロックが複数あるのですべて停止した．また，TribeRelocationで実行される

EstablishMajorTribeChainも系列分解図では不用なのでパスするようにした．これでようやく系列分解図が出力できるようになった．渋沢一族8には系列が107個入っている．つまり，先祖ノードが少なくとも107人登録されている．上記5系統の代表ノードから先祖ノードを探すと，

渋沢栄一＠1　→　渋沢市郎右衛門@20
岡部長景＠191　→　岩崎彌次郎@343
吉阪俊蔵＠770　→　箕作秋坪@387
正田建次郎＠624　→　正田貞一郎@625
末松謙澄＠793　→　伊藤助左衛門@661

とりあえず，これらの系列の部分図を作ってみよう．

▲系列分解図で栄一の系列を選択→新規部分図で部分図に切り替えようとして，TREEVIEW::CheckDispSizeOverのエラーになった．系図外枠が35025ｘ1489になっている．上限は32000ｘ32000なので明らかにオーバーしている．「この図面は 91.4% 以上には拡大できません．」という警告が出されている．しかし，部分図画面で100%に切り替えても特に問題は発生しない．500％まで拡大することもできる．どうも，部分図と全体図を取り違えているのではないだろうか？

渋沢市郎右衛門系列には165名収容されている．

▲岩崎彌次郎系列を選択して部分図に切り替えようとして，SIMPLEGRAPH::GetHasseDiagramで停止した．この関数を呼び出すときの引数seedが空になっている．tajugraph2の節点リストが空になっている．⇒エラーを無視して描画できたが，内容がかなりおかしい．

これは明らかに系列分解図としての出力だ．確かに現在の親族図の設定では「系列分解図」となっているが，それが部分図まで影響するというのは想定外だ．「特殊レイアウト」で「系列分解図」をオフにすれば図面は正常に戻るが，その代わり，全体図でも系列分解図オフとなり，図面が変化してしまう．全体図・親族図・部分図のそれぞれで図面モードを持つというのもかなり厄介だが，そうするしかないのではないだろうか？まぁ，これは後で考えることにしよう．

岩崎彌次郎系列を系列分解図で切り取るとき，矩形領域選択しているはずだが，余分なカードが付いて来てしまっている．栄一系列の先祖ノードの渋沢市郎右衛門だ．もう一度取り直ししてみよう．今度は渋沢市郎右衛門は含まれていない．シフトキーを押していればこのようなことも起こり得るかもしれないが…

岩崎彌次郎系列は23点だ．

箕作秋坪系列は43点．

正田貞一郎系列は12点．これには，正田建次郎の子ども3人は含まれていない．この三人は平山信系列の平山多美の預かりになっている．

伊藤助左衛門系列は25名収容だ．

これで5つの系列は取り終わった．後はこれらの接点を探すだけだ．いや，それは別に難しいことではない．全体図を系列分解すればすぐに分かる．たとえば，岩崎彌次郎系列の場合，系列分解図で彌次郎系列のすべてのカードを選択し，外部系列で選択状態になっているカードを見つければよい．岩崎弥太郎の娘岩崎磯路@347は木内重四郎系列に入っている．岩崎弥太郎の孫娘加藤悦子の配偶者岡部長景と弥太郎の弟弥之助の孫娘岩崎妙子の配偶者岡部長章はともに，岡部長発の孫だ．弥之助の孫の岩崎英二郎の配偶者北原篁子は北原白秋の三人の配偶者の一人佐藤菊子との間にできた子ども，などなど… しかし，これでは埒が明かないので，岡部長景の傍系親族図を取ってみよう．

岡部長景の傍系親族図は40点だ．これも部分図として登録しておこう．

▲EraseTreeView中，NAMEBOX::RestoreExtractBoxで停止した．(PHASE > INITIALIZING && !tywbox->IsExtractOrTooYoung()) という理由だ．tywboxのownerはすでに空になっている．⇒NAMEBOX::RestoreYoungWifeと同等の修正を入れた．

吉阪俊蔵の傍系親族図は37点

正田建次郎の傍系親族図は27点．

末松謙澄の傍系親族図は30点

渋沢栄一の傍系親族図も取っておこう．全239点だ．

岡部長景の傍系親族図と渋沢栄一の傍系親族図の接点が見つかった．尾高豊作＠22だ．手順は以下の通り．

一覧表表示範囲を「系図画面上のカード」に設定
岡部長景の傍系親族図を部分図で開き，全選択する
渋沢栄一の傍系親族図を部分図で開く
一覧表をスクロールして選択状態になっているカードを見つける

吉阪俊蔵の傍系親族図と渋沢栄一の傍系親族図には接点はない．

▲カード選択の動作がおかしい．部分図で全選択状態のまま選択が落ちない．選択と非選択が反転しているように思われる．部分図に切り替えて全選択した場合の動作もおかしい…

正田建次郎の傍系親族図と栄一の傍系親族図にも接点はない．末松謙澄の傍系親族図も同様．

▲全体図で表示を更新すると選択が落ちてしまう．⇒「選択を反転」→「選択を反転」で選択状態を復元することはできる．

吉阪俊蔵の親族図と栄一の親族図には直接の接点はないが，下図のように他系列との接点は存在する．

吉阪俊蔵の親族図と正田建次郎の親族図には接点がある．共通カードとして，坪井正道＠390，坪井信子＠391，坪井直道＠392がある．この三人は坪井誠太郎＋平山百合の子で，平山と正田は正田建次郎＋平山多美で繋がっている．吉阪俊蔵の配偶者箕作花子は箕作佳吉の娘，箕作佳吉の姉箕作直子の子が坪井誠太郎だ．また，吉阪俊蔵の子吉阪隆正は箕作佳吉の弟箕作元八の孫娘甲野富久子と結婚している．

伊藤博文の傍系親族図を部分図で開いて全選択→ 末松謙澄の傍系親族図を部分図→ 選択を反転でTREEVIEW::selectAllのエラーが出た．(!selectedcard || !selectedname)のとき，(topology->ActiveList->count)が起きている．

2021年3月1日2021年3月2日

CHAOTICSTATEまではノーマル処理する

▲軟体動物3.zelを開き，①マキガイとニマイガイを合体，②カタツムリとイカとタコを合体させて，RetrieveGhostのエラー「すでに廃棄中のノード対」が発生する．もう少し簡単な手順があるかもしれないが，少なくともこの方法で確実に再現できる．障害はCOUPLING：TopologicalSort冒頭のEraseTreeViewで起きている．フェーズはCHAOTICSTATEに入っているので，エラーを無視してもよいのかもしれないが，どういうフローになっているのか調べておこう．

UNDOありでゴミ箱なしというエディションだ．カタツムリとタコのカード合併でこれらが保持するノード対がClearPairBoxでパージされる．その後，系統並び替え→EraseTreeViewですべての描画要素が削除され，NAMEBOX #357 カタツムリ(0)が削除されている．このとき，PAIRBOX #406：#376 カタツムリ(1)→#357(0)がRetrieveGhostの対象となる．PAIRBOX #406はClearPairBoxですでにRetrieveGhostで処理されている．RetrieveGhostではこのノード対にdisableのマークを付けた後，(PHASE<=CLEARTABLE)という理由でゼロ復帰している．

RetrieveGhostはかなり複雑で大きな処理なので不用な摩擦を避けるために離脱することにしているものと思われるが，削除しようとしているノード対を放置したまま復帰というのは明らかにまずい．ゼルコバの木では基本的に「混沌とした状態」というのを認めないというのが方針であり，目標でもあるので，できる限りのことは実行すべきであると思う．フェーズはINITIALIZED=CHAOTICSTATEにあるので，この段階では処理を省略できないとしてみよう．また，仮に離脱する場合でも少なくともPAIRBOXを破棄してから離脱すべきだろう．最初にPAIRBOXを破棄してから離脱するようにしてみよう．⇒これでエラーは解消した．

CHAOTICSTATEまではノーマル処理するとしてみよう．ここまでできると「完全にクリーンなシステム」までは後一歩というところに達する．RetrieveGhostというのはこの種の処理としては最大で，それがこなせるとなればほとんどの場合はクリアできると考えられるからだ．⇒問題なく動作した．CHAOTICSTATE＝INITIALIZEDの前には，INITIALIZING→ INITIALSTATE→ GROUNDZEROしかない．

これらのフェーズはアプリ起動時と終了時にしか通過しない完全な「初期状態」ないし「初期化中フェーズ」と考えられるので，システム的な整合性が崩れるのはある程度までは避けられない．ゴミ箱を復活させてUNDOシステムとの整合性をチェックしておこう．⇒問題なさそうだ．かなりよい動きになってきたので，リリース版を作り直しておくことにする．⇒源氏物語全系譜6.1.ZELが完了した．実行環境は開発機，デバッグモード，エディションはZT BASIC．

ZT BASICで渋沢一族を開いてみた．描画までに8.1秒掛かっている．多重カードが2件ある．①#224 穂積万亀子と②#691 井上光貞だ．穂積万亀子は穂積八束＋浅野総一郎の娘浅野松の子で，栄一の子星野辰雄の妻だ．万亀子の2つのカードはとんでもなく離れている上，世代差もあるので，多重になるのも仕方ないという感じはするが，「重婚クラスタ循環」は発生していないので，不可避の多重という訳ではない．

井上光貞は桂太郎の孫で，井上三郎＋千代子の子であり，北白川宮能久親王の孫の二荒明子の配偶者だ．井上光貞のカード2枚は比較的近接しているので消去できそうにも見えるのだが… リリース版（ZT ADVANCED）ではどちらも解決して，多重ゼロになっている．これが，ZT BASICとZT ADVANCEDの力の差と見てよいのではないだろうか？井上光貞の場合はこんな↓感じだ．

穂積万亀子の場合は左に伸びる親子連結線が限りなく長いので追い切れないが，連結線を選択できるようになればそれも改善されるだろう．

従って，ZT BASICに求められるのは，これ以上の機能向上ではなく，障害で停止しないような安全な運用が可能であることにあると言ってよいと思う．渋沢一族の完全木テストを試してみよう．⇒早速障害が出た．ただし，これは開発機ではなく，リリース版の障害だ．

渋沢一族8.zelをただ開いただけでは発生しない．デスクトップ上に反例サンプルが複数できている．これらを開くとエラーが起きる．

▲BUG21-03-01 21-37-57.ZELを開いて，結婚参照番号不整合というエラーが起きる．また，CARDLINK::CheckCardLinkでvsprintf_sのエラーも起きている．このエラーは「父母ページ数の調整」をダンプしようとして起きている．⇒最終的には描画まで進んだが，中身はごく一部を除いて完全にバラバラになってしまっている．反例サンプルは全部で9つある．これらがどのタイミングで生成されたのか分からないが，その手順が分からないとバグを追跡できない．リリース版と同じ構成でビルドし直すところから始めるしかない．

▲新規ファイルの状態から，渋沢一族8.zelを開こうとして，nodule：Connectでエラーが起きる．TRASHCAN::ReuseWasteでオブジェクトを再利用するために，nodl_floatしようとしているところだ．Connect関数は付け替えをするときに，そのスロットの先住者を上書きする動作になっているためエラーが起きている．昨日の修正でnodule：nodl_floatを書き直しているが，ミスっていた．

接続元がIsAliveのときはスロットを開けるようにしているが，そうでない場合には放置している．これは「死亡しているノードは仮想関数SLOTが使えない＠20210111」という理由だが，ゴミ箱に入っているノードはDELETED == DEADになっているため処理されないことになる．DEFINETRASHCANの場合にはつねにスロットを空けるようにした．

渋沢一族は完全に連結だと思っていたが，GetHasseDiagramのダンプで見ると，5つの系統に分離している．①渋沢栄一＠1，②岡部長景＠191，③吉阪俊蔵＠770，④正田建次郎＠624，⑤末松謙澄＠793だ．本当にそうなっているのかどうか確認する必要がある．

渋沢一族をリリース版で開いたときの状況は多重カードの位置を確認することが目的だったので，基本的には系統並び替えその他のデータ操作は一切行っていないつもりなのだが，実際には障害が発生しているのだから，何かしらのデータ操作を行っていたと考えるしかない．何をやるとこのようなことが起こるのか？ともかく少し動かしてみよう．⇒いや，障害が発生していたのはリリース版ではなく開発機のZT BASICではなかったのか？リリース版では多重が発生していないから，ほとんど操作らしい操作をやった記憶がない．

しかし，開発機でデバッグ中には反例サンプルは生成されないのだから，机上に反例が残っているとしたら，アプリで生成されたと考えるしかないだろう．開発機上でリリースモードでテストしていたという可能性はないだろうか？完全木テストを開始しようとした時点で問題が起き始めたのだから，完全木テストをやってみればよいのではないか？上のような派手な障害なら必ず引っかかるはずだ．

参照番号200近くまで走らせたが，エラーは発生していない．当初のエラーの原因はおそらくnodl_floatの書き換えミスだったのではないかと思う．しかも，それを開発機上でリリースモードで走らせていたのだろう．開発実機のデバッグモードで渋沢一族の1面を描画するのに約8～10秒近く掛かっている．これでは一晩掛かっても終わらないのでVAIO2に移すことにした．VAIO2ではさらに遅く倍速1面で20秒くらい掛かっているが，仕方ない．やらせておくことにしよう．

▲開発実機で標準版をデバッグモードで走らせて，渋沢一族を開き，完全テストに入ったところでRestoreYoungWifeで停止した．(PHASE > INITIALIZING && !tywbox->IsExtractOrTooYoung())という理由だ．完全木テストに入る前に参照番号でテーブルの並び替えを実行している．その処理が完了した後の系統並び替えでエラーが起きている．

系統並び替え冒頭のEraseTreeViewを実行しているところで，NAMEBOXのデストラクタからRetrieveGhost→ RestoreYoungWifeの呼び出しが掛かっている．フェーズはCHAOTICSTATE = INITIALIZEDでINITIALIZINGよりも大きいために停止している．上記で「CHAOTICSTATEまではノーマル処理」としたためだ．

問題のTYW枠はMARGBOX #130718：＋→#37005 井上博邦(0)でこの結婚枠のTOOYOUNGWIFE属性が落ちてしまっているという点だ．⇒NAMEBOX::Dispose→ clearmarchainでMARGBOX：ReleaseMargBox→ ResetTooYoungWifeが実行されている．つまり，この結婚枠のオーナーとともに殉死しているということだろう．⇒結婚枠のオーナーが空ないし削除処理中の場合は停止しないようにした．