インポートファイルの読み込みとテーブルの構築を別ループに分けてみたが，パフォーマンスは変わらない．どうもDLL側になにか原因があるようだ．DLL側ではTREEVIEW:SendUpdateDataという関数で処理しているが，時間を消費しそうな箇所は見当たらない．1レコードを受理すると，人名リンクを1個生成するCARDTABLE::makelinkが呼び出される．SendUpdateDataではこのオブジェクトに値を転記しているだけで，それ以上のことは何もしていない．多分結婚リンクはカードをすべて読み込んだ後で実行されるのだと思う．人名リンクはそれほど大きなオブジェクトではないし，メモリ逼迫の要因になるとは考えられない．
確かに，VBからZ.mSendRecordDataの呼び出しに要する時間は当初の10msくらいからかなり急速に増加して，320点の辺りでは1秒掛かるようになってしまう．CARDLINK::makelinkで時間の掛かりそうなところとしては，①newlink，②BackupPointData，③MakingLookUpがある．このうち，②はUNDOに関係するものなので，止めてみよう．⇒確かにこれが原因だったようだ．今のところUNDOは不要なので，止めたままにしておく．⇒アクセス違反などが発生しているが，描画できた．
▲コラッツ1000.zelを開くのにかなりの時間が掛かり，マネージド・デバッグ・アシスタントが作動して停止する．
▲このサンプルは単純な木であるのに，ZTYW処理が作動している．暫定的にgoodsonを空としているため，例外が発生する．
▲人名枠高の計算がかなりおかしい．フォントサイズを大きくすると枠が伸びて世代境界を超えてしまう．しかも，人名が消えてしまう．系図画面設定でパラメータを変更しても画面に反映しない．⇒系統並び替えで正常に戻った．
▲親の垂線が兄弟連結線から突き出ている．⇒系統並び替えで戻る．
なぜだろう？スクリーンショットをペイントで開いて保存したファイルが壊れていて，開けない．⇒接続が切れていた．⇒画像の一部を切り取って保存した．横長の扁平な図形なので全体を取ってもあまり美的ではない…
世代数はもっとも高いところで10世代だ．667584453というのが多分この図に含まれる最大数だと思う．ノード数は1000しかないが，コラッツ関係の画像でここまでの図面は世界中探してもないと思う．PDFに落としてみよう．前日の修正が反映していないので，myAppが空になっている．確か，2つのクラスでdoClearを追加したような気がするが…修正はPAGESETUPだけのようだ．
コラッツ1000.PDFの左下隅の大きい数字が固まっている辺りを切り出してみた．
悪くないのではないかと思う．FBに投稿しておこう．⇒コラッツ1000.PDFのリネームができない．ファイル所有者の許可が必要だという警告が出る．コピーしてしまえばこっちのもののような気もするが，ローカルでコピーすることもできない．いや，当然かも知れない．ネットの向こうのマシン上のファイルをリネームしようとしていた．EdgeでPDFを開くと回転ができる90°回転すると，数字が縦になって読みやすくなる．ただし，その状態では保存できない．Chromeでは保存できた．これを出品することにしよう．500％までしか拡大できないが，十分だ．これができるのなら，座標変換しなくても現状のままで国際版を名告ることができる．
おかしい．最大数の667584453が重複している．ノード数は1000で合っているのだが…⇒読み込んだCSVでは1箇所だけだ．OpenOfficeでソートしたときにやり損なっているのだろう．⇒最初に番号列でソートし，次に氏名でソートしているが，2回目の氏名でソートのところでダブるようになる．単独で氏名でソートしても同じ結果になる．項目が重複しているのだから，ソートによってどこかに潰されたデータがあるということになる．かなりまずい．おそらくOpenOfficeのバグと見られるが…このダブリは完全に同一行ではない．父番号と属性が異なる．⇒読み間違いだ．正しくソートされている．ダブリではない．1文字違いで，667584433というのがあった．
数学物理etc（談話室）にアップロードしたファイルをダウンロードしてチェックしたら，回転が戻ってしまっていた．まぁ，仕方ない．ファイルを差し替えてみたが，同じ．ノーマルに見えるファイルをローカルでコピーしても同じような動作になるので，ダメのようだ．
