いま、久方ぶりに（暑い夏に合う）ウォッカトニック（Vodka tonic－英語だとヴォッドカトニック、と聞こえますが）で祝杯を挙げながら書いています。（おつまみは、．．．ワインや洋酒に合うのでとても気に入っている．．．昨日から二連荘のカプレーゼサラダ、玉ねぎの荒みじん切りを載せるのが私流か？．．．そうでもないみたいだな？）不具合のままアップしましたが、その「リソースが表示されない」不具合が本日解決しました。（グビッ）
結論から言うと、今回の不具合の原因は、ECCSkeltonというよりも（発生場所はそうなんですが）私の思い込み（半分は正しいのですが、その中途半端性で発見が遅れました）によりました。
The story is just like this.
分からないので途方に暮れ、半ばやけ気味にアップしてから、次に向かうべく"FileList"の移植を始めました。
このプログラムはCDLGにツールバー、リストビュー、ステータスバーを張り付けただけの簡単なものでスイスイと移植して、コンパイルすると、
あれっ、またリソースが表示されない？
その時、また直観が降りてきて「これってやっぱりhInstanceじゃね？」ということで、ｗWinMainやDllMainのインスタンスとメインウィンドウ（ダイアログ→不具合が発生していたのは、メインウィンドウをダイアログにしていたプログラムだけ）のインスタンスを比較してみました。
あれっ、なんでm_hInstanceが0？（注）
注：因みにこの時のプログラムインスタンス（エントリーポイント関数のHINSTANCE引数）は4******という値でした。
そうなんです。不具合の発生した TextToSpeechと、このFileListは共にCSDIベースではなく、CDLGでメインウィンドウにしているのですよね。それでECCSkeltonにおけるhInstance（注）の与え方をBCCSkeltonと比較すると、矢張り両者間で相違があり、ECCSkeltonではタイプ量、引数量を最小限にしたいために、プログラムインスタンス（注）を親ウィンドウ（hParent）から採っていたことが分かりました。
それはそれで（プログラムインスタンス == ウインドウプログラムの親ウィンドウのインスタンスである限り）正しいのですが、ダイアログベースのプログラムだと親が「デスクトップ（hParentが0で、hInstanceも0）」の場合、実際に作られたプログラムアプリケーション（それはそれ自体のhInstanceを持っている）の中のリソースが見えなくなってしまう、という結果になります。
注：ウィンドウズで実行されるプログラムはその管理の為に、固有のIDをHINSTANCEで与えられます。それは実行プログラムのエントリーポイントにあるhInstanceで実行プログラムに教えられます。実行プログラム（*.exe）に埋め込まれたリソースはそのID（hInsutance）をベースに参照されます。
「何故FileHandlerやWCEditorでは不具合が発生しないのか？」の答えも、CSDIがプログラムインスタンスを与えられ（m_hInstanceに保存）、それを子ウィンドウのダイアログに与える（元々のECCSkelton設計上の仕様）のでリソースを参照できることで説明されます。
従って、今回の不具合の原因は、
「ECCSkeltonの設計上、引数を減らすために、CDLGのm_hInstanceを引数で受け取らずに、親ウィンドウ（m_hParent）のインスタンスを取得してm_hInstanceに代入していた。これはプログラムがウィンドウベースで『親ウィンドウのインスタンス == プログラムインスタンス』の場合、正しく作動するが、親がOS（デスクトップ）の『ダイアログベースのプログラム』の場合、プログラム固有のインスタンスが渡されず、それに収録されたリソースを参照できない」
ということでした。（Does it make sense?)
本日修正版CDLGとそれに応じて修正したサンプルを入れてECCSkeltonパックを修正した、BCCFormandBCCSkeltonをアップしました。
FileListは問題であったステータスバーの「吹き出し」も正常に表示されるようになりました。
めでたし、めでたし。