ウィンドウズ 8 10 対応コードへの プログラムチップ

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

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

[ 2016 / 10 / 20 ] DPI の仮想化機能 について。
[ 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 が書いているのですから 当分 この機能は続いて 無くなる事もないだろうと思います。

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

[ 2014 / 01 / 02 ] DPI の仮想化機能 について。
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 の仮想化機能の調整値で動いて どれが 実際のピクセル位置で働くか良く確認して 意識して使用する 必要が 出てきた様です。

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

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

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

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

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

[ 2013 / 01 / 15 ] メニューの淡色表示について。( 2013/06/26 追記 )
プログラムをしている方はご存じでしょうがメニューを作成する時には当然ですがメニュー属性を指定してメニューを 作ります。この内の 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 を使用する場合は表示方法が変わったので要注意です。

-チップスに戻る- -トップページに戻る-