「系列内スプリット問題」は解決した．ここで一度リリース版を起こしておくことにしよう．”Version 2.2.0.012 Release 2020-10-30 今回も手順を省略した簡易手順の所内版としておく．リリース版更新の手順リストを作っておきたいが，プリンタがインク切れになっているので後日またということにしよう．⇒おかしい．ライセンスコードが合わない．⇒ライセンスファイルの内容は正しい．リリース版の方が間違っている．しかし，Version 2.2.0.012 は合っている．よくわからないが，アンインストール→再インストールで一致した．
▲ZTシステム構成図(ERR11).ZELの部分図でズームの動作がおかしい．この不良はリリース版でも起きる．全体図，親族図では問題なく動作しているので，部分図に限った不良だ．これは最近になってからの事象と思われるが，古いバージョンで動作を確認してみよう．⇒V2.2.0.008_R20201014を走らせてみたが問題なく動作する．⇒V2.2.0.011 R2020-10-25ではすでに不良が発生している．V2.2.0.0010 R2020-10-17は動作する．これはZELKOVA 2020-10-24に入っていたものだが，2020-10-23のデバッグ版でも動作している．⇒これはプログラムではなく，データの問題ではないかと思う．
現行版ではMAXPARENTS=32になっているが，以前のバージョンでは4になっていたので，MAXPARENTS=8という版を作成してみた．サンプルを読み込ませるとこの版でも障害は発生する．別に保存してMAXPARENTS=32で開いてみたが，動作は変わらない．このデータの部分図で「画面上のカードを保存」し，再度開いてみたところ，不良は発現しなくなった．オリジナルをMAX=8版で読み込むと，「修復しました」が出るのでまったく同じデータとは言えないが，外形的には同じ．オリジナル版の部分図をMAX=32バージョンで部分図をファイルに保存したサンプルはMAX=32版でも正常にズーム操作できる．このときも「修復しました」が出ている．どこを「修復した」のかが問題だ．
「同一親ページの重複を検出」で停止．treeviewが①pagesetupの単身婚，②pagesetup＋PAGESETUPを持っていることが原因と思われる．部分図にはPAGESETUPは含まれないので父pagesetupのページが2つになってしまったものと思われる．⇒確かにオリジナルでもPAGESETUPを母から取り除いて父母ページ3にしてしまえば事象は解消する．父ないし母を複数持つということはあり得るが，同じ人名が複数のページで同時に父ないし母になるということはあり得るだろうか？
ある人物が子どもを持っていて，後妻を持ち（後妻が）その子どもと養子縁組するということはあり得るのではないか？このとき，父＋後妻→子どもではなく，後妻→子どもという関係を成立させるのは不自然だ．とすれば，父が複数ページに現れるのは避けられないということになる．問題を2つに分けて考えよう．
- 画面上のカードを保存では生成されるファイルは誤りを含まない正規データでなくてはならない
- 父ないし母が複数ページに存在するときの描画上の不具合，ないし，部分図で実質的に項目1のような状態になっているときの対処法
ファイルを読み込んだときに行っている整合性検査をファイル書き込みに先立って実施すべきだろう．可能だろうか？現行では部分図を操作するとき，独立のデータテーブルを使わずに，オリジナルのテーブルの上でやりくりしている．方式的には独立のテーブルを使って既存論理だけで操作するというのが一番わかり易いが，不整合が発生する可能性があるため，現行方式となっている．
部分図では表示するカードが削減されるだけで，関係はすべて温存される．これには利点もあれば，欠点もある．部分図の2つのノードの親等を表示したときに，経路が変化していれば親等が変化することも避けられない（これは事実に反する）．いまの場合は本人の母が部分図で非在になった結果，父だけの結婚ページが複数生じるという事態になっているのだが，これを検出できるだろうか？なんらかの方法でこれが検出できればその結婚を非表示にすることで対処できる．実際，部分図を生成する論理では初期化の段階でそれを実施しているはずなのだが…
部分図の場合，ExtractPartialCardで有効なカードと結婚を抽出している．しかし，上記のような矛盾を回避するためにはより厳格な検査が必要になる．FilteringKinshipでは表示モード（祖系図，血統図，親族図，単式図など）に従ってフィルタリングを行う．フィルタリングではカードリンクを削減しているので，この段階でも上記のような矛盾が生じる可能性はあると考えられる．TribeDecompositionが系統並び替えの本体だが，この前に片付けておく必要がある．FilteringKinshipの後でCountValidMargを実施しているので，ここで有効な結婚枠が確定するものと考えられる．FilteringKinship→HideNameboxでも結婚枠の有効性チェックを実施している．
「有効結婚枠判定の厳格化＠20201030」というオプションで修正を入れることにしよう．以下のような修正が必要だ．
- CountValidMargとHideNameboxの処理は重複しているのでHideNameboxに統一する
- ExtractPartialCardで結婚リンクを無効化しているが，これも不用と思われるのでHideNameboxで一括処理する
- HideNameboxでは親ページの重複を検査する この検査は有効な父と母が同じ結婚リンクを重複とみなし，いずれかを削減する
ただし，項目3はやや微妙なところがある．3に該当するのは父ないし母のみのケースに限定すると考えられるが，たとえば，父だけが2つの結婚に残った場合には父の子ども枠では2つの結婚の子どもが合併されなくてはならない．⇒いや，それほど単純なものではない．もし，子どもが残っているとすればその結婚は母方に表示される可能性もある．父方に残った場合には拡張子ども枠として処理されるからそれ自体はおそらく問題にならないはずだ．以下のような場合を考える．
この関係の直系血族図は
のようになる．異母兄弟は拡張子ども枠として処理されている．妻1と妻２が同じこどもを参照している場合には，以下のようになる．これも問題ない．
直系親族図を出すと
特に問題なく描画できている．では何が問題なのか？子１を夫の単身婚の子どもとして追加しても特に問題は生じない．夫→子１，夫＋妻１→子１，夫＋妻２→子１の3つの結婚があるときに，直系血族図を出すと上の図とまったく同じになるが，結婚枠は3つ表示されている．ただし，そのうちの2つは子ども数ゼロで不可視になっている．
おかしい．障害が再現できなくなってしまった．途中で保存してしまったかもしれない．⇒一つだけ残っている．「系列内スプリット MAXPARENTS=4.ZEL」というファイルだ．サンプルは基本的にすべて読み取り専用に設定しておく必要がある．デスクトップ上のサンプルだけでも読み取り専用に設定しておこう．
障害はいろいろなズーム倍率を与えたときに画面が再描画されないという症状だが，一度表示→系図画面の更新を実行するとその後は問題なく動作するようになる．この不良は特定のサンプルでしか起きていないようだが，上記の解析で見ているような問題ではなさそうだ．
反例サンプルでpagesetup(0)→treeview(0)が2つあり，しかもどちらも可視というのはやはりかなりイレギュラーだ．出口検査では多重ゼロとなってはいるが…確かに同じカードに入っているから，多重の定義には当たらないが，本来ならどちらかを消去しなくてはならないところだ．結婚が2つあるとすれば当然仮ノードを2つ生成しなくてはならないのだから，それが同じ仮ノードを指しているというところがそもそも間違っている．⇒読み違えていたかもしれない．pagesetup(0) →treeview(0)という結婚は一つしかない．
TREEVIEW::DrawControlの問題のように思われる．この関数の出口で必ずRefreshを実行するようにしたら，問題なく再描画できた．⇒updatebitmap1が立っていないと画面は更新されない．⇒updatebitmap1は立っているが，TREEVIEW::BuildBitMapで「系統並び替えで遅延処理されるためここではパス」という理由で抜けている．しかし，ズームの場合には通常系統並び替えは実行されない．
系統並び替えが実行されるか否かはFAMILYTREE::spantreenodeで判定される．通常画面が再描画されたときにはspannodcountはクリアされるはずだから，このカウントが間違っていることになる．TREEVIEW::RefreshかないしDrawControlでリセットされなくてはならないはずだが，残ったままになっている．⇒TOPOLOGY：topologicalSortではリセットしている．TREEVIEW::DrawControlでリセットするというのが適切ではないか？系統並び替えを実行して画面がそれに同期した時点で落とすというのは理に適っている．実際，そのような論理に変更して再描画が掛かるようになった．
最後の系統並び替えでリセットされているとすれば，その後どこでセットしているのかは調べておく必要がある．OpenFileProc →InitializeDisplayでChangeTitleDate→＜PARTIALMAPS．PARTIAL_UPDATE＞→PARTIALNAME::partialRegisterが実行される．partialRegisterでは部分図モードのときはupdatespannodを実行する．部分図のタイトル情報の更新で系統並び替えが実行されるというのは明らかに誤りだ．PARTIAL_UPDATEというのは「日付のみの登録更新」なのでこのケースではupdatespannodするべきではない．しかし，partialRegisterには情報が渡されないので判定のしようがない．PARTIALNAMEにコマンドというメンバー変数を置くのが早い．※
※コマンド処理の入口で設定するのがベストだが，実装ではコマンドごとに個別に更新が必要か否かを判定している．戻り値でこの値を返すことも考えられるが，戻り値では別の値を返している．
TREEVIEW::DrawControlの出口でリセットするというのはやはり問題がある．DrawControlでは描画を遅延処理する場合があるので，フラグが落ちると系統並び替えが掛からなくなる可能性がある．⇒この事象が初回だけ起きるというのはこの日付の登録がファイルオープン時にしか起こらないためと考えられる．⇒ダメだ．まだ画面の更新ができない．⇒抜けがあった．複数箇所で設定している．
これで問題は解決した．バックアップを取っておこう．
▲縦長い図面のとき，画面に合わせてズームと縦幅に合わせてズームで微妙に高さが違うのはなぜか？⇒理由は分かった．縦幅の場合はスクロールバーが出ることがあるので，それを見込んでいるためだ．フル画面ではスクロールバーもたないので，縦幅よりやや広くなる．フル画面の場合もやや狭めて一致させてもよいが…現状でもよいような気はする…「つねにスクロールバー幅を減じる＠20170510」というコメントが残っている．しばらくこれ（画面に合わせると縦幅/横幅に合わせるを一致させる）で様子を見ることにしよう．
▲ファイルを閉じようとするとき，ときどき下記のパネルが出る．
検索文字列.txtには検索履歴が入っているはずだ．現在14個テキストが入っている．アクセスを拒否される理由が分からない．停止しているのはCOUPLING::SaveFamilyTreeでASSERT_NEVER (!undosys)によりSTOPしているようだが，デバッグモードではただ止まるだけのはずなのだが…そもそもERRORCLOSEDという文字列はこのシステムには存在しない．いや，あった．MDIFormCloseのエラートラップだ．MDIFormCloseで以下を実行したときに起きる．⇒StringReaderを使ったままにしていたからではないだろうか？どうもそういうことのようだ．いままでこのようなことはなかったような気がするのだが…