自然数を四進数表示すると，フルヌードのビーナス像が現れる．ウソだと思ったら自分の目で確かめてみるとよい．ネット上にはN進数表示のためのツールがごろごろしているから，コラッツ木上の隣り合った数字をいくつか比較してみればホントだってことが分かるだろう．君の目の前にあるのは「整った美の完成型」だ．乱雑でカオス的なコラッツ数列の渦の中にこんな「秘密」が隠されていたなんて信じられるだろうか？
これを見たら夜も寝られなくなる人が続出するかもしれない．実際，昨日からこのブログへのアクセスが急増して一日の訪問者数が100を突破している．ともかく，コラッツ完全木ツールをリリースするまでは全力疾走するしかないね．「コラッツの秘密」が開示される日は近い．
もう少し突っ込んで解析したいのだが，そのためにはゼルコバの木で横書き系図を表示できるようにしたい．それができれば一々PDFに落として，云々の手間が省けるのだが…原理的にはそれほど難しくはないが，かなりの手間が掛かりそうだ．コラッツ三本桜の復活とどちらを先に手掛けたらよいか？コラッツ三本桜の復活は「コラッツ完全木」の完成を意味するが，一度仕事に掛かったらA面・B面の5機能すべてに対応しなくてはならないから，かなりの時間を要することになる．むしろ，思い切ってここでゼルコバの木に横書き系図を導入してしまった方が早いのではないか？ゼルコバの木の座標系は現在，X軸は右から左，Y軸は上から下というオリエンテーションになっているが，横書き対応というのは，X軸とY軸を入れ替えることに相当する．X→Y’，Y→X’とすると，X’は左から右，Y’は上から下に描画されなくてはならない．かなり厄介そうな話だが，やってみよう．
内部の計算は完全に温存されるものとし，座標変換は描画関数で直接実行する．ゼルコバの木系図図面に出力される図形には，①人名枠，②人名枠内のテキスト，③親子連結線，④兄弟連結線，⑤人名枠頭部垂線などがある．描画関数はDrawTreeView.cppとDrawTree.cppに入っているとみてよいだろう．可能ならば，最下位の関数で対応するというのがベストなのだが…切り分けができるだろうか？最下位の関数ということは，WindowsのAPIを直接呼び出している関数ということになる．DrawingObject.cppという未使用のCPPファイルがある．内容は「描画要素オブジェクトクラス」となっているが，これは将来，描画要素をオブジェクトとして扱えるようになったときのためにリザーブしておいたものだ．今回の修正は趣旨はまったく異なるが，とりあえず，ここに修正を要する関数を集めてみることにしよう．まず，使われているWindows APIを特定してみよう．デバイスコンテキストクラスの関数がそれに該当する．ざっと拾い出したところ42個あった．
- Arc
- BitBlt
- DPtoLP
- Ellipse
- EndDoc
- EndPage
- ExtTextOut
- FillRect ●
- FillSolidRect ●
- GetClipBox
- GetDeviceCaps
- GetMapMode
- GetSafeHdc
- GetTextColor
- GetTextFace
- GetTextMetrics
- GetTextExtent
- GetOutputTextExtent
- LineTo ●
- LPtoDP
- MoveTo ●
- PatBlt
- Polygon
- RestoreDC
- SaveDC
- SelectClipRgn
- SelectObject
- SetBkColor
- SetBkMode
- SetMapMode
- SetPixel
- SetROP2
- SetTextAlign
- SetTextColor
- SetStretchBltMode
- SetViewportExt
- SetWindowExt
- SetWindowOrg
- StartDoc
- StartPage
- StretchBlt
- TextOut
ただし，これらの関数でも座標に関わりがないものは対応不要と考えられるので，実際の数はかなり限られていると思う．まず，ともかく矩形と直線の描画に関わるものを対象として修正を試みる．対応が必要な関数は上記リストで●をマークしたFillRect，FillSolidRect，LineTo，MoveToの4関数だけだ．これらはCDCクラスの関数だが，CDCクラスをオーバーライドすることは可能だろうか？⇒できそうだ．_CDCという拡張クラスを新設し，以下の関数をDrawingObject.cppに移動した．
- Bobject::DrawYlist
- Bobject::DrawParentPath
- TRIBEBOX::DrawTlist
- Bobject::DrawLine
- BRect::DrawFrameRect
- printtombo
- printtombo_yoko
- printtombo_tate
- Bobject::CallFillRect
- TREEVIEW::PaintBackGround
- Bobject::FillSolidRect
一応修正は入ったので，走らせてみたが… どうも，これはかなり手強い．画面はほとんど真っ黒で一部描画されている部分もまったく座標変換になっていない…新規ファイルにすると，こんな感じだ．
ちょっと頭を冷やして考えなくてはならない… 現行ではデバイスのマッピングモードをMM_ANISOTROPICに設定している．これは座標単位と座標軸の向きを任意に設定できるという便利なものだが，X・Y軸を入れ替えるとしたら，少なくともSetWindowExtExとSetViewportExtExで軸の向きを変更しなくてはならない．ゼルコバの木は画面出力とプリント出力をまったく同じ関数で実行しているので，印刷の方も手当しなくてはならないが，ここのところは暫定的にパスしておくことにしよう．⇒少し状況が変わった．画面にはまだブラックなところが残っているが，人名枠が横書きで表示されている！これはいい傾向だ．
おそらく，スケールと軸の向きはこれで正しくなったと思われるが，座標原点の位置が悪いのではないだろうか？SetWindowOrgを呼び出している箇所には修正を入れてみたが，まったく変わらない．なんとか横書きしようとしているのは確かだが…
座標がからんでいる関数は上記のリストの中にまだどっさり残っているが，DPtoLP, LPtoDPが動作しないとまずいのではないだろうか？現行では論理座標と物理座標は等スケールになっているはずだが，GetClientRectなどで取得した矩形領域は論理座標系とは反転したものになっているはずだ．CWndの関数もチェックしておく必要がある．座標に関わりがあるのは多分GetClientRectだけだと思う．mmm… だいぶよくなった！
▲上下カーソルでカードが移動してしまう．おそらくこれは一覧画面での動作だが，カード画面にフォーカスがあるときは無用な動きだ．
枠線や系線がまったく出ないのはなぜだろう？