▲Undo処理中にRestoreShadow→ InsertLinkでエラーが出た．挿入しようとしている位置にすでにリンクが存在しているというエラーだ．⇒再現しないが，別のエラーが出た．
linkの参照番号は@233でこれからrecnの233が計算されたものと推定されるが，その場所には@233の別のカードが存在している．削除されたカードの参照番号は基準ソート以前のものと推定される．この状況で間違っているのはどちらのリンクと言えるか？
UNDOSYSTEM::RestoreShadowでは，レコード番号をshadowの親番から取っている．これは正しいのではないか？基準ソートのUndoが正しく動作していない可能性が考えられる．⇒従前では，NAMESORTはCardNumListとMargNumListを保持していたが，現行では完全に抹消されている．これらのリストには有効な参照番号の写しが格納されている．これは必要だったのではないだろうか？⇒確かに基準ソートでリナンバーしなければこのエラーは発生しない．
▲カードを70点選択→ 単点削除→ 単点削除→ 単点削除→一括削除→ 基準ソート→ Undoを実行して，UpdateCardBaseで基準ノード不在エラー(!basenum && CHARTTYPE != DISP_IMPORT)が起きた．⇒*basecardは0だが，*basepartには237が入っている．表示モードは部分図だ．呼び出し元のmZelkova::mUpdateBaseRefnumでは，BaseDispAll=3079，BasePartial=134が入り，それを引数で渡している．「参照番号が一致しない場合は更新とする＠20180129」という論理で*basecard = 0に変わっている．⇒エラーを無視して続行で，上のエラーが再現した．
完全に抹消してしまっているので，かなり大変だが，CardNumListを復活させておこう．BuildNumListという関数も必要だ．「参照番号を永久コード化する＠20230109」というオプションでパージした部分だ．⇒「参照番号を永久コード化する」というのは覆されてはならない決定である．抹消したコードを復活させることは不可能ではないが，必ずしもベストソリューションとは言えないのではないか？むしろ，この方向を突き詰めて，「基準ソートを実行しない」，「参照番号をユーザから隠蔽する」という方向に進むべきなのではないか？
基準ソートを実行すると，参照番号が１から始まる通し番号になるというのは悪くないが，たとえば，結婚参照番号はまったくユーザに公開されていないが，それによる不都合は基本的に存在しない．もし，仮にカードの参照番号をソートするのであれば，その時点ですべてのUNDOを一旦破棄せざるを得ないだろう．そこまでして，実現するだけの意味があるだろうか？基準ソートを実行するか否かは今のところペンディング事項だが，それを実行した場合にはUNDOをリセットするという作りにしておいた方が安全だと思う．⇒一応動作チェックしておこう．
▲基準ソート→ Renumberを実行→ UNDOリセットを実装して，基準ソートを繰り返したところ，CARDTABLE::Renumberで(max && max == maxrefnum)のエラーになった．maxrefnumは基本的に単調に増加すべきものと考えられるので，同じ値をセットする操作はイレギュラー動作とみなされる．しかし，Renumberは参照番号の振り直しなので，そうなることは避けられない．⇒Renumber時には，maxrefnumをリセットしておけばよいのではないか？⇒解決
▲部分図から全体図に切り替えて，どこかでハングしてしまった．⇒かなりまずいことになった．系統並び替え→ 三極検定→ 極大セグメント検定でハングしている．maxloopが302という大きな数字になっている．REDLINEの値は50だ．⇒どうも，UNDOのインタフェースが壊れてしまったようだ．VB側で，LineageSort→ ChangeBaseRefnum→ UpDating→ UndoStatus→ RefreshSub→ LineageSortで無限ループに陥っている．ChangeBaseRefnumで誤動作しているようだ．
Z.BaseRefnumが3079なのに対し，Zelkova1.TopologicalSortが171という数を返しているためだ．画面は部分図になっているのに，DispPartialMapがFALSEになっている．⇒DispPartialMapを強制的にオンにしたら，抜けてきたが，エラーパネルが出ている．
画面はいつの間にか全体図になっている．カード画面は「系図画面上のカード」で，全体図なら300が正しい．部分図なら271のはずだ．どうも，かなり話がこじれてしまったような感じだが，再現できるだろうか？⇒基準ソートとおそらくそれに伴うUNDOリセットの影響と思われる．起動→ 基準ソート→ 部分図⇒全体図で再現できる．UNDOチェーンのリセットだけでそれほどの影響が出るというのはほとんど考えられないのだが… 基準ソート実行後は，VBで基準カードの切り替えを行っているが，それほど致命的な操作とは思えない．戻り値の参照番号は176だ．障害は部分図⇒全体図の切り替えで起こるので，どこかで何かしらの齟齬が発生しているものと思われる．基準ソートを実施していなければ，この切り替えは問題なく通る．
何かパラメータが落ちているのだろうか？このエラーは初回限りで，別の操作を行ったあとの，基準ソート→ 部分図⇒全体図では（操作を反復しても），起きない．⇒ChangeBaseRefnumの出口でやっていた操作（Z.BaseRefnum，Z.BasePartial，Z.BaseDispAllの更新）をUpDatingの前に実行するようにして解決した．
TOPOLOGY::GetRecordを包括的に使うように修正した．
- 修正した関数：
- CARDTABLE::GetCardBaseRecord
- FAMILYTREE::GetRecord
- TOPOLOGY::UpdateRecordFunc
- TOPOLOGY::GetActiveRecord ⇒ 廃止
- PARTIALNAME::GetPartialRecord ⇒ 廃止
- FAMILYTREE::GetAllRecord ⇒ 廃止
▲テーブル並び替えでは「現ソート列」を管理しているが，Undo/Redoしたとき，アプリに伝達されていない．