▲ZView.vbを開いて，COUPLING::GetUserFont:フォントサイズゼロエラーが起きる．これはZELファイルのアイコンをダブルクリックしてオープンしようとするときに出るエラーと同じだ．シューティングはかかり難しい．ZView.vbのオープンはデバッグを開始することには当たらないので，デバッガが作動していないから，ブレークポイントなどを仕掛けても止めることができないため，ほとんど状況が掴めない．
障害はCOUPLING::GetUserFontでScaleFontSizeがゼロを返しているために起きている．このあと，MakeSolidFontを実行したあと，GetUserFontを再帰実行して復帰しているが，ループしてしまう．ScaleFontSizeの値がゼロとなる理由として考えられるのは，PNTPERLOGがゼロであるためと考えられるので，この値に初期値1.0を与えるようにしたところ，今度はMAPPINGのズーム倍率がゼロになるという不良が発生するようになった．前門の虎，後門の狼という状況だ．しばらくデバッグというのをやっていないので，SearchWrongObjectなどデバッグ用ツールの錆落としから始めなくてはならない．
TREEVIEW::mapping.zoom_normalがゼロとなっている理由は，TREEVIEWのコンストラクタで固有データ部をゼロクリアしているためだ．それをやっているのはsetpidだが，この関数は共有関数なので広く使われている．MAPPINGのコンストラクタはzoom_normalなどのメンバー変数を初期化しているが，それを上書きしている．廃棄オブジェクトのリサイクルでも同種の問題があり，TRASHCAN::ReuseWasteから呼び出されるdoCleanではメモリを全クリアする前に維持する必要のある変数を保全するようになっている．operator newではメモリを全クリアしているので，setpidで固有データ部を全クリアする必要はないのではないだろうか？この修正の影響範囲はかなり広いとは思われるが，setpidでメモリ全クリアを実施しないようにしてみよう．
まだ，どこかでクリアしているところがある．ファイルをオープンする前に一旦クローズしているが，そこで実行されるEraseTreeViewでクリアしているのではないか？いや，CleanSlotではそこまでやっていないはずだ．EraseTreeViewのあと，COUPLING::Clean→ TREEVIEW::Clean→ doCleanが実行される．この設計はあまりよくないような気がする．オブジェクトを温存させたままクリーニングするより，一度delete してから作り直した方がわかり易かったのではないか？とりあえず，ここではMAPPINGのコンストラクタでやっている処理をclean(void)としてくくり出し，doCleanから呼び出すことにする．
開発機の完全スキャンが完了したが，まだ5件の脅威が検出されている．
これらはとっくの昔に除外リストに登録されているはずなのだが…というか，ハッシュ値を計算しているので除外リストへの登録にはなっていないのだが…ハッシュ値が変化しているとすれば相当な問題だ．ハッシュ値の計算値を記録してみよう．
- D:\ZELKOVA 2022-03-08\ZekovaVB\obj\Debug\ZelkovaTree2022.exe 80BFC63F34A43E1A4F0E5B321A2EC3BDED3911AA65984765D06B4E30A00C63AC
- D:\ZELKOVA 2022-03-08\debug\app.publish\ZelkovaTree2022.exe 80BFC63F34A43E1A4F0E5B321A2EC3BDED3911AA65984765D06B4E30A00C63AC
- D:\ZELKOVA 2022-03-08\debug\ZelkovaTree2022.exe 80BFC63F34A43E1A4F0E5B321A2EC3BDED3911AA65984765D06B4E30A00C63AC
- D:\ZELKOVA 2022-03-02\ZekovaVB\obj\Debug\ZelkovaTree2022.exe 066B292370D40C40CBD5B36FA2E0E0C98BA52889BF02CA462F6CEDBFB3D482A8
- D:\ZELKOVA 2022-03-02\debug\app.publish\ZelkovaTree2022.exe 066B292370D40C40CBD5B36FA2E0E0C98BA52889BF02CA462F6CEDBFB3D482A8
とりあえず，MAPPINGのズーム倍率がゼロになる問題は解消したものと思われるが，ZView.vbを開いたときのエラーはまだ残っている．
ソースコードの修正が動作に反映しない．⇒Program Files (x86)のbabalaboフォルダに入っているOCXを参照している．アプリをアンインストール→リビルドで動作したが，別のエラーが発生している．基準ノード番号がゼロというエラーだが，無視でファイルをオープンできた．
ファイルをクローズしたときにもエラーが出たが，その後はオープン・クローズを繰り返しても何も出ないようになった．
昔々，OCXを任意のVBアプリに挿入して直ちに動作するような作りを試していたころがあったので，その名残りではないかと思うが，デバッグできないのでどういうフローになっているのか？ほとんど見当もつかない．多分この修正で，ZELファイルのアイコンをクリックして表示されるエラーも解消しているのではないかと思う．しかし，スクロールバーの問題はまったく解決していない．というか，スクロールバーがまったく出なくなってしまった．なぜだろう？
コントロールサイズはOCXのMoveControlイベントで引き渡される．この値が逆転している．現状ではW=1531, H=713となっている．⇒TREEVIEW::GetScrollValueでコントロールサイズを返している．この関数ではGetViewSizeで値を取り出し，LPtoDPで物理単位に変換している．この関数をオーバーライドしてみよう．⇒確かにこの修正は正しいようだ．縦スクロールバーが表示されている．ただし，スクロールバーをドラッグしてもうまくスクロールできない．また，リールを回すとスクロールバー自体が消えてしまう．
LPtoDPは34箇所に出現する．おそらくこれらすべてを書き換える必要があるだろう．⇒とりあえず，引数がtagSIZEであるような箇所だけ修正してみた．これでスクロールバーの操作はリールを含めてできるようになったが，内容は同じだ．つまり，スクロールできていない．これに対処するにはおそらく，引数が矩形の場合と点座標の場合のすべてに対応する必要があるだろう．⇒対処した．完全に動作するようになった．
▲リール操作中，ZView.vbのMoveControlで停止した．AutoPosition.Yが負値になっている．この値は，OCXからMoveControlイベントで渡されたものだ．FramePositionの呼び出しはモードにより，
- SETFRAME_SCROLLCONTROL
- SETFRAME_CONTROLSIZE
- SETFRAME_MOUSEWHEEL
- SETFRAME_SCROLLBAR
- SETFRAME_MOVECONTROL
の別があるが，このうちMoveControlSubを実行しているのは，SETFRAME_MOUSEWHEELの場合だけで，それ以外ではInvalidateControl(NULL, false)を実行しているだけだ．しかも，SETFRAME_MOUSEWHEELの場合はInvalidateControlを止めてもスクロール動作になっている．これは前段で実行しているCtrlFramePositionだけで処理をカバーしているということなのではないだろうか？後段を完全に削除しても動作しているので，これでしばらく運用してみることにする．こんな↓感じになった．
なかなかいい感じだ．
▲別のもう少し大きいファイルを開いたら，一部を残して画面が真っ黒になってしまった．カードの位置は正しいが，テキストは出ていない．
生描画に切り替えたら，PrintImpositionで「印刷用紙が小さ過ぎます」というエラーになった．PrintImpositionを止めたら，画面が真っ黒になる現象は止まったが，ある領域から下は描画されない状態になった．つまり，上記と同じ状態と見られる．いや，メモリ描画環境を使うように設定し直したら，やはり真っ黒になる．⇒COUPLING::SetTitleBoxで「タイトル枠描画パラメータを設定し系図外枠矩形領域を最終決定する」ということをやっているので，見てみよう．
論理座標系では系図枠は11458 x 782になっている．物理座標系では親ウィンドウサイズは999 x 697だ．これを論理座標系に換算すると，1146 x 1149になる．TREEVIEW::BuildBitMapでは，描画領域は論理単位では」11518 x 842でこれをLPtoDPで物理単位に換算して，511 x 6989になる．ビットマップはこのサイズに作られる．buildBitMapではLPtoDPの逆演算DPtoLPが実行されている．draw.Size()という計算で1531 x 6989という矩形のサイズ（横幅は現物に合わせている）が，2523 x 11521になっている．