デバッグ作業が少し進み始めた．バグというのはとんでもないところに潜んでいるものだ．「デバッグにはいかなる予断も許されない」
▲UNDOBASE::SetUndoList→ で(!copynode->shadow)が発生
GetNewCard→ MakeNewCardで引数のrefnumが0のときは，mCreateCardで新規カードを作っている．mCreateCard→ CreateCard→ FAMILYTREE::getNewCard→ UNDOSYSTEM：CommandStart→ UNDOBASE::CommandStart→ BackupPointData→ SetUndoList→ で(!copynode->shadow)が発生している．⇒「生成したばかりでshadowを持つはずがない＠20170823」というブロックが削除され，代わりに「1行削除＠20220423」が入っている．この日付は2022-04-23だが，この修正は実際には2022-04-26-1で初めて入っている．この辺りのログを読んでみよう．
2022-04-29のログはそのものずばり，「UNDOBASE::SetUndoList で(!copynode->shadow)により停止した」となっている．⇒この記事では対処されていない．問題がメモリ不足の問題にすり替わっている．⇒2022-04-27で「UNDOに関する修正をフィックス」している．おそらく，ここで誤ったものと思われる．「UNDOのShadowをfreeblock化＠20220423」2箇所 に該当するのではないか？
「UNDOのShadowをfreeblock化＠20220423」というのがある．この日付が20220423となっているので，整合している．この定義はFIXED＠20220426でフィックスされている．#ifndefのマクロで#elseが活きなくてはならないところを誤って削ってしまったのだろう．⇒復活させた．修正のフィックスでバグを作り込んでしまっていた．⇒別のエラーが出るようになった．
▲UNDOBASE::CommandEndでUndoCurptrが空になった．⇒PergeZenpoChainで空にしている．UNDOBASE::CommandEndは戻り値としてlongを返しているが，この値は初期値0のままで使われていない．⇒「ringTopが空のときはつねにPergeZenpoChainを実行する＠20170515」となっているため，PergeZenpoChainが実行されている．UNDOSYSTEM::CommandEndには「UndoCurptrが空となる場合があり得る？＠20220418」というコメントが付いている．この関数は外部で致命的エラーが発生したときには，fatalerrorを返している．
PergeZenpoChainでは，Undoチェーンの後方ノードが空，つまり，UndoCurptrが末尾ノードである場合は，UndoChain，UndoCurptr，UndoNumberをリセットしている．また，UndoCurptr＝UndoChainの場合（UndoCurptrが先頭ノードの場合）も同様動作となる．従って，UndoCurptrが空となるのはノーマルな状態であると考えられる．
if (lret >= 0 && !UndoCurptr) STOP; あり得る＠20220418 となっていたのだが，同日付であり得ないに変わっている．⇒lretにUndoNumberを格納してチェックを回避するように修正した．⇒どこかでハングしている．強制ブレーク→続行しようとして，以下のような見たこともないパネルが出た．
デバッグの中止もできない．どうも，このエラーは「Attempting to get the view from an adapter in state TextDocDataAvailable」はかなり始末が悪そうだ．ネット上にも情報はあるが，あまり役に立たない… デバッガに関係するものであるような気がするが…
PHASEがINITIALIZINGのままになっている．どこかで横道に逸れてしまっているのだろうか？エラーが発生しているのだろうか？CZelkovaCtrl3::TopologicalSortで-1017を返している．この値はCallSortLineageの戻り値だ．ERR_AUTOCORECTEDDATA（自動補正されたデータ：保存が必要）という通知だ．InitializeDisplayではUpdateFlagをオンにして対応しているが，Currefnumに0を格納しているため，動作がおかしくなっているのではないか？
Z.BaseRefnumには1が入っていて，GetRecordNumberでレコード番号を取り出そうとしているが，0が戻ってくる．Z.mSendRequest(4) ‘基準ノードの参照番号を請求する ＠＠2016-10-22 というのがあるので，これで取り出してみてはどうか？⇒対処した．これで描画できるようになった．⇒この修正でGetNewCard→ MakeNewCard→ mCreateCard を通らなくなってしまったので，UNDOが掛からないようになっている．暫定修正を入れてもう一度動作確認してみよう．CommandEndの動作にはまだ少し疑問がある．
- (UndoCount <= 2)のときは，なぜUndoCurptrを繋ぎ変えてUndoChainに戻しているのか？
- なぜ，UndoCurptr->ringTopは空になっているのか？
FAMILYTREE::getNewCardは-10018を返している．⇒このエラーコードは「カード登録数がカードリンクテーブルのサイズを超えた」の意味だ．しかし，UNDOBASE::CommandEndにはアプリケーションの処理結果は一切入ってこない．⇒一手間かかってしまうが，アプリの処理結果をCommandEndに渡すようにしておいた方がよいのではないか？処理が失敗したときには，そのコマンドは破棄されるというのが当然の動作になるのではないかと思う．⇒一度バックアップを取ってから取り組むことにしよう．⇒ZELKOVA 2022-12-24 Aとして保全した．
「CommandEndに処理結果を渡す＠20221224」で修正しておこう．⇒処理により，戻り値が結構あいまいな場合があるので，ケースバイケースで導入するものとし，今回はMAKENEWCARDにのみ限定適用とする．⇒PergeZenpoChainを実行して0復帰するようにした．UndoCurptr, UndoCount, UndoNumberはすべて初期化されている．
CommandEnd(DELCARD)では負値を返している．CommandEnd(DELALLCARD)，CommandEnd(MERGECARDS)も同じ．これは別途チェックしておく必要がある．⇒UNDOBASE：CommandEndでは特に何もしていない．現行ではUndoNumberを返すようになっている．UNDOSYSTEM::CommandEndではTopologicalSortの結果を返すようになっている．致命的エラーが発生したときには，fatalerrorで復帰する．
▲UNDOSYSTEM::CommandEndで0復帰すると，画面が表示されない．なぜだろう？⇒GetNewCardで新規ファイルに失敗しただけで何も表示されないというのはかなりおかしい．⇒画面の更新はRefreshSubで実行されるが，更新のダブりを抑制するためのRefreshFlagはデータベースの読み込みが完了するまでは落ちない．このため，事実上UndoStatusの実行時にしか画面は更新されないようになっているが，これまでの論理ではZ.mUndoStatusがゼロの場合には画面の更新は実行されなかった．⇒UNDOSTAT.UPDATEDIAGRAM) <> 0 の場合はつねにZView.RefreshSubを呼び出すように修正した．
ここで一度バックアップを取っておこう．
▼MAXUNDOCOUNTに達したときの動作を確認する
▲Undoでテーブルが更新されていない．⇒UndoStatusに組み込んで動作するようになったが，呼び出し頻度が高過ぎる．⇒CardUndoRedoから呼び出すのが適切だ．⇒もともとこの位置から呼び出していた．
▲カードを１点づつ５点削除したあと，Undoを2回反復して，UndoProcessでUndoNumberの不一致 (UndoCurptr-> UndoNumber != UndoNumber)が発生．前者が7，後者が8．また，Undoで最初の50点まで戻れなくなる．
▲一覧画面が毎回同じ場所・サイズで開く．前回の場所を覚えていない．⇒現在位置は覚えているが，ファイルを閉じると忘れてしまうようだ．⇒ダブルクリックでオープンしたときは，DockingWindowFunc(False) が実行され，このときのウィンドウ位置を記憶するという動作になっている．⇒暫定的にこの動作を止めて任意の場所で開けるようになった．
▲テーブルをクリックしてCardTable_MouseClickが起動しない．⇒MouseClickというイベントが見当たらない．MouseDownというのはある．⇒MouseDownでも入ってこない．
▲CardGridView_CurrentCellChanged→EditTableEnd→…FAMILYTREE：GetCardBaseで(PHASE < DRAWSTAGE) で停止した．