CreateWindow()で貼り付けたボタン等は、ダイアログボックス等と同じ扱いになる。
ただし、Tabキー等で移動できることが絶対条件である。フォーカスのある場所しか読まないわけだからこれも当然である。通常のウインドウでこれを実現するには，
・IsDialogMessage()を呼び出す
・コントロールをサブクラス化する
の二つの方法がある。
IsDialogMessage()を使う方法では、ダイアログと全く同じ挙動を簡単に実現できる。
サブクラス化は、もっと自由度が高くなる。
エディットコントロール、リストボックス、コンボボックス、スクロールバー等、直前のラベル文字列も読む場合、その「直前」は、CreateWindow()を呼び出した順番である。
また、IsDialogMessage()を使う場合、Tabキーで移動する順番も、CreateWindow()の順番になる。
WAVRECの場合、GDI関数による描画を読まないことはほとんど問題にならない。
経過時間を読ませてもアレだし、ファイル名はオープンの時に判っているはず。
（レベルオーバーの警告くらい出したほうがいいのかもしれないが…）
デター！スクロールバーの山。
当初「バランス」という文字列もGDI関数で描いていたため、複数あるスクロールバーの区別が全くつかなかった。（縦スクロールバーと横スクロールバーの区別もつかない）
とりあえず、CreateWindowの第二引数で個々のスクロールバーに別々の文字列を設定してみたが効果は無かった。SetWindowText()しても無駄だった。
また、旧バージョンであるPC-Talker 2.0では全てのスクロールバーを、無関係なグループボックスの文字列を使って「左右チャンネル処理のスクロールバー」と読んだ。CreateWindowの第三引数でウインドウスタイルにWS_GROUPを追加して別のグループであることを明示しても無駄だった。（新バージョンPC-Talker 3.0ではタイトルバーの文字列を使って「MioneMのドラッグバー 選択」と読む。）
この問題は、スクロールバーの直前にスタティックテキストを置くことで解決する。（あくまで「直前」なので、10個のスクロールバーには、同じ内容にもかかわらず10個の別々のスタティックテキストを置く必要がある。すげーリソースの無駄遣いな気がするが…。しかも、エディットコントロールの場合は１つのスタティックテキストで複数のコントロールのラベルを共用できるのに……）
このスタティックテキストは、WS_VISIBLEもしくはShowWindow(SW_SHOW)で見える状態にする必要があるが、実際に見える必要は無い。（他のコントロールの後ろに配置して隠しても良いということ。）
ただ、MioneMの場合、モード切り替えでグライコを使わない状態にできるので、その時「ウィンドウ全文読み」で読まないようにするには、ShowWindow(SW_HIDE)で隠す必要がある。
さて、上記の対策で、「バランスのドラッグバー」「グライコのドラッグバー」などと読ませることはできるが、まだ、つまみの位置は読まない。「+12デシベル」などの値をどうにかして読ませないと実用にならない。
そこでこの機能を利用することにした。
ただし、つまみを動かすたびに転送したのでは、自動読みの場合にかえってわずらわしい気がした（特にPC-Talker2.0ではつまみを動かすと「スクロールバー ドラッグ」と読むのでこれと重なることが考えられる）ので、特定のキーを押した時に現在フォーカスのあるコントロールの値だけをクリップボードに転送するようにした。（この実現にはコントロールのサブクラス化が必要である。）