前回は自分で書いたCTABクラスのリビューを行いました。（大分脳みそが劣化しており、時間がかかります。）
そして次は肝心のリッチエディットコントロールのCREDITクラス、と思いましたが、ANSIベースでRTEditorを書いてから20年、リッチエディットコントロールも更新されているだろうとMicrosoft Docを見たら、先ず現在最新のリッチエディットコントロールはウィンドウクラス名も変わっており、機能も段違いです。(注）
注：従来のリッチエディットコントロールはVer 1.0が "Riched32.dll" で、Ver2.0と3.0は ”Riched20.dll”（ウィンドウクラス名もユニコードが入ってきたのでANSIの "RichEdit20A" とユニコード（UTF-16）の "RichEdit20W" があります。が、これらは#define UNICODE条件で変わる "RICHEDIT_CLASS" を使変えますが、最新のVer4.1はDLL名も ”Msftedit.dll"、ウィンドウクラス名も "MSFTEDIT_CLASS" と完全に変わりました。
まぁ、Ver4.1はもう私の能力を超えているし、BCCSkeltonとの互換も考えれば、Ver2.0、３.0を対象にして移植するしかないかな、と考えています。更にリッチエディットコントロールは文字列を扱うのでウィンドウズのUTF-16化の影響をもろに受けており、他の関数のように簡単に対応できそうに思えません。
ということで、ECCSkelton仕様として、
（１）Ver2.0、３.0を対象として、"RichEdit20W"を使用
（２）「文字列処理はUTF-16一本」の方針ですが、ファイルの読み書きはANSIにも対応したい（注）
と考えてます。
注：リッチエディットコントロールの表示等は従来の対応で大丈夫ですが、ファイルの読み書きはEM_STREAMIN、EM_STREAMOUTの際のSF_RTFとSF_TEXTの二択から、ORでSF_UNICODEが使えるようになったそうで、両者のフラグに加えて出力ファイルとBOM等をチェックする実験が不可欠と考えています。更に（可能であれば）UTF-8にも対応したいのですが、現在はそのヒントすらわかりません。
まぁ、先は長そうですので、先ずはANSIのrtfファイルを使って動作を確実にし、その後UTF-16のファイルで対応、更にその先を目指すかどうかはその時に考えましょう。
Let it be!
ps. 先般アマゾンプライムでドキュメンタリーの"Eight days a week"を見ましたが、米国が1960年代中盤までアパルトヘイトであったとか、米国公演で白人黒人の入場区別を理由に公演拒否して（当時の公民権運動を背景に）社会問題になったり、（私には）懐かしい画像が多く流れました。特にJFK暗殺、東西冷戦（007のスパイシリーズは当時の現実）など「小学生なのにショーンコネリーが好きで、ビートルズを口ずさんでいた」私がいとおしかったです。