Windows 8 が環境を整えてみると 此までの Windows 7 までとは違って動作検証だけして OK とは行かない問題が 有る様で ウィンドウでの内部動作が 変わって此に対応しないと不自然になる部分が有るのに気がつきました。
そんな気がついた内部動作を此の プログラムチップ に書いて多少とも プログラム上の参考になればと思います。
[ 2015/08/01 ]
Microsoft の Windows 10 の が正式になったので デスクトップの Windows 7 環境を 正式に 引き継いで入れる事も出来たので それで 検証しながら 此の ページで Windows 10 の事も書いていきたいと思います。

何処に 書こうかと思いましたが どこかには書いておきたいと言う事で まあ 此処でいいかと思い 書き留めました。
もう そろそろ Windows 10 Spring Update も一段落して そこそこ使用し始めている事と思います。こちらでも デスクトップと ノート に入れて使用し始めました。見た感じは同じでそれ程変わっているとも思わなかったのですが 使用しているうちに 常用している NAS 上に置いている メールソフト FTP アップデートソフト等が 外に向かって通信が出来なくなってしまいました。 Ver 1709 に戻せば 使用できますから 何らかの 変更が 1803 で有った模様です。( ログを見ると 通信用の Socket 作成が 失敗している様です。) 巷でも 話題のネットワーク共用周りの 何らかの 変更が 影響しているのかも知れません。ただ  他の NAS からでは 同じソフトでも 今までと同様に動作するので 話は かえって 複雑です。
通常 使用する物は 全て 此の 動作しなくなった NAS からに統一して 立ち上げて作業をしていたので バックアップ 統一動作を 考えると 非常に不便になり 対策を考慮中です。( NAS メーカーにも メールを出しました。)
後 エクスプローラーからの フォルダー ファイル の右コンテキストメニュー選択後の マウスボタン経歴が変わり マウスの 右クリック左クリックの 痕跡が全く無くなってしまいました。したがって此の痕跡で 動作させていた ClipName Rbutton は 通常の物と何ら変わりなく動作になってしまい マウスの 右ボタンで Name Only を多用していたので結構不便になってしまい ました。此は もう少し様子見かな と思っています。
ウィンドウも大きく バージョンアップすると色々な事が 出てきますし DOCM も CLSID も APPID も 無い イベントエラーが 出たりして もう何日か前から Web でも話題になっています。又 何ヶ月かかけて安定さしての  繰り返しになるのでしょうか。
[ 2018 / 06 / 20 ] フォルダー ファイル の右コンテキストメニュー選択後の マウスボタン経歴は 06/13 の アップデートで 元に戻って マウスの 右クリック左クリックの 痕跡は以前よりはっきり残る様になった様です。

Windows 10 になってから Windows 8 から続いている ファイルのコピー等の 確認ダイアログ "OperationStatusWindow" と Windows VISTA から始まった ユーザーアカウント制御 の確認ダイアログ の動きが多少変わってきた様です。
これらの 確認ダイアログ とプログラミング上で多少関わる時の注意事項を解った範囲で書いておこうかと思います。 確認ダイアログ と 言っても 此までのダイアログとは全く違う物です。Windows 7 までは まさしくダイアログで クラス名 "#32770" の 此まで通りのダイアログで扱いも 此に準じる物でプログラムも 対応すれば良かったのですが Windows 10 に なってから ファイルのコピー等のダイアログは "OperationStatusWindow" クラスになり ユーザーアカウント制御 の 確認ダイアログ は Credential Dialog Xaml Host クラスになり動きも作成状況も以前とはずいぶん変わってきて 此に プログラム的に対応するのは以前と同じようには行かなくなりました。
まず クラス名 "OperationStatusWindow" の ファイルのコピー確認 進捗状況表示 ウィンドウ ですが 此は最初に此が 必要な状況でウィンドウが作成される様です。( 表示されるかは状況によって変わる事になります。)そして一度作成された ウィンドウは使い回しされて 削除はされず その時々によって Visible ←→ Invisible が切り替えられて 表示 非表示 が切り替えられ 複数状況のある時には 2段 3段 になって表示されます。一度作成された後は 表示されない必要の無い時でも インビジブルで システムに常駐している事になります。したがって 此の ウィンドウの表示 の立ち上がりは プログラムの  HookProcedure には Activate で捉えられますが 非表示は Delete が無いので捉えられません。 Activate で捉えられる とは 言っても Create ではないので 非表示から 最初に表示されるのを捉えるのは 工夫が 必要かもしれません。
次に ユーザーアカウント制御 の確認ダイアログ "Credential Dialog Xaml Host" クラス ですが 此のウィンドウは確かに デスクトップ上にあって フォアグラウンドウィンドウ ( アクティブウィンドウ ) では有るのですが 此までのデスクトップ用 HookProcedure には Create Activate Delete も全くかかりません。したがって表示されているかいないかは定期的なタイマー に よる所となります。したがって 此によって立ち上げられたウィンドウを把握するのは プログラム的には 定期的なタイマーに よるのかな と考えています。( 今の所 此をしなくてはいけない プログラムは 此処にはありません。)
又 此の ユーザーアカウント制御 の確認ダイアログ はシステムの低い所で出すせいでしょうか 此が フォアグラウンド ウィンドウの時には マウスなどの RawInput 機能が全く効かなくなります。( Input Signal が搬出されません。) したがって OnScroll や BwFwButn 等は 動かなくなってしまいます。当然の事ですが ユーザーアカウント制御 は OS 事項ですから  これらの事を解析する ツールも それなりの ユーザーアカウント制御 の許可を取った物でないと調べられません。
Windows も ずいぶん長い時間 標準ソフトプレーヤーを続けていますから 最初に想定した 基準 Windows 32 API だけではカバー しきれない所も出てきて 当たり前の話でしょうが Windows 10 になってから タブレットも デスクトップも 1つの ウィンドウで カバーしようとする剰りの ちぐはぐさも 出てきている様な気がします。

ここの所 Windows 10 も落ち着いてブルースクリーンが 出なくなったなあ と思っていたら 何となく代わりに エクスプローラー エラー イベント ID 1002 1000 等が起きて 一瞬画面が白くなり動作が止まり 又 リカバーする 事が散見される様に ( 日に何度も起こる様な頻度では無く 2週間に一度とか ) なりました。ひょっとしたら OS が ブルース クリーン で落ちるのを改善して内部で持ちこたえる コードを入れたのかもしれません。
とりあえずは ブルースクリーン で再起動されるよりは良いのですが 画面が白くなり動作が止まり リカバーした後は  場合によってはタスクトレイアイコンが再現出来ていなかったり どうもプログラムマネージャーも再起動しているらしく ウィンドウハンドルが変わっている事も有る様です。
此までは ブルースクリーン 再起動だったので 個々の プログラムは再度立ち上げになり タスクトレイアイコン 再確保 プログラムマネージャーハンドルは新たに取得 と言う事で問題は無かったのですが エクスプローラーは再度立ち上がっても タスクトレイアイコン は失われたままだと 此に頼ったプログラム( 他にフォームとか持たない物 ) は自分の設定も  終了も 出来なくなってしまいます。設定から タスクトレイアイコンを再描画しようとしても プログラム内部では有る つもりで タスクトレイアイコンを削除しても 無い物を削除するので エラーで削除出来ない 結局まだ表示中の判断になり いつまでたっても 表示は出来ません。プログラムマネージャーやタスクバーウィンドウ ( Shell_TrayWnd ) を確認して 動くプログラムも 以前のハンドルが無効になり 時によっては危ない不具合も出て来る可能性も出てしまいます。
あまり良くない事に Windows API メッセージには当然ながら システムの状態が変わりました とのメッセージは有りません したがって これから常駐して常に動作させるプログラムは 何らかの機会を捉えて システムの様子が変わったとか タスクトレイアイコンが有るかどうか(結構調べるのは難しいかも)を確認するとか 確認しないまでも 内部設定と タスクトレイアイコンの有無の同期判断方法を変えるとかしないと 常駐プログラムが取り残されるかもしれません。
何しろ システムが 一瞬画面が白くなり動作が止まり 又 リカバーする様な事は それ程 頻繁に起こる事ではないので はっきりした対策もないのですが 可能性は排除する方向で考えておいた方が事も良いかもしれません。

[ 2014 / 01 / 02 ]　DPI の仮想化機能 について の新たな展開の続きです。
Windows 8.1 で始まった DPI 仮想化機能はそのままの機能で Windows 10 に引き継がれて現在まで来ています。 ただ この頃になって見つけたのですが Windows 8.1 に変わった時に Microsoft から
DPI に関連する API およびレジストリ設定 2013年10月 と言う物が出ていまして レジストリの HKCU\Control Panel\Desktop の DWORD 値 Win8DpiScaling を 1 にセットすると Windows 8.0 以前の DPI スケーリングを 引き継ぐ事が出来る様です。此は Windows 8.1 についての文章ですが Windows 10 もこのレジストリーは引き継いでいて HKCU\Control Panel\Desktop に DWORD 値 Win8DpiScaling が 0 で存在します。 ただ Windows 10 についてはこの値を変えるボタンやスイッチは無さそうで レジストリー の値を直に変える以外には 他に方法は無い様です。この値を 1 にすると DPI スケーリングは 文章の通りに Windows 10 でも Windows 8.0 以前と 同様に 120dpi ( 125% ) までは 何もしない 捨て置きなります。ただデスクトップの設定表示は 何だか意味がわからない 文章になり DPI 選択スケールも 200% まで来てしまいます。 ( サポートもしないし 又 あまりして欲しくないのでしょうか。) 取りあえず Windows 10 でも 120dpi までは DPI スケーリングをする事を防げますから 文字だけは 大きくしたいと言う人には朗報だろうと思います。 それもたまたまそうなる訳ではなくきちんとした文章で Microsoft が書いているのですから 当分 この機能は続いて 無くなる事もないだろうと思います。

[ 2013 / 02 / 04 ] Windows 8 の メニュー高さを調べる GetMenuItemRect ついて。不整合が生じていると 書いたのですが Windows 8 では変わらず ( bottom - top ) が 1 dot多い様ですが 此が Windows 10 になってから ちょうど良くなりました。 どの プログラムも OK になっているので 見た目は 似ていますが内部的に変えられた様です。私としては このままの形で Windows 10 が出てくれるのを 望みます。Windous 8 環境では多少無駄が出ても我慢して使ってもらう事になりそうです。
どちらにしても 一年間は ただで アップデート可能との事ですから このまま見守りたいと思います。 ( 焦って Windows 8 対応をしなくて良くなりました。)

Windows Vista から始まった DPI の仮想化機能 は Windows Vista 7 までは特に プログラム上で意識する 事も無かったのですが 此は Windows Vista 7 では テキストサイズの拡大率が 150% 以上でないと働かなかった様で 此処まで 拡大 する事の機会が 無かったので 意識する と言うよりも 気が付かなかった様です。此がWindows 8.1 ( 8.0 かも ) から 画面の テキストのサイズを大きくすると ( 125% でも ) 此までと 違って DPI の仮想化機能 が働いてしまう様で 良く使用する API GetCursorPos で取得する値が 此の テキストサイズの拡大率によって 調整されて変わって来ているようです。
此を まともに影響を受けるのが MousePos で CRT が 1920 x 1200 でも カーソルポジションが 1535 x 959 ( 125% 時 )に なったりします。此は 此で DPIの仮想化機能 と捕らえればまあ良いのかも知れませんが 今までの XP Vista 7 から 同じ 画面サイズで カーソルの位置の値が変わるのも変ですし 本当に不具合が出るのは API によって DPIの仮想化機能の 調整値で動く API と 実際のピクセル位置で 受け付ける API が有る事です。
まさしく MousePos が此に当たって マウスカーソル付近の 拡大窓が マウスカーソルとずれてしまいます。どの API が DPI の仮想化機能の調整値で動いて どれが 実際のピクセル位置で働くか良く確認して 意識して使用する 必要が 出てきた様です。

Windous 8.1 に変わった後に 以前からの ヘルプファイル形式の HLP をサポートする様になる更新プログラム Windows8.1-KB917607-x86.msu がアップされました。此処にある何個かのプログラムは まだ ヘルプファイルが HLP 型式の物が有りますから 此の更新プログラムを インストールして 読んで下さい。

ウィンドウズ 8 も 約一年して Windous 8.1 に変わりました。SP1 扱いかなとも思いますがそれにしてはダウンロード サイズが大きい様な気がします。とりあえず 環境を 8.1 に変えてみる事にしました。自動更新で 2時間ぐらい かかりましたが 特に問題もなく終わり プログラムも確認しましたが 変わった所は有りませんでした。
これからの 此処 ソフトの小物たちの Windous 8 の検証は 8.1 で行う事にします。( と 言うか Windous 8 の環境は 一台しか有りません。)

プログラムの中には非常に多いアイテムをメニューで出す事が有ります。此処で言うなら SbFolder や ClipSaver の リストや CLS リストのメニューなどです。SbFolder は ファイルの数だけのメニューアイテムを並べる訳ですから ひどい時には 2000 個以上になってしまいます。そんな時には 見通しのいい様に上下に ▲▼ の付いたメニューでは なくカラムを変えて表示する様に ( Menu Break ) していますが カラムを変えるには 画面に幾つメニューアイテムが 入るかを正確に調べなければなりません。
メニューの高さは 人それぞれの設定によって ( フォントや 上下の余裕 ) によって違いますから プログラムから １回で 正確な値を出すのは殆ど不可能です。( 大体は ± 1 ドット程度の誤差なら当たります。) したがって 此処にあるプログラムは此のメニュー高さの正確な値が欲しい時には 大体の値で計算して メニューを出して メニューが出た後で API GetMenuItemRect で各メニューの Rectangle ( 矩形 ) のサイズを実際に取得して 高さを調べてそれを元にメニューが画面の高さにちょうど収まる様に 高方向の数を計算しています。 実際に出ているメニューのサイズから計算するのですから間違いは有りませんでした。
此が Windows 8 になってから 通用しなくなってしまいました。色々確認した所 GetMenuItemRect の返す値の ( bottom - top ) が 1 dot多いとの結果になりました。したがって今までのプログラムでちょうど良かったはずの メニュー高さが 足りなくて隙間が出来る様になりました。
Windows 8 用に調整を入れるのは簡単ですが Windows 8 のディスクトップディメンジョン等のカスタマイズ方法も まだ はっきりしないので それが解ってから確かめながら変更していった方が良さそうです。

テクニカル インフォメーションにも書いている様に プログラム的に USB メモリー等のドライブを取り外しをしても Windows 8 では 何もメッセージが出なくなっている様です。
この為 一応 切断確認を確かめる為にはプログラムで何らかのメッセージを出した方が良いのではないかと思います。

Windows 7 8 とバージョンアップしてくるにしたがってエクスプローラーのフォルダー表示の仕方や構造はその都度 変わってきているのですが デスクトップの構造 此はとりもなおさず プログラムマネージャー ( クラス Progman ) の構造は以前から ( Win 95 ぐらいからか ) 変わっていません。比較的シンプルな構造をしています。したがって デスクトップ上の アイコンやらそのテキスト等は 以前からの GetWinTt 等で変わらずに取得出来ます。
此処までは 此まで通りのデスクトップなのですが Windows 8 になってから不思議なウィンドウがデスクトップに 配置される様になりました。EdgeUiInputWndClass のクラス名を持つウィンドウで 大きさもあり Visible Flag も 立っていて スクリーンの中に有るのに見えません。又 ウィンドウ拡張スタイルも定義されていないビットが立って いたりします。とにかく ツール類で認識も出来るしマウス下に有ると言う指示もするのですが 見えないしアクティブ にする事も出来ません。したがって 目に見える デスクトップ上の常駐プログラムの列挙をする時にはこの EdgeUiInputWndClass は除いておかないと具合の悪い事になります。まあ 以前から有る Shell_TrayWnd クラス ( タスクバー ) の様な物だと思えばよいのかも知れません。この辺の事は既に MSDN に 書かれている様です。

プログラムをしている方はご存じでしょうがメニューを作成する時には当然ですがメニュー属性を指定してメニューを 作ります。この内の fState に当たる MF_DISABLED / MF_ENABLED / MF_GRAYED の色の扱いが Windows 8 になって 変わったようです。
此までは MF_DISABLED / MF_ENABLED は通常のメニューテキスト色で ( Normal なら黒 ) MF_ENABLED なら有効 MF_DISABLED なら色は通常と同じで メニューとしては無効 ( 選択出来ない ) MF_GRAYED なら色は淡色表示で メニューとしては無効 ( 選択出来ない ) と言う事になっていました。
此が Windows 8 では MF_DISABLED と MF_GRAYED が同一表示になり どちらも 色は淡色表示で メニューとしては 無効 ( 選択出来ない ) と言う表示法になったもようです。但し 同じ淡色表示でも内部的な Status は MF_DISABLED MF_GRAYED と区別されている様です。
通常のメニューを作成しているには MF_DISABLED と MF_GRAYED の違いはあまり意識する事は有りませんが 意識的に MF_DISABLED を使用する場合は表示方法が変わったので要注意です。