悪意を持った物や そういうソフトや 偶然運悪く デスクトップが全て覆われて タスクバーが出現しなくなってしまった時の 為に BwFwButn の 内部コマンド /A で出る タスクメニューに そういう状態の時には タスクメニューの最後のタスクに  Shell_TrayWnd ( タスクバー ) の アイテムを付加する様にしました。此を選ぶ事で タスクバーが現れて タスクバーのメニュー なり スタート メニュー なりから 何らかの処理を始められる様になります。
本当は 緊急の時には Windows キー + ? で タスクマネージャーが直に強制的に現れて欲しいのですがそうはなっていないので 自衛の意味を持って この機能を付けたのですが デスクトップが全て覆われて不便になった時には意外と使えます。

此処の所 Windows Defender も落ち着いているようです。特に言う事は有りません。
03/20 に緊急的に アップした CabwcPos の安定版を 本日アップしました。CabwcPos は スタートアップから終了まで 常駐させて常に使用しているので 何かおかしな事が有ると直ぐに解るので 今回の物は対策をした所が当たりで 無理もなくなり安定しているのでは無いかと思っています。

信じられない事に 01/18 の Windows Defender 1.403.2293.0 定義更新から 突然 BwFwButn が Trojan:Win32/Bearfoos.B!ml 判定 されて 削除される様になりました。非常に不便なので BwFwButn を 除外ファイルに入れて使用し出しましたが あまりにもおかしい ので もう一度 Vis Studio で Rebuild しました。( ソースは全く変えていません。) 此は Defender に掛かりません。 ソースは同じでも Rebuild すると 実行ファイル( BwFwButn.exe )は 微妙に違うようで 全く同じでではないので 掛からないようです。
多分 Defender の次の 定義更新では直るのでしょうが それまですっきりしないので 01/18 に Rebuild した BwFwButn.exe を 同梱した BwFwButn.zip に差し替えました。Defender で四の五の言われた時には 本日挙げた BwFwButn.exe を使用して見て 下さい。全体を見渡しても BwFwButn のコードには怪しい所は1つも有りません。何が引っかかったのかは解りませんが  Windows Defender にも思い違いから来る 所謂 バグが有ると言う事でしょうか。
[ 02 月 20 日 の追記 ] 02/18 の Defender KB2267602 1.405.187.0 は もっとひどく 結構ひどい目に遭った方も居たのでは ないかと思います。私の所は Trojan:Win32/Wacatac.B!ml のオンパレードで ソフトの小物たちの プログラムだけで無く他の プログラムもやられました。多少の事では押さえられなくて Defender のリアルタイム保護を OFF にして使用しているうちに  Ver 1.405.201.0 で 全ては 終わりましたが 結構な大暴れでした。此の為 Web 上で ビールス チェックが出来る Dr.Web を 見つけて 個々に チェックをしてみましたが あたりまえですが 特に問題はありませんでした。
本当に迷惑な Defender Ver 1.405.187.0 でした。( もう少し確認して出して欲しかったかと思います。)

Windows 11 の下に有るタスクバーの高さも 23H2 から Reg の TaskbarSi でも小さくならないし ViVeTool での  タブエクスプローラー を無くすのも エクスプローラー が立ち上がらなくなってしまったので 諦めて 通常通りの  Windows 11 で使用していたのですが タスクバーの高さ は我慢できずに ネットで新たな情報は無いかな と検索してみると 以前 Windows 10 のリボンにする為に インストールしてみて あまり安定性は無かったのでやめてしまった ExplorerPatcher が 小さな ICON で タスクバーの高さが小さく出来る 様だと解って最新版を使用して見ました。
まさしく ピンポン で タスクバーの高さは小さくなるし Windows 10 のリボン にも安定して出来るし 又 諦めていた  タブエクスプローラー もやめる事も出来ました。改良版は 最新の 23H2 Windows 11 でも安定して使用できる様です。
又 便利な事に Windows 11 ←→ Windows 10 の切り替えは System の 再起動ではなく エクスプローラー の再起動で済むので ( エクスプローラー の再起動は ExplorerPatcher の中に有ります。) 気軽に設定を変えられます。
此までは プログラムの 動作確認は Windows 11 ←→ Windows 10 の確認は 別の PC でしていましたが 此なら同じ PC で 切り替えて出来そうな気もしています。( まあ 今の所は してはいませんが。)
このまま 使用して安定して使える様なら Windows 11 は Windows 10 擬きで行こうかなと思っています。此だけ 安定して 切り 換えが 出来るのは エクスプローラーもそれなりに準備されている事を考えると Ms が 純正品で ( オプション指定 ) 出来る様に しても 良いのではないかと 思ったりします。

今までの BwFwButn は メニューの説明と タスクメニュー クリップボードの実行 のチップ等は適宜出していたのですが  本日アップした BwFwButn から コマンドメニューに 表示するタイトルを チップとして表示し何をしているのかはっきり させるようにしました。特に ウィンドウが表示されない物を コマンドとして指定している物は非常に確認がしやすく なりました。( もちろん 表示無しの方法も用意しています。)
内部コマンドにしろ 外部コマンドにしろ コマンドメニュー を出して選択する時には タイトルをクリックするので比較的 はっきりしているのですが Bw Fw Middle ボタンの One Click にアサインした物で 動作が 表示を伴わないコマンドに ついては 今 何をしているのか判って使いやすくなりました。
BwFwButn は マウスの Side Button だけでなく Middle Button ( Wheel Button ) でも作動しますので 通常の スクロールホイール付きマウスでも全機能を活用できるかと思います。( ただし マウスボタンの 押し離しを直に 感知しているので タッチパッドについては無力です。)

Windows の設定ウィンドウが UWP アプリタイプが増えてきて随分久しくなって期間がたちました。設定ウィンドウは 大きくて解りやすいのですが そこにたどり着くまでが大変でなかなか目的の設定ウィンドウにたどり着けません。
そんな 時に URIスキーム を使用して 此の目的の設定アプリ(ウィンドウ)にコマンドラインですぐに表示するする事が 出来る様です。 詳しくは Windows 設定アプリの起動 に 書いて有る通り ですが 此が BwFwButn でも ms-settings:bluetooth 等の コマンドラインで 使用できます。BwFwButn は コマンドメニューが 10+26(A-Z) x 2 で 72個まで 持てますから 私は

Bluetooth デバイス
ms-settings:bluetooth

と 言う様な 形で 此が 丁度 コマンドメニューの B.Bluetooth デバイス となる様な所に来る順序で( B キーを押せば即選択できる ) 何個かの 設定 アイテム を直に呼び出す為に入れています。この様な事を BwFwButn の  おもしろコマンド に追加しています。

10月の定期アップデートが来て Windows 11 のファイルエクスプローラーの様子は 9月末のアップデートと内容的には 変わらずこのまま行きそうです。したがって 本日の OnScroll と CabULCmu 09/25 の BwFwButn はアップデートした物で   ULCメニューは当分そのまま使用できそうです。
ただ 9月末のアップデートでも感じた事ですが フォルダー内容を表示するのに何でこんなに遅いのか理解に苦しみます。 ( 遅いままです。内部で何かしているのでしょうか ) 何個かのソフトはタイミングを取り直す必要が有りそうです。 ( もうした物を使い出しています。)
又 もっと基本的なウィンドウの表示の仕方ですが なぜか画面いっぱいで表示する Window Style WS_POPUP の外枠に 白い線の ボーダーが付く様になってしまいました。此は全画面表示する プログラムは 影響を受けそうです。今までの ウィンドウ スタイル表示を平気で変える様な事をするかな と言う感じがします。此の事は 此処のソフトの小物たち の プログラムだけで無く 他の動画ソフトで全画面表示するソフトも外枠に白い線が入る様になりました。( 此は結構 見た目が違和感が出る様になっています。) 何考えているんだよ Ms と言う感じで OS ( Windows ) はバージョン アップしてもソフトの表示は同じ様にするのが本筋ではなかったのでは ないでしょうか。
此処 ソフトの小物たち のプログラムは まだ私が手間を見ているので OS の変化には耐えられますが 前から有る もう バージョンアップが見込めないソフトはどんどん表示が取り残されてしまいそうです。
出来る事は 変化に応じて 内部を変えて対応して行くしか無いようです。Ms に希望するのは 内部は変わっているのでしょうが  見た目を変えるだけの無駄で意味の無い バージョンアップはやめていただきたいものです。Windows 11 にはせめて ファイルエクスプローラーのタブ表示をしないオプションを付ける事ぐらいはしても良いのではないかと思います。 ( Vive ツールで タブ表示をしない設定をすると エクスプローラーがクラッシュする様になりました。)
結局 一番安定していて使いやすいソフトウェアープレーヤーは Windows 10 と言う事でしょうか。

Windows 11 の ファイルエクスプローラーの様子が変わりそうです。( 実際 KB5030310 09/24 Update では変わっています。) この先 どんどん変わりそうです。考えて見れば 去年の今頃の Update で タブエクスプローラーになりましたが 何となく 不完全燃焼と言う所でやっと形だけの タブエクスプローラーに 梃入れが始まるのではないかと思っています。
どうせやるなら さすがタブエクスプローラーの方が良いね。と殆どの人が思えるような改訂をしていただきたいと思います。 ( 私は 殆どメリットを感じなかったので ViVeTool と言う物で タブエクスプローラーを Disable にしていましたが 今回の Update で此もだめになった様です。)
此から 23H2 にかけて ファイルエクスプローラーは大きく変わっていくようです。( どうか 頭でっかちでなくコンパクトな 物を望みます。) 当分変化に注視して対応にいく必要が有るのではないかと思っています。
本日の BwFwButn は ギリギリの所で ULC メニュー が対応に間に合いましたが 次は解りません。

ここの所 Web ページを見ていると 古くから有る物を除いて 殆どのページは UTF-8 で書かれている様で UTF-8 が スタンダードに なっている様です。文字種の自由度を考えると やはり ユニコード系かなと思います。
文字コードは何で書かれていても ブラウザーで表示されているのを読んだりするのは何の問題も無いのですが 文字をコピーして 此を ファイル名に使用するのも Wondows は ユニコード対応していますから 此の名前のファイル名も作成出来ます。 ただ ソフト(プログラム)によっては 内部的なコードは ANSI ( Shift JIS )文字で対応していると ANSI 文字に無い UNICIDE 文字 での ファイル名が付けられたファイルは無い事(読めない)になってしまいます。
したがって 現存するファイルを対象とするソフトは内部的な文字動作は ユニコードでする法がトラブルも減らせるのではないかと 思います。
此の事は もう何年も前に テクニカル インフォメーション に書いた事ですが そろそろ徐々にですが対応していかなければならないと考えています。

デスクトップに現れるウィンドウで 最小化 最大化 閉じる ボタン は右の方に有るのに タイトルバー付近の 右クリックで システムメニューが現れない物が何個か有る様です。もちろんこういう物は ウィンドウ作法のタイトルバー ではないので 右クリックで違うメニューが出たりもするのですが 何も出ないなら システムメニューが 出た方が右上が 隠れている時には便利だろうという事で BwFwButn のオプションに Sys. メニュー を加えました。
デスクトップを使う人の ウィンドウ 配置によるとは思いますが 私の場合 デスクトップの 右上部分には 色々 見るために  トップモーストウィンドウを配置している関係で 大きく展開しているメインウィンドウの Close ボタン ( Xボタン ) が隠れている事が 多く この様な時には タイトルバーの 右クリックからシステムメニューを出して 閉じる を選ぶ事になり いつも此のメニューが出る事が 結構必要事項になったりします。
[ サイト ステータスの確認 ] 06/23 に現在の URL に引っ越していつ来るかと思っていた Google の巡回ロボットが 08/06 にやって 来まして 白判定 ( 安全ではないコンテンツは見つかりませんでした ) をしていきました。新しい URL は回って来るのが遅くなるのか  全体的に Web サイトが増えているのか 一月以上かかるのはずいぶん期間が長くなって来ているのかも知れません。

いつからは はっきりしないのですが 多分この一月以内ぐらいで MS が IME の不具合は解消したと 言った辺りから 新しい IME の挙動が変わり 今までの IME Control API が効かなくなったようです。
したがって ここに有る HideLBar や CabwcPos の IME Bar を隠す 機能は効かなくなりました。此等を有効にするには 日本語 IME 設定 全般の 以前のバージョンの Microsoft IME を使う を オン にして下さい。 ( MS IME でない ATOK 等を 使用する時には関係しません。)
何か 新しい事が出る度に 昔ながらの Windows API が変わっていくのは仕方がないのでしょうか。

06/23 までに 新しい 此の URL のページを整えて 古い URL に引っ越しの インフォを 挙げて 引っ越しが終わりました。
それで 各ソフトに同梱している 古い ホームページ URL と メールアドレスをどうするか考えると ソフトのアップデート時に 変える方法も有りますが ソフトによっては もう殆どアップデートしない物も有ると思うので この機会に全ての同梱テキスト ファイルの ホームページアドレスと メールアドレスを新しい物に変えて一括アップロードする事にしました。此は 機械的に 旧→新に入れ替えた物ですからひょっとしたらちぐはぐな事が出てくるかも知れません。
個々にアップしていくソフトは同梱のテキストもヘルプファイルもその都度変わりますから 何か有っても その時になれば問題は 解消される筈です。
とりあえず 06/25 に 全ての ダウンロード用 Zip ファイルを刷新しました。

今まで このホームページで公表してきた プロバイダーの ホームページサービス を 2024/03/31 を持って打ち切るとの 連絡が有りました。 さすがに 21年間も同じ所で ソフトの 更新 発表をしてきたのですが 一方的に断られてしまいました。
此は 新たに レンタルサーバーを用意すれば 済む事ですが それでも月額 200円 ぐらいはかかるだろうと思います。 又 ホームページの 原稿は こちらの Local に同じ物が有りますから 問題は無いのですが 同梱しているテキストファイルには 此処の アドレスが 書いてあります。
全て 書き換えてアップしなければならないと思うと気が重くなりますが すぐに片を付けようと思うから焦るのであって ゆっくり やってもそれ程 実害は無いと考える事にしました。

今まで Windows 98 から使用してきた 立ち上げ時のコマンドライン取得の方法が 多分 今までよりこの方がすっきりして 統一されて 良いのではないかと思う方法に考えつきました。
此の事は Programing Tipsにも 書きました。結果はどちらでも同じ事になるとは思いますが 考え方の本筋は新しい方が正当だと思うと 徐々に変えて 行くのが 良いのかと思いますが どちらにしても コード上は 趣味の話ですから その都度 無理の無い効率の良い方を 採用いて行きたいと思います。

Windows 11 の縦に並べて表示するメニュー数が テクニカル インフォメーション に書いた様に大体解りました。此まで ( Windows 10 まで ) とは違い 若干 余分な お世話 が付くようです。
03/20 の SbFolder と 本日の SubFolder は此に沿った物ですが 此処に有る何個かの ソフトは 表示数によっては 影響が 出たりしそうです。( 使用の不具合と言うほどの所までは行かないとは思いますが )
表示数によっては出る物なので 出ない時の方が圧倒的に多いのですが 出た時の 違和感の大きい物 使用感の悪くなる物から 機会が有れば修正して行きたいと思います。

MousePos は ピクセル単位を相手にする その動作の性質からサイズの変更も出来ないし Windows の DPI スケーリングに 任す訳にもいかないので 高精細モニターで使用すると 小さく表示しか出来なくなってしまいます。
だだ 拡大窓もどのサイズでも良いと言う訳でも無く 現在は 225 ピクセル ( 3*3*5*5 ) を使用していますが 今まで 次の 候補は 315 ピクセル ( 3*3*5*7 ) しか思いつかなかったので 高々 4割 のサイズアップですが 大きいサイズの  MousePosL と言うのを作ってみました。
最初に MousePos を作り始めたのは Windows 98 の頃ですから 225 ピクセル に API の StretchBlt で ピクセルデータを 転送する のも結構負荷が有りましたから ( CPU 使用率 5% ぐらい ) 結構気を遣いましたが 現在は PC パワーが アップして来ているので 私の所の 9年前に組み立てた 古い PC でも 315 ピクセル の StretchBlt でも 0.2 % 以下で 済んでいるようです。新しい 物は 略 0% です。
そんな事で MousePos の通常は使用しない所を 省いてサイズもダウンした MousePosL を本日挙げました。

いつの間にか Windows11 のタスクバーに有る検索ボタンが 通常の 2.5倍ぐらいの幅を取っている事に事に気が付きました。 何か意味が有るのかなと思って観ましたが単なるボタンです。多分 昨年の遅い時期のアップデートでなった模様です。
スタートメニューの横のこんな良い場所に長々と と言う感じでサイズを短く出来るのかと思ったら出来ません。無くして しまう事は出来ますが何となく不便です。検索メニュー は Windowsキー + S のキーボードショートカットで現れます。 此なら Windows キー + S を搬出するプログラムをタスクバーにピン留めして指定すれば単なるアイコン幅でスタート メニューボタンの横に置いておくだけで良いと言う事で コーディング( と言う程でも無い )し始めましたがもう少し 汎用性も考えて コマンドラインも指定出来る様にしました。
この辺の使い方は サンプル として 書いておきました。使い方によって もう何個か 便利に使用できそうな Windows + ショートカットキーが 有りそうです。
ソースコードも挙げて置きますので 参考や ひな形 ( 簡単すぎて話にならないかも ) 等にしてみて下さい。 たいへんに 簡単な コードですから C++ のビルド環境をお持ちの方なら中程の内容を コピペ するだけで 同様の物ができると思います。
[ 02 月 27 日 追記 ] Windows11 の 02/22 のオプションアップデート KB5022913 Build 22621.1343 から タスクバーに有る検索ボタンが 通常の大きさに戻った様です。しかし 同時に タスクバーの高さ ( 幅 )と アイコンの大きさが小さく出来なくなった様で まだまだ Windows11 の UI デザインは落ち着かない 感じです。

11/20 に ClipName を アップして ClipName.inf も アイコン付きで Context Menu に入れる事にして ちょっとかっこよく なったかなと 思っていたら なんと Windows 11 の ファイルの右コンテキストメニューの中に パスのコピー (A) と 言うのが有るのに気が付きました。それも アクセスキーが (A) です。1998年 のPower Toy の中に有った機能で  ClipName 作成の動機となった物で 今更かよ Ms と言う感じで ClipName.inf を変えて ClipName の (A) を 変えようかと思いましたが パスのコピーに ２つの 重なったメニューは要らないという事と 機能が全く違うので  パスのコピー はまず使用しないので 本体の方の パスのコピー (A) に消えてもらう事にしました。
探せば 情報は有る物で 無事 簡単に消す事が出来ました。こうなると結構要らない 右コンテキストメニュー アイテムは 有る物で 以前のバージョンの復元 新しいウィンドウで開く とかは 消えてもらう事にしました。
本日 アップした GetWinTx は削った機能も有るのですが メニューの 文言を取得する機能を加えていたので この部分の コーディング をしている時にはこの機能は 殆ど趣味の領域 かなと思いましたが 結構 役立ちました。 多少 メニューの上から GetWinTx を使用するのは 難が有るのですが 殆どの場合は あっさり取得出来る様です。

10/15 の一言 にも書いたのですが Winows 11 から 始まった Round Corner ( 角丸 ) をさせない プログラムも Windows 11 22H2 にした PC が今まで通りに VC++ 6.0 も使用できる事に なって 実際に Windows 11 上で プログラムを出来る事で 比較的すんなりと纏める事が出来ました。
ウィンドウは 角丸ではなくて 以前の様に直角でないといけないとか の意見が有ったりするのですが 私自身は 特に丸が気に入らない 訳でも無いのですが 角丸も小さいのも指定出来るとなると 此は結構使えるかもと言う事で角丸を指定出来る専用プログラムを作って 見ました。角のないウィンドウ 小さな角丸 普通の(大きい) 角丸 が指定出来るようにしました。
非常に シンプルですが効果的なソフトが出来たのではないかと思います。

Windows 10+ つれづれ にも書いたのですが Winows 10 から 直に Windows 11 22H2 にした PC が今まで通りに VC++ 6.0 も使用できる事になって 特に Windows 10 に戻す必要も無くなり 使い慣れた VC++ 環境で Windows 11 上で直に試しながら プログラムが出来る事は大きなメリットになりました。
以前からどこかで書いた様に 今更 VC++ 6.0 かよと思いますが 此処に有る物は 全て Windows SDK を利用して( 参照して ) 直に API Call している物だけなので 開発環境は コンパイル リンクが出来る物なら 何でも良いのです。もちろん VC++ 6.0 は 1998 の物ですから Header も Library も Windows XP 以前の物ですが 新しい API Call で *.h ;.lib が無ければ 新しい SDK から借用してくれば OK です。
又 VS2017 を使用した感じでは 此処に有る様な小さなプログラムでは コンパイルに 特に大きな改善は無さそうです。
そんな訳で 本日 アップした LHAComp は Windows 11 の Round Corner で不具合が出ない様に調整した物です。
又 Windows 11 環境下で プログラム と 確認が出来たおかげで Round Corner ( 角丸 ) をさせない プログラムも そのうち アップ出来るかと思います。
こんな事を書いている間に 10/12 のアップデートで Windows11 のファイルエクスプローラーが タブ表示に対応しました。 結構調べてみると ウィンドウの構造が変わったいる様です。此処に書くのも長くなりそうなので  テクニカルインフォーメーション の 方に書いています。

2022/08/15 に上げた MastrVol.exe は単純な プログラムで まあ此で終わりでしょう と思いましたが 思いも しなかった 落とし穴が有ったようです。
浮動小数点データと 整数データの 変換違いからか データの保存方式の違いからか ちょと間違いと言う程では 無いのですが 足りない所が有った様です。
普通に 考えれば 3% 3 / 100 は 0.03 ですが 開発環境の持つ float ( 浮動小数点データ ) では 29999999 x 指数 と 言う保存で 此を 3% に すると 0.02999999 で 3% に 届きません。値的には 此で 3% で正確さは 問題ないの でしょうが 此の値を SetMasterVolumeLevelScalar にそのまま入れれば 3% に届かないので 2% になって しまいます。日頃から あまり float デートは扱わなかったので 嵌まりましたが 端数の 0.0001 ぐらいを 足す事で 修正が出来ました。気が付けば 当たり前の話でしょうが 取り敢えず MastrVol.exe は %XX が正確に 出る様に修正しました。( しかし 0 〜 100 までしか動かなくて 100 段階しか調整できない物を float で 指定しなければならないのかは 疑問です。)

2022/08/10 に テクニカル インフォメーション を書きましたが 此でやっと COM 対応のプログラムもコンパイル ビルド 出来る 様になりました。それで 此まで Windows Vista から始まった オーディオミキサープログラムが 構想通りに書ける様に なりました。結構何年かの勘案事項で コマンドライン指定で オーディオミキサーのマスターボリュームをコントロール する物です。余分な UI は無し 単に コマンドライン指定 だけです。出来た物を みてみると まあ サイズも 12Kb ぐらいですし それ程大きい物ではありません。
今回は 此の MastrVol のショートカットを クイック起動において便利に使用できる事を主眼にして作っているので  MastrVol.exe +5 とした物を クイック起動 に置けば 此で此のアイコンの Shift Control 無変換 キー の 組み合わせの クリックで 通常使用する オーディオミキサーの ボリュームを コントロール出来ると思います。
ノン ストップ用途 No UI の単純なソフトですが ソフトの小物たち らしい 結構便利な物が出来たと思っています。
同時に ソースコードも挙げていますのでプログラムに興味のある方は参照 ( 参考と言う程でもない ) して下さい。

2019/11/30 に テクニカル インフォメーション を書きましたが 此の時は 自分のプログラム上の考えでしたが よく考えてみると MessageBox API を使用する( 此と類似の動作をする ) 他のプログラムも MessageBox が画面の中央にドンと出る よりは 関連のウィンドウ上に出る方が良い事がありそうです。例えば エクスプローラでのファイル削除の 確認 MessageBox 等は 画面中央より 削除されるファイルの近くの方が解りやすいのではないでしょうか。
そんな考えから CabwcPos に 他のプログラムが出した MessageBox 又は 此と類似動作 のダイアログ が 画面中央に出た( 又は出そうな ) 時には 出した ウィンドウの 中央に持っていく MsgBox 移動 と言う機能を 付けてみました。 例えに使用した エクスプローラでのファイル削除 の確認は格段に使用しやすくなりました。但し動かすタイミングは 後付けだし どういう意味で MessageBox を出したのかも 他のプログラムで 類推でしかないので 多少の外しは 有ってもしょうが無い事だとは思います。
此も使用して 20日間ぐらい経って違和感のない所まで煮詰めたつもりですが 当然何か出て来れば修正かなと 思っています。ただ CabwcPos の内部的なメッセージの流れは マウスボタンは常時感知 新たなウィンドウは タイマーで常に監視 と言う事で此の様な付加機能を付けるのには それ程の負荷も掛からず 向いているのは 確かです。

Windows 11 で Windows の Windows 10 デスク トップ上の見えないタスク。 を Windows がアップデートされる度に確認して行かなければなりません。 が 新に実際に起こっている様です。
列挙 API を使用してのタスクの列挙を行うプログラムは 制限フィルターを 追々 変えなければならない様です。
それとは 特に大きな 関連はないのですが プログラムコードのデバッグに使う 補助プログラムを 2つ と ウインドウを 確認する プログラム SerchWin を 親子 オーナー ウィンドウが確認しやすい様に変えました。 変えた中で SerchWin は プログラムと関係無しで 立ち上げるだけで結構 面白いかと思います。Windows の構造に 興味のある方は 走らせてみて下さい。

05/15 の Top_Most から マウスカーソル 直下の デスクトップのウィンドウを列挙して候補にする EnumWindows を 使用してきたのですが 此だと Windows の Windows 10 デスク トップ上の見えないタスク。 を Windows がアップデートされる度に確認して行かなければなりません。
此の 列挙 API をやめて マウスカーソル下のウィンドウ。 の考え方の方が 良いのではないかと思い出しました。
まだ 確認中ですが WindowFromPoint で直に探すのが 手間いらずなら この方が良いのかなと思います。 ( API WindowFromPoint は 内部的には 大変だろうと思いますが Call する側には関係ありません。) 此だと 後々の デスクトップの様子が変わっても 今ある プログラムは その都度対応に追われなくて済むのでは ないかと 思います。
 [ 07 月 20 日 の追記 ]
本日挙げた ClsClose で WindowFromPoint で直に探す API を使用した物にしました。コードがなんと簡潔になった事よ と思うほどあっけない物に サイズも小さくなりました。此で後々の デスクトップのウィンドウを列挙してフィルターを その都度確認する手間が省けるなら言う事 無しです。
Sorce コードも 両方が 切り替えられてビルド出来る様になっている物を同時にアップしましたから興味のある方は ダウンロードして観て下さい。コンパイル出来なくても CPP のソースを追うだけでも解るぐらい簡単です。

本日の Top_Most をもってデスクトップのウィンドウを列挙して候補にする EnumWindows API を使用した 新しい考えに 基づくプログラムは修正し終えたつもりです。この先は当分 此で行けるとは思っていますが どうも チラチラと入って くる Windows 11 22H2 の噂を聴くとどうもこの辺の状況は 又 変わってきそうです。
まあ 大きく変わって現在のコードでは対応出来なくなったら 又 新たな方法で対応する事になるのですが 以前から 書いている様に ウィンドウズ そのもの自体はそれ程便利にならなくてもいいのではないかと思っています。 ソフトプレーヤーとしての安定した 基盤が一番大事な事ではないかと思います。 ( 決して 現在の ウィンドウズが安定していないと言っている訳ではありません。)
Windows 10 の 22H2 はどうなるのでしょうか。

ここ何ヶ月の間に プロバイダーの方から セキュリーティーの関連で メールは SSL でお願いしますとか ホームページサーバへの ファイルのアップロードは SFTP でお願いします。との期限付きの メールが有ったりして それに対処して今まで通りに運用する 準備はしたのですが 此までは 此のホームページにアップロードする時に使用していた FTPexchg と言う 2001 に作られた アップロード プログラムを使用していたのですが さすがに SSL には対応してはいないので 此は変える事になりました。差分ファイルを 変えるのに特化した物だったので余分な事もなく便利な物だったので残念です。( まあ 今時 Visual Basic 5.0 の ランタイム ルーチン が必要なのもすごいかなと思いますが FTP アップロード は此で何の問題も無かったのです。)
セキュリーティーの関連で SSL でやり取りするのは 時の趨勢で まあそんな物かなと言う事で それなりのソフトを用意すれば 良いのですが それでは 此処 "ソフトの小物たち" のホームページは SSL での対応になったかと言うと FTTP:// では今まで通りに 接続は出来るのは 当たり前ですが FireFox は 此の接続は安全では有りません と出ていますので FTTPS:// で接続しようとすると  接続出来ません。ホームページ用のサーバーが SSL に対応していない様です。何となく 要求だけして 自分はしない と 言う感じで ?? ですが そのうち変わるのかな。

マルチモニターに対応する様にしたプログラミングをしだしてそろそろ約２年程になります。多分此の作業も本日の  SaveTimer で終わりではないかと思います。本来は SaveTimer はもっと早期に マルチモニター対応にすべき物なのでしょう が 最初からあまり必要になって作った物でもないし 日頃から常に常駐させて使用している物でもなし 又 最初に決めた 各項目のデータ構造をどうするか等があって 結局後回しになってしまいました。
日頃から常に常駐させて使用している物でもないと言っても プログラムをしていると 動作は面白く アクセサリーとしても 十分使える事を実感します。他からの要望に添って立ち上げたプログラムですが 以前は結構根気が有って良く此の様な物を 作り上げたなあ と関心などしてしまいます。
今回 新に見直して 最新のコードで 効率も上がった所もありますので いつもの様に バグが無ければ此からも 継続できる のではないかと思います。

6月をもって IE11 のサポートが終了するそうです。所謂 ブラウザーですから Internet Web Page を閲覧する事については 他の ブラウザーを 使用する事で 特に問題は無いのでしょうが IE11 と他の ブラウザー FireFox Chrome Edje とかは ウィンドウの作りの構造が違います。 IE11 までは それまでの ウィンドウズと同様に 子ウィンドウ→子ウィンドウと 今までの コンポーネントの積み重ねの ウィンドウクラスで 出来ていました。
ところが 新しい ブラウザーはウィンドウ自体がこう言う構造をしていません。全く 今までの ウィンドウの作りと違うのです。 ( 何年か前の Apple の Saffari は以外と Windows の基本コンポーネントで出来ているので驚いた事が有ります。)  Windows 95 から始まった Windows コンポーネントを全く無視してフォームが作成されています。もちろん 新しい コンポーネントの 使い方とか API コール 等も公式的にはオープンされていません。
こうなると 此処に有る GetWinTx とか ClipSaver.dll の 他のテキスト取得 とかは殆ど役に立ちません。特に IE のリンクに マウスカーソルを当てた時に 下の方のステータスバーにリンクの URL が出る機能は結構此をコピーするのに便利な物でした。
なんだか この頃見ていると Windows も進歩していかなければならないのでしょうが、全く以前の Win32 の基本を自ら崩して いってしまうのか気になります。( だんだん 他の ウィンドウを相手にする プログラムが 作り難くなってきています。) 余分な事はするな と言う事でしょうか。

以前から 何となく気がついていて 大きく不具合の出るプログラムについては対策している物も有ったのですが 此の辺りで もっとはっきりしておいた方が良いだろうと考えて プログラムチップにも書いたのですが プログラム のタイミング上 今すぐにではなく 状況が落ち着いたら ( 画面が書き換わってからとか キー入力の残りが終わってからとか ) しましょうと言う事で 自分自身に する事を ポストしておく API PostMessage と言うのを結構使用して います。
何となく PostMessage と言うから スレッドの メッセージキューの最後に廻されて 先に起こった通常のメッセージが先に処理される 様なイメージが有りますが 此が大きな間違えで PostMessege された物はその後の処理が終わって メッセージループに戻ると すぐに PostMessege  された物がメッセージとして浮かび上がってくる と言う事で PostMessege ループを繰り返して回しても通常の処理は終わらないと言う事になって しまいます。
この様な 事を避けるためには プログラムチップ にも書いた様に PostMessege アイテムが来たら 通常の処理を先に終わらすと言うような コードが 必要となります。もちろん 全ての プログラムが此が必要だとは思いませんが 処理を後に回すためにタイミングを待つ為の PostMessege を使用する  プログラムには必要になる物だと思います。

半年ほど前に SbFolder SubFolder にメニューを一カラムで表示するオプションSWの /-B を新設しましたが メニューを常に 一カラムで表示する事にすると 割と下の保有アイテムが少ないフォルダーでもすぐに上下に ▲ ▼ が付いてしまいかえって 見通しが悪くなってしまいますし ▲ ▼ が付くと 基本的なスクロールはマウスの左クリックで１つずつ送りになってしまいます。 それが不便なので ▲ ▼ 上での自動送り機能を付けたのですが マウスの疑似左クリックでしていたので 他への影響も結構出て あまり使いやすい物では有りませんでした。
最初は 画面がメニューで覆われてしまうのを避ける為に始めたので /-B SW を指定しても 三カラム以内で表示出来る時には 通常通りのカラム変えで表示する様にしました。此で殆どのフォルダーは▲ ▼ が付かずに表示出来ます。
又 せっかく ▲ ▼ 付きで一カラムで表示出来るのですから 表示最大数を 1024 まで増やしました。( 此までは 環境によって 違いますが 200 〜 400 ぐらいだろうと思います。) 此で最後に -残り000個-と付く事も少なくなりました。
後 ▲ ▼ 付きで一カラムの場合のメニューのスクロールですが PageUp PageDown の挙動と ▲ ▼ 位置での挙動がマッチして いなかったので 送る信号は一本化して 全て内部で消化出来る物に変えて 統一を取り 最初と 最後では必ず停止する様にして 解りやすく使いやすくしました。又 ファイルだけで無く Windows\system32 以下のフォルダー群の様に全てポップアップの メニューにも対応できる様にしました。( 希望的には ▲ ▼ 付きメニューのスクロールが Scroll wheel に対応してくれる 事です。)
自分自身は此で常に /-B SW 付きで使用するので SbFolder.inf からの レジストリーへの関連付けも /-R-B SW 付きで する事にしました。
同じ事ですから SubFolder の同様の改訂も次に行いたいかと思います。

此まで Dokonoko は API の Toolhelp32Snapshot を使用する関係上 64bit プログラムは列挙出来ませんでしたが API を見ていると もっと汎用性の有る API が使用できる事に気が付きました。もっと直接的に 実行ファイルを 取得出来るので コードも簡単になり 全ての プログラムの実行ファイルを特定できる様になりました。
取得出来ないのは UAC 絡みの 制限と フォルダーを オープン 出来ないのは アクセス権 絡みの時だけとなりました。 アクセス権 絡みの時は パスネームは取得出来ているので 此をクリップボードに代入するオプションも 付加しました。 此で Dokonoko もほぼ全てに対応できる様になったかと思います。
ソースコード も新しくしておきますので 興味のある方はのぞいてみて下さい。

11/25 の 一言 に書いた様に Windows 11 の デスクトップ上の 見えないタスク を排除する コードを書いている時に気が付いたのですが デスクトップ上の見えるタスク を 列挙する プログラムは 此処 ソフトの小物たちには結構有ります。殆どの場合は 見えて表示されている タスク ( プログラム ) が 対象です。此までは 最後までを対象にして 列挙していましたが 見えるタスクだけなら "Progman" 所謂 プログラム マネージャー以降は 見える物が無い事に気が付きました。したがって "Progman" が出たらもう終了して良い事に なります。環境によって 違うとは思いますが 全体として Window 列挙は 200 ぐらいになりますが "Progman" が 全体の 3/4 ぐらいの所で 出るとすれば 後の 1/4 ( 50 回 ) ぐらいは無駄になってしまいます。そんな事で 此からの デスクトップ上の タスクの列挙は "Progman" が出たらもう終了 と言う事にして 効率を上げたいと 思います。
此の 話は プログラミング チップの話かも知れませんが それ程 の字数を取る話でもありませんし それでも 効果は 結構な物だと思うので 此処に書いておく事にしました。

Windows 11 を導入してみると 03/01 の テクニカルインフォーメーション にも書いた様な事が Windows 11 ではなおさら多くなって いる様です。そこで ウィンドウズを 調べる GetWinCnst, SerchWin を 新に使いやすく 現状に合う様に 改良しました。これで Windows 11 も解析しやすく なると思います。 以前からの事ですが Windows を相手にする ユーティリティープログラムは 何らかの Windows の基本仕様の 変更に伴って 対応していくのは 当たり前の宿命かも知れません。
当面の間 デスクトップのタスクを列挙する プログラム TaskSwch,TaskMuEx,BwFwButn は Windows 11 では 余分な物が 出るかも知れません。

メニューのアクセスキーに関連した事を確認していると テクニカルインフォーメーション に書いた様な事が気になり出して アクセスキーに関連 と同時に マウス 右ボタン でも 支障が無ければメニューの決定が 出来た方が良いのではないかと思い 本日 CabULCmu に アクセスキーに関連 と同時に Menu Rボタン のオプションを付けて アップしました。まあ 後付の対応ですから ソフトによるメニューの右ボタンの使用方法によってはおかしな挙動も出るかも 知れませんが メニュー決定に 左 右 ボタンの意識なく出来る様になります。

EjctClse はメニューの数も少なく ドライブレターをメニューのアクセスキーにしたり 確認の為のメニューは Space キーでも OK にしている関係上 キー操作で選択する事が多くなっています。そんな時に  テクニカルインフォーメーション にも 書いた事が 結構起きていたので此の対策をしてみました。同じような メニューだけの プログラムも何個か有るので  確認して気が付いた所から改善して行こうかなと思います。

此処に有る プログラムの中で エクスプローラーの フォルダー ファイルの 右コンテキストメニューを 拝借して出す プログラムが何個か有ります。此の方法は自分で状況を判断してメニューを作る訳ではないので結構便利です。
その中で フォルダー表示ウィンドウの左上部のアイコンを右クリックするとそのフォルダーに対する エクスプローラーの コンテキストメニューを出す機能を持つ物が CabULCmu OnScroll BwFwButn です。そのフォルダーの上を開いて メニューを出さなくても良いので 結構便利に使えます。
便利に使っていたのですが ある日 キー入力をした時に メニューに有る アクセスキー ( アクセラレーションキー ) が 効いていないのに ふと気が付きました。ちょっと不便です。コードを確認してもおかしな所はありません。 デバッグで確認してもメニューの出ている時はキーメッセージが出ていません。不便だから何とかしたいと 色々いじっている内に 何故か 全く関係なさそうな メニューの選択を右ボタンでも認める設定 ( TPM_RIGHTBUTTON ) を 外すと アクセスキーが効く様になりました。何故だかは全く解りません。此は私の持っている ４個の PC 全て ( Windows 10 ) 同じ結果です。右ボタンクリックでの選択は出来ませんが アクセスキーが効く方が便利です。
Windows 10 もまだまだ 解らない 変な 所が有る様です。

SubFolder ( SbFolder ) は此までフォルダー以下のアイテムを出来るだけ一度に多く表示する為に メニューの上下が 画面に収まらない時にはマルチカラム ( Menu Break )にして表示していました。ただ フォルダーを開く用途に限定して 考えれば テクニカルインフォーメーション にも 書いた様に上下に ▲ ▼ が付いた一カラムのメニューも 常に次の段が右に出ていくので使い勝手は却って良い事も有るのでは ないかと思う様になりました。
多少 期間の短いアップですが 本日 メニュー表示は 一カラムだけの SW 指定の出来る SubFolder を挙げました。

結構気に入って使用していたマウスのサイドボタンが チャッタリングを起こす様になってしまいました。常用している  BwFwButn の動作がおかしくなってしまったので 最初は 又 バグを作ってしまったかと思いましたが BwFwButn は サイドボタンの ON OFF のタイミングで 色々な事を判断しているので SW の チャッタリングでプログラムの動作が おかしくなった様です。
はじめは マウスを掃除して 接点復活材で対応しようかなと思いましたがマウスが分解出来ません。それに PC 関連 だけでなく 他の道具でも マイクロ SW には結構接触不良とか 痛い目に遭っています。それで機械的に修復する事はやめて プログラム的にガードを入れる事にしました。此を入れてみると 今まで有った 訳の解らない おかしな動作も無くなり 動作も安定しました。まさか マイクロ SW の動作まで考えてプログラムをする事になるとは思いませんでした が 次の アップから SW のタイミングがクリティカルなソフトから チャッタリング防止コードを入れていこうかと 思います。
この辺の詳しい事はテクニカルインフォーメーション にも書きました。

もう Update も無いだろうと思っていた ClipSort に新しい機能を付加しました。テキストエディターで日記擬きや 覚え書きやら 書いていて 新しい項目が上が良いのか 下が良いのか結構迷って それでは テキスト行の順序を 変えようと思った時に ふと テキストエディターに 行の順序の反転機能 ( 最初の行→最後の行, 最後の行→ 最初の行 ) が無く ClipSort にもこの機能は有りません。数行ぐらいならカット＆ペーストでも対応出来ますが 多くなるとほぼ不可能です。
いつもの事ながら 不便な事は何とかしよう と言う事で ClipSort にこの機能を付加しました。ClipSort 自体は テキストの行分解をして 再度テキストに再構築する物ですから ほんの数行のコード変更で オプション機能を 含めても十数行で済みました。ましてやソートも無しのメモリー上の入れ替えですから 処理も一瞬です。 ですが有ればやはり便利で繰り返しのプログラムはすごい威力だと実感します。此で 色々な テキスト形式の メモの順序の入れ替えが心置きなく行えます。

本日 記念に と思って残していた DialUpDs を 使用も バージョンアップも無いだろうから削除しました。 もう モデムも使用する事もないし モデムの付いた パソコンや モデム自体も無いでしょう。 ( モデムの付いた ノートは持っていますが 此を繋ぐモジュラージャックやアクセスポイントも有りません。)
モデムも 300 ボーから始まって 2400 ボー 56K モデムと速くはなってきましたが 現在と比べると全く話にならない スピードです。
DialUpDs の初めが 2002/04/12 Ver 1.000 ですから この頃は自宅でも出先でも ダイアルアップ接続をしていて ダイアルアップ は時間料金制ですから DialUpDs は 他のダイアルアップ接続プログラムと違って コマンドライン 無しで ただ立ち上げれば 全ての ダイアルアップ接続 を切る様にする仕様にしたかったので作成したのを覚えています。
考えて見れば 有線LAN も 10M 100M さすがに 1G LAN は速いなと思いましたが。ネットの通信も ISDN ALDS 光 USB も USB2 が出た時は もう十分速いと思いましたが USB3 が出るとやっぱり速い方が良いかなと思います。
10Gb 有線 LAN は速いんでしょうね。私の所は全ての装置が 1Gb 止まりですけど。
装置 設備の関連で陳腐化するプログラムも有りますが Windows の世代を超えてまだ有用なプログラムも残っています。 さすがに Windows 95 の時から現在までも まだ有効なプログラムを見ると Windows 95 で固定した Win32 API 仕様は 基準をしっかりして変えなかったのが良かったのではないかと思わざるを得ません。

全く おかしな話ですが 03/10 の GetWinTx 2.160 に TipText 部分にも デスクトップに新設されて取得テキストとは関係ない見えない ウィンドウ 排除を 入れた GetWinTx 2.170 を アップしました。たった 一行の 見えない ウィンドウ 排除 のコードを入れただけで Windows Defender の チェックでも FireFox の ダウンロード チェックにも かからなく なりました。TipText 部分の コードですから 無くても まあ 特に 問題なく動作はするのですが 他から なんやから 黒だの 言われるよりは ずっとすっきりするでしょう と言う事で 2 日間 しかたっていないのですが 即アップしました。此で 当分何か 無ければ このままの GetWinTx で行けるのではないかと思います。( 白 黒 判定ソフトの 基準もなかなか解りません。)

03/01 の テクニカルインフォーメーション にも書いた内容を 各プログラムで そのつもりで確認してみるとデスクトップを覆っているも物が有る事で 此が邪魔をしたりして 結構おかしな 物が 事が 起こっているようです。したがって どうしても必要な物から 危ない 問題の出そうな物から 対応していこうかと思います。
とりあえず ウィンドウを列挙する機能を使用している物は 全て当たって確認する事になるのでしょが Windows を 相手にする ユーティリティープログラムは 何らかの Windows の基本仕様の変更に伴って 対応していくのは 当たり前の 宿命かも知れません。

ずいぶん 久しぶりに StartQut をアップデートしました。もう 忘れかけられた感じのソフトですが 私の所では  今だに現役で インターネットを始める時には デスクトップに有る此のショートカットをクリックして NetTrafc.exe を 立ち上げて FireFox を立ち上げます。そして FireFox の位置を PosWindow.exe でいつもの位置に移動します。
此で 通常通りに インターネットをスタートします。StartQut の時間は 現在の WiFi 環境では特に必要は無く  ダイアルアップ接続の名残ですが まあ有っても邪魔にならず何かの参考です。
又 インターネットを終了する時には StartQut をクローズすれば 全ての FireFox は終了し また 関連の メールソフトも  終了する様にしています。デスクトップには NetTrafc が残ります。
使い方に よっては 用途の 限定された マルチコマンドランチャーですがさすがにもっと効率の良い プログラムコードが 有れば 自分自身が使用するプログラムであろうと 改良して使用しているのであれば 此をアップするのが 良いかと思います。
ただ ヘルプ ファイルを同梱して改訂はしていますが 以前の *.HLP 形式の物ですから此を読む為には  テクニカルインフォーメーション 参照が  必要かもしれません。

通常色々整理して使用しているフォルダーの深さは 人によって違うでしょうがそれ程深い物ではないのでしょうか。 フォルダー名を打ち込んだりする事を考えれば 深さは数段と言う所ではないでしょうか。
SbFolder SubFolder はフォルダー深さの制限がかかってはいけないと考えて 31 段確保しています。ただ SubFolder は 常駐するという事で制限深さ全てのポップアップメニューを用意して立ち上げていましたが あまり使用しない深い 所まで用意しておくのは無駄が多すぎると思い立ち 最初の数段の深さを用意した後は SbFolder の様に On Demand で 用意する事にしました。多少 準備済みかどうか確認の手間はかかりますが 多分此の方がシステムにかける負荷は 使わない物を用意しておくより少ないと思います。

一年半ほど前に Windows XP の デスクトップ PC が立ち上がらなくなって Windows XP での検証が出来なくなって いましたが ふと気が付くともう15年以前に出先用に使用いていた ノート PC が有った事を思い出しました。
動くかなと思いつつ立ち上げてみると バッテリーはだめそうですが本体は元気に立ち上がりました。 ( 久しぶりに HDD のカリカリ言うシーク音を聞きました。)内部時計も 20秒 程度しが違っていないのには驚きましたが 中に入っているソフトの日付を見ると5年ぐらい前に立ち上げててこ入れを しているようでした。( 忘れていたぐらいですから 別に持ち出して使用していた訳では有りません。) 此の ノート PC は外使い用で 15年ぐらい前には 持って出ていたので 開発環境の Visial Studio も インストール済みで C++ での ソフトの作成も出来る様になっています。まあ 現在では 殆ど XP 環境での動作は 意味が 無いとは思いますが とりあえず 開発環境 動作検証環境に Windows XP と公式的に書かける様になりました。

バグを作ってはいけないと思ってコーディングしていた ClipSaver に思わぬ落とし穴が見つかりました。 結構古くからのバグですがバッファメモリー使用の方法によって救われていたのが以前には OK だったのが 現在は ( 一年半前ぐらいからか ) NG になって居ました。
したがって ClipSaver ご使用の方は 不具合が 無しでも 比較的緊急アップデート を ダウンロードして ClipSaver.exe を差し替える事をおすすめします。
ウィンドウズ XP の検証が出来なくなったのが発見の遅れにつながりました。XP での不具合レポートありがとう ございます。( レポートが無ければ 多分ズーッと気が付かなかった事でしょう。)

Windous 10 になってから マウスホイールでのスクロールが マウスカーソルがウィンドウ上に有ればインアクティブな ウィンドウでも下の方でスクロール出来る様になりました。此の為 此の用途に作った OnScroll は Windows 10 では 横スクロールが出来る可能性を残して 何となく影の薄い物になりました。
現在の状況を考えると OnScroll の仕様の軸足を Windows 10 の方に移しても良いのではないかと思う様に なりました。此の辺りの事は テクニカルインフォーメーション に書きました。Windows 10 を使用していると 肝心な フォルダー表示ウィンドウ ( エクスプローラー ) が横スクロールに対応していなくて不便です。今回の OnScroll は 此の様な出来ない事に対応する事を主目的にしました。今まで 横スクロールに対応していなかった 物でも 横スクロールさせる事も出来るし 多少制限付きですが 縦スクロールホイール( 通常は付いている )で マウスカーソルが横スクロールバー上に有れば 縦スクロールホイールで横スクロールさせられるとかが出来る とか 応用範囲が広くなりました。その為に Windows 10 での使用が 便利で 価値の有る ソフトになりました。

IME の挙動について考えさせられた テクニカルインフォーメーション に [P.S.09/01] を書きましたが それ以降 此処に有る色々な プログラムで確かめてみると IME を使わない宣言をすると非常に効果のある プログラム それ 程効果の無いプログラムも有る事が解ってきました。外部とのやり取りの無い 常駐しても自分だけで何かをしている 物程 効果が大きく メモリー占有量の減少が大きい様です。
そんな事から 一番効果が大きく問題の少なそうな NetTrafc を本日アップしました。タスク マネージャーで 見てみると メモリー使用量は 2.8Mb から 0.7Mb ぐらいに 1 / 4 程度に減少しています。これぐらい違うと 積極的に IME を使わない宣言をする価値は 十分有る様な気がします。

IME の Control プログラムをしている時に 新たに IME の挙動について考えさせられました。この辺りの事は テクニカルインフォーメーション に書きましたが IME を使わないのなら これからすぐにどうのこうのと 言う事ではないのですが こんな事も考えながら プログラムをする方が良いのかな と思い始めています。

本日 Just System の ATOK パレット の様に デスクトップに置いた 言語バー を IME を使用していない 直接 入力時には 隠してしまう ( 消してしまう 無くしてしまう ) プログラム HideLBar をアップしました。
此で ATOK は ATOK パレット を出さなくても良くなり 大手を振って テキストサービスを使用する にして Windows 10 の全てに使用できる様になったし Ms IME の方は 現在直接モードか IME 使用モードかが はっきり する様になりした。この辺りの事は 2020/08/01 に テクニカルインフォーメーション に書きました。
プログラムコード自体は なんだか 此でいいの ぐらいあっさりした IME コントロールに用意された API だけを 使用した物ですから ソースコードも揚げてありますので C の処理系を 持っている方なら 開発環境が違っても  同様の動作をする プログラムをコンパイルリンクする事が出来るだろうと思います。
とりあえず ATOK Ms IME の動きが統一されたので デスクトップ廻りの操作がすっきりした感じです。

05/10 からマルチモニター環境も考慮して 各プログラムをアップして来ましたが マウスカーソルの座標が  0〜スクリーン右下 ( +1919,+1199 とか ) だけでなく マイナスも取り得ると言う前提で まだ 道途中と 言う感じです。
とは言っても 全体像は 使用 API も コードもほぼ固まったので 後は此を続ける所までは来ています。そこで 本日 デスクトップ全体の ソフトのフォーム状態を調べて確認する AdjustPos をアップしました。 この AdjustPos は自分自信もそうですが 他のプログラムを全て調べるので マルチモニター用に 使用している API コード を確認するのには向いています。
此処にある 全てのプログラムを修正するのにはまだまだ 時間がかかりそうですが 以前にも考えた通り  必要だと思う物 マルチモニター環境だと 不具合が大きいと考えられる物から修正して行きたいと思います。

ひょんな事から 私の所でも マルチモニター環境が構築出来てしまいました。別に新しい器機を 買ったとかではなく  此まで有った デスクトップ PC の LAN ケーブルで繋がっていた一台に 10年前の製品で その辺にほって 置かれた USB 無線LAN アダプター を挿して WiFi ( 無線 LAN ではない ) を使用できるようにしただけです。 此で Windows 10 の Miracast で接続すれば なんと マルチモニター環境が構築出来ました。 ( 何か拍子抜けです。)  もちろん モニター自体は離れた所に有るので 画像等が 並列して繋がって見える 訳でもないので 実用には ほど 遠いのですが マルチモニターの 検証用にしては十分です。
あっという間に繋がって不思議な気がしますが WiFi Alliance の規格の内だそうで WiFi が インターネット接続 だけ ではなかったを 改めて認識しました。
この環境で まあ モニターも 2個だけですが プログラムも検証しやすく なり ちょっと試した所 何個かの物は マルチモニター対応には不適で なるべく早くに修正した方が良いのを 確認出来ました。

NetTrafc のヘルプファイルを書いていて 制限事項を書き出して感じたのですが NetTrafc を作成した 2014年頃には まだ 1Gb Gigabit Ethernet しか無く 此でも十分に速く NetTrafc も速度的には全く制限を受けなかったのですが  そろそろ 10Gb Gigabit Ethernet が実用化して来るのを見ると 隔世の感がが有ります。
この間に SSD が出てきて 500Mb/sec を出して SATA 規格 ( 6Gbps )を１杯まで使用し NVMe SSD では 3500Mb/sec を 出す様になりました。( 私の所でも NVMe SSD でこれくらい出る環境が有ります。) 又 SSD ではないのですが 5GB/sec ( 40gbps ) 出る物は以前から RAM Disk として使用しています。( 動画切り取り用には必須です。)
とにかく 物や 通信速度がどんどん速くなって来ています。ただし Windows の基本は Win32 API ですから最初に 作成した Windows 95 の時には考えられない様な 速度 と データ量になっている事は確かで 設計設定した時には 余裕の有った 32bit データ値の入れ物も 量 速度 共に余裕が無くなって来ている 所が出ているのは確かです。
私が 心配する事でもないのですが これから Windows の API をどの様に変えていくのか 興味の有る所です。 ( アプリケーションソフトだけなら 大きくデータの確保できる 64bit 化も有りでしょうが。)

プログラムソフトは単発的に立ち上がって終了する物は除いて ある程度常駐して機能をする物は その動作を 決める 設定を持つ物が殆どです。設定は レジストリーに持つ物や ファイルに書き込んで持つ物や コマンドライン   SW で指定するとか 様々です。
又 プログラムの中には 自分の設定ではないのですが 機能するには何らかの記憶ファイルが 必要な物も 有ります。本日 アップした CabwcPos ですが 開かれたフォルダーのサイズと位置を記憶しておく メモリーを  ファイルに書き込み 此を次の立ち上げの時にメモリーに戻す ファイルの読み書きが必ず入ります。 此までは 自分自身の 動作を決める 設定は 立ち上げ時のコマンドライン SW で行っていてましたが 設定も 18 個 ぐらいになり 作った本人も 此の SW を正確に 指定するのが ほぼ不可能状態になっていました。
ちなみに最後の ショートカットに入れた SW は /QDGULBJINA /W664H562 /(A-) でした。 考えて見れば CabwcPos は 必ず CabwcPos.pkg を残し 又 読み込む訳ですから 此の CabwcPos.pkg の中に 自分の設定も埋め込んでしまえば 手間無しでコードもだいぶ節約出来ます。使い出してみると だいぶ 使い勝手が良くなりましたし 初めて立ち上げた時も 妥当だと思われる 設定 所謂デフォールト指定も 出来る様になり 初めて使用する時にも便利になりました。
フォームを表示するソフトは フォームの位置とかサイズの為に 殆どは Config.ファイルを 持っているのですが フォームを表示しないソフトは ファイル読み書きを ケチって コマンドライン指定を選択したのが 却って 仇と  なった感じがします。
[ 04 月 05 日 の追記 ] BwFwButn も同様に BwFwButn.bwf の中に設定を埋め込む様にしました。

本日アップした BwFwButn は 基本的に コマンド と それに与える パラメーターを 一行に書いた テキストを 実行する Win + R で出る ファイル名を指定して実行 と同様の ランチャーです。ただ 行を多数行にすれば マルチ コマンド になります。この辺の 詳しい事は テクニカル インフォメーション に書きました。
此の コマンドセットの解析部分に 不備があったので 新たな考えで 思い切って修正しました。此で BwFwButn の 内部 コマンド /CB がより多くの場合で 正確に使用できる様になりました。( 私は 此の /CB  機能を マウスホイールの プッシュダウン に割り当てています。)

本日アップした SaveTimer から テスト用の 画像と WAVE ファイル 設定用の SaveTimer.qnf ( これの設定では ファイル指定はパス無しで同じフォルダーが前提です。) を同梱してダウンロードして解凍したら その同一 フォルダーの中で動作確認を出来る様にしました。これで 最初の方はずいぶん何がどの様に出来るか すぐにテスト出来て解りやすいと思います。
ただ 画像やら WAVEやらを同梱したので Zip サイズが 16Kb → 205Kb になってしまいましたが現在のネット スピードなら全く問題ないでしょう。又 テストが終わったらバッサリ削除して下さい。

前々から 思っていた ソースコード置き場 を作りました。プログラムを しない方にはあまり用の無い物ですが する方にはちょっとしたヒントになるかもしれません。もちろん ソースコード が有れば 即 コンパイルして 実行ファイルが出来るという訳でもありませんが プログラム 作成の 手助けになればと思います。
ただし 数が多いので 何処まで詰められるか解りませんし 手間を考えるとコードに解説もコメントも入らない とってだしの イメージは拭えません。それでも ソースは単なるテキストですから探し方によっては参考に なる事も有るかと思います。( ただ ソースコードを追うのは久しぶりだと自分で作った物を追うのも大変 ですから 他の人が書いた物はかなりの困難になるかと思います。)

[テクニカル インフォメーション ]  に 書いた MessageBox を適当な所に動かして表示する と言うのは思っていた以上に 見やすく 意味のある所に 移動すれば より解りやすくなる事も実感出来る様になりました。
又 メッセージボックスだけでなく フォルダーを選択するダイアログ ( SHBrowseForFolder ) 等も同様に位置を 動かす事が出来るので たいへんに応用範囲が広いものだと解りました。そのうち Programing Tips にも  コードソース を置こうかと思いますが 余りに少ないコードで実現出来るのでページの容量が 1ページになるか 心配なぐらいです。
とりあえず 本日の CompFile から採用しましたのでどういう風に動くのが試してみるのも良いかもしれません。 一番の初めは 此の CompFile の 相違ファイルです。同一ファイルです。のメッセージボックスが フォームとは 関係の無い 画面の中央に表示されるのが気に入らなくて 始めた物ですから たいへんにすっきりした物に なりました。
これから 此の メッセージボックス を動かす方法を 他の ソフトにも適用していこうかと思います。やり方に よっては UI がずいぶん良くなる事も期待出来そうです。
[ 12 月 10 日 ] Programing Tips に コードソース を置きました。

Windows 10 Ver 1909 ( Nov Update ) もあっという間に済んでしまって 何となく拍子抜けしてしまいました。 此では 毎月有る 品質更新プログラムの方が時間も手間もかかる様な気がします。ダウンロード容量も 毎月の 品質更新プログラムよりも小さかった様です。まあ勘ぐれば品質更新プログラムに既に入っていたのでは ないかと思います。
良く言えばそれだけ Windows 10 も安定して来て する事も少なくなってきたのかもしれません。とりあえず  Update した後 環境を元の様に整える事も無かったのは助かりました。

ついに 私の所でも テスト用の つなぎ替え Windows 7 を除いて 全て Windows 10 になってしまいました。 これ以降 以前の バージョンの Windows でのテストは出来なくなってしまいましたが 大局的には特に問題は 無いかと思います。今更 以前のバージョンの Windows で働く事を担保する必要も無いでしょう。 全体的には Windows 10 Only サポート で良いのではないかと思います。
この辺の 事は Windows 10 つれづれ にも書きましたいた

本日 アップした BwFwButn は テクニカル インフォメーション にも書いた ツールチップ 擬きを 適宜 有ると便利だと思われる 所に入れました。此まで 何のフォームも無く メニューと 選択機能だけを実行する BwFwButn でしたが 多少 UI が良くなりました。ツールチップ 擬きも何処でどのように出すかはこれから使用していくに したがって 変わってくるのでしょうが とりあえず 初めの一歩かなと思います。

最近 1つの PC のディスプレーを 4K 程ではないのですが 高解像度の物にしました。画面は広くなったのは良いので すが それ相応にサイズが大きくなった訳ではないので 文字が小さく 線が細くなってしまいます。本来なら それ なりの DPI を設定して使用するのが順当なのでしょうが DPI を上げると Windows の仮想スケーリングによって 文字 などが滲んだ様になってしまうのもどうかと思います。( 4K ぐらいになれば却って良いのかもしれません。)
そんな時に Windows 10 1809 から簡単に利用できる テキスト拡大を使えば色々な所で表示される使用文字だけは 大きくなり見やすくなります。( 線の太さは細いままですが。) 此の辺りの事は テクニカル インフォメーション にも書きましたが どのように使用するかは人それぞれになるのだろうと 思います。
とりあえず 此処ソフトの小物たち でフォームを表示するソフトは Windows の持っている UI font を基準にして サイズを出していて DPI Aware プログラム ( システムの DPI スケーリング 不許可 ) としていましたが Windows の持っている UI font は Windows 10 で新設された テキストサイズ 拡大機能 には連動していません。 したがって システムの表示文字は大きくなっても フォームは拡大されず フォームの大きさも 一定のままでした。 此では せっかくの文字拡大機能と DPI Aware とは言いながら連動しないので これからは システムの拡大機能と 連動した フォントを使用する様にして 行きたいと思います。又 使用法も人それぞれだと思うので 個々のソフトの プロパティから 仮想化スケーリングを選択できる様に仮想化スケーリングをされては機能しないソフトは除いて DPI Aware 宣言を外す方向で 行こうかと思っています。

06/05 に 共通フォームウィンドウを使った小さなソフト ExifTime を アップしましたが 此の 共通フォームウィンドウは 特定フォルダー以下から連続して何かを探して なんとかする と言う用途にはたいへん使いかっての良い フォームと コード内容なのですが さすがに 最終更新が 2017 年 09月 ぐらいなので 今ならこうは書かないな と思われる所が 散見されて EmpFolder InvaLink と アップしたのですが それでも細かい所 不安定 ( 不安全 ) な所とか修正しきれて いませんでした。本日 アップする InvadURL がほぼこれらの改善を出し切った安定版になるかと思います。 
そのうち ExifTime の安定 改良版の 後に EmpFolder InvaLink と アップしようかと思います。もちろん EmpFolder InvaLink は 以前の 2017 年の物よりずいぶん良い物で通常使いには何の問題も無い筈です。 ただ自己満足的な 現在考えられる最良のコードではないと言う事です。
[ 07 / 01 ]  同じ理由で ExecSlct の補助プログラム ExecMenu を アップしています。

本日 久しぶりに ソフトの小物たち らしい 割と気に入った ExifTime と言う JPG 画像の Exif 情報 の  オリジナル撮影日時 を読み取って ファイルの更新時刻 を その撮影日時に変更するプログラムをアップ しました。此の辺りの 詳しい事情は テクニカル インフォメーション に書きました。共通フォームウィンドウを使った小さなソフトですが 写真 ( JPG 画像 ) 整理には無くてはならない物になりそうで 必要な物はプログラムする と言う趣旨にも 叶っているのではないかと思います。

Google の巡回ロボットが 4月30日に廻ってきまして サイト調査のセーフ基準が変わったらしく "このサイトは安全ではありません。訪問者のパソコンに不要なソフトウェアや不正なソフトウェアをインストールしています。" と 久しぶり( 何年ぶりか ) になってしまいました。
サイト自体は 改ざんされている訳でもなく 単に Google の巡回ロボットサイト安全性検索アルゴリズムが変わって  変に間違った方に厳しくなって GetWinTx.exe が掛かっただけの筈なので 今回は対策は何もしない事に決めました。 そのうち 巡回ロボットが改良されてのバグが取れる事を期待します。( とはいえ 05/05 には GetWinTx.zip はテキスト だけにしてあったのですが。)
と 悠長に構えていたのですが Gmail で受け取る時に 此の 黒判定になった ソフトの小物たちの URL が入っていると 通常のフォルダーではなく 迷惑メールのフォルダーに入ってしまう事が判明しました。"恐るべし Google の一人芝居。"
此では あまりに不便なので やはり 黒→白判定に積極的に戻す事にしました。( 消極的には GetWinTx.zip はテキスト だけにしてあるので 05/05 からの間に 巡回ロボットがやってくれば 白にはなったのですが 11日間 待っても やってきてくれません。)
それで Google サイトステータス のチェックをリクエストしました。( もちろん GetWinTx.exe はどこかに隠しました。) 待つ事 一日半で "安全ではないコンテンツは見つかりませんでした" と言う結果で 白判定の 通常のサイトに戻りました。 Gmail で受け取る時にも ソフトの小物たちの URL が記述に入っても単なる受信フォルダーに入る様になりました。
何か 変だけど " めでたし めでたし " かな ？？

Google の巡回ロボットが 4月30日に廻ってきまして サイト調査のセーフ基準が変わったらしく "このサイトは安全ではありません。訪問者のパソコンに不要なソフトウェアや不正なソフトウェアをインストールしています。" と 久しぶり( 何年ぶりか ) になってしまいました。
又か と言う所で 古くは 2015/08/25 Googleロボット 最後は   2017/11/15 のウィンドウ Defender やらですが 今回は Defender は大丈夫で 此の辺りの 事は プログラム Tips に も書いた事と同様ですが あまり気分の良い物ではありません。
サイト自体は 改ざんされている訳でもなく 単に Google の巡回ロボットサイト安全性検索アルゴリズムが変わって  変に間違った方に厳しくなっただけなので 今回は対策は何もしない事に決めました。そのうち 巡回ロボットが改良されて のバグが取れる事を期待します。それまでは危険性を知りつつ敢えて繋げると言う事にして下さい。

2013/04/02 の テクニカル インフォメーション に書いた 自分が 立ち上がる時にアクティブウィンドウを参照するプログラム も 有る様に 逆に 立ち上がる時に誰も アクティブ でない方が 都合の良いプログラムも有る事に気がつきました。
此の為 BwFwButn では コマンドを立ち上げる前に必ず 以前にアクティブだった物を フォアグラウンドにしていましたが  本日の BwFwButn で フォアグラウンド をその都度指定できる 内部コマンド /F を新設しました。此で フォアグラウンド で出る ツールティップの出現を防いで処理した後に 他のプログラムの関連ウィンドウをアクティブにして新しい プログラムを立ち上げると言うような マルチコマンド も記述可能になりました。

Windows 98 から使用している ClipName の コード内で Windows 98 ME ( 2000 ? ) で必要だった 「指定された ファイルに対して・・・・・・ 関連付けて下さい。」と出る ダイアログ はそこで止まってしまうので ClipName 側で 消す処理をして その名前も取得できるようにしていたのですが ここの所 ( と言うか何年もかも ) 見ていないので この機能は NT 用の ClipName からは コンパイル上で 削除しました。 何となく いつかは使用する機会も有るのでは ないかと考えて置いていたのですが 通らないコードは 捨てて軽量化をしました。 此で 立ち上げ時の 確認と 最後での確認も無くなり だいぶ すっきりした動作となりました。
何故 今此が残っているの とは思いましたが 以前には 必要が有って 入れたコードは 必要性を見極めて省くのは なかなか 決断しにくい物です。

2019/01/10 に書いた テクニカル インフォメーション の様な事が 設定ウィンドウのページ内の コピーボタン での 表示テキストをクリップボードに代入する機能にも 起こり 他で 利用する時 特にANSI 変換して使用する時には あまりに不便なので 此の UTF-16 では アサインされていない コードを抜く( 削除する ) 専用のプログラム ClipPrune を公開しました。
多分 今まで作成した物の中では最小規模の物ですが クリップボードテキストに候補が無い時には確認だけで他は何も しないので 取得テキストが不確実な(あやしい)時には 何も考えずに立ち上げて 通してみるのも良いかと思います。

01/20 の一言で 新たに開いたフォルダーを殆ど重ねて開くのは 全く実用的ではなく 新たにフォルダーウィンドウを 開いた時には 重ならない様に開いた方が良いのではないかと書きました。
本日 CabwcPos に 記憶されていない フォルダーウィンドウを開いた時には 一番上位のフォルダー表示ウィンドウから 幅にして 約半分ずらして表示する様にする 半幅調整 と言うオプションを付けました。此は 前の有ったウィンドウから 半分の幅分だけ右にずらして表示しようとする機能で 私のフォルダー表示ウィンドウ使用の方法では思った通りで  新たに開いたウィンドウを移動する事も無く２つのウィンドウを見比べながらすぐに作業が出来る様になりました。
ウィンドウを掴んで移動させないので CabwcPos は位置を記憶する事も無く 無駄がなくなりました。此の為 僅かな可能性で 削除されたフォルダーの記憶を CabwcPos のデータから削除出来るかもしれないと思われる コードはバッサリ削除 して 結構軽量化出来ました。又 .3_ は除外する のメニューとコードも削除しようと思いましたが 此は オプション 扱いだから とりあえずは残しておく事にしました。( 私は もう 此のオプションは使用していません。)
作業中のフォルダーウィンドウの配置は人によってそれぞれだとは思いますが ファイルや フォルダーの ドラグ &  ドロップ も出来ない 両方を同時に見比べる事も不自由な 殆ど 全面的に重なり合った配置は 作業効率が 悪いのではないかと思います。

CabwcPos も CabwcPos.dll 使用から 離れて 5ヶ月たってやっと全てのコードが CabwcPos.dll 向けから離れて  新規アクティブ方式に最適化され 余分な所も無くなったと思います。
ただ 何もしない時の エクスプローラーの 表示位置については 新たに開いたフォルダーは タイトルバー高さぐらい 右下に重ねて開かれるのは 多数のフォルダーを開いた時には 整然として 格好は良いのですが 一番上の表示が全ての 表示を覆い尽くして 下の物は見えず下の物を上部に上げれば 又 此が下を覆い尽くす と言う事になり 全く実用的では 有りません。結局何かするには 個々の ウィンドウをつかんで動かして 両方見える様にしなければなりません。
そのために 個々の フォルダーウィンドウを 記憶した位置に動かす様に CabwcPos を作ったのですが いつも同じ位置で なければいけないと言う訳でもなく何となく並んで 両方見えれば良いと言う用途の方が多い様な気がします。ウィンドウを つかんで動かせば CabwcPos はそれを記憶するので記憶数はあまり記憶する必要の無い ウィンドウでもどんどん増えて いきます。そんな事を考えると 記憶していないフォルダーウィンドウを開いた時にも 記憶はしなくても他のウィンドウと 重ならない様に動かせば足りて ただ動かすだけ そんな機能も必要なのかなと考え始めています。

エクスプローラーの 表示 設定 フォルダー オプション 表示タブのフォルダーとデスクトップの項目の説明を ポップアップで表示する に チェックを入れると 出る ファイル フォルダーの ポップアップ表示はコラムを網羅して  意外に詳しく 此を テキストで取得すると結構便利です。ただ ここに来て テクニカル インフォメーション に書いた様な事に気がつきました。テキスト利用に不便なので 最初に GetTipTx から対応していこうと思います。

此処 ソフトの小物たち で公開している プログラムは 以前からのしがらみと 64 bit ビルド 環境が無い為に全て 32 bit いわゆる x86 プログラムです。此は 別に 64bit ウィンドウには WOW64 と言う物が用意されているので 特に プログラム自身の 動作はそれで完結する物は全く問題は有りません。ただ 中には 相手に何かする 相手を 調べる とか言う動作をする プログラムも何個かは有ります。
此までは 何となく動いているから良いかと言う所で過ごしていましたが 相手が 64bit (x64) 動作だと自分が 落ちるのではなく 相手を落としてしまう事が有るのが解りました。現在殆どの 方の環境は 64bit(x64)ウィンドウ 環境だと思われるので 此の不具合は嬉しくないので これからは 相手と関わるソフトは 相手にするプログラムは 32bit or 64bit を確認してプログラムをする事も必要なのだろうなと考えています。

Windows 10 Ver 1809 で予め用意されていたり 使用した後 デスクトップに残っている 見えないウィンドウの扱いが 今の所 此で良いでしょう と言う所で 解決しました。これらのウィンドウは システムスタイル的には Visible ( 可視 ) ですが実際は見えずに覆っている感覚の物です。( 何かを描かれる前は 透けていて マウス動作も キー入力も受け 付けない ウィンドウです。) したがって 此までの様に 親ウィンドウだけの Visible or Invisible で判断出来ない ので 多少コードを加えて 子ウィンドウのスタイルも加味して判断する事にしました。
デスクトップの表示も此までの様に ウィンドウ自体のオーバーラップからある種の画像ソフトの持つレーヤー構造に して表示して行くのかなとそんな気がしています。現在の所 気がついた所では システムの設定ウィンドウと ブラウザーの Edje が主な物ですが 私は Edje は使用していないので どちらかと言うと迷惑な話です。

Windows 10 Ver 1809 を本格運用しだしました。何となくシステムドライブの占有サイズが減ったのは良かったのですが 削られた物も有りそうです。
デスクトップの様子も 変わった様です。ApplicationFrameWindow クラスという 設定ウィンドウや Ms Edje 等の枠になる ウィンドウが 必要の無い時も余分にしゃしゃり出る と言うか 使用後にも残す事に した様です。此の辺りの挙動は これから確認していかなければならないと思いますが とりあえず TaskMuEx から選択しても 反応のない意味の 無い ウィンドウは除く事にしました。ただ 今の所の確認では メニューに必要のない物を除く決定打を思いつきません。
興味のある方は プログラムティップス に有る GetWinCnst で調べればデスクトップにも結構余分な物が有る 事が解ると思います。
[ 12 月 05 日 ] 使用しないで 用意されていたり 使用した後 残っている ApplicationFrameWindow クラス の挙動が だんだん解ってきて デスクトップメニューに必要の無いアイテムは 次回のアップデートから排除できそうです。

本来なら とうの昔にしていなければいけなかったのですが 何となく問題が無いので良いか という事で 済ませていなかった ClasTitl の内部的な取得動作を UniCode 化 しました。クラス名は多分 ユニコード化 しなくても 特に問題はなさそうですが タイトルについてはそろそろ ANSI では対応出来ない物が有るかもしれません。 どちらにしても ユニコードで取得して ユニコードテキストで代入するので基本的な無駄は有りません。

本日 非常に短いタイミングで BwFwButn をアップしました。何となく アクティブ インアクティブ 又 そのタイトルバーの 色とかの動きがはっきりしないので コードを眺めたり メッセージに 余裕を持たせたり していると テクニカルインフォーメーション に書いた様な事に気がつきました。
殆ど 此で モヤモヤしている事も解決して コードも あまり効果のなさそうだった余分な物も無くなり 意識して待つ時の  待機ループをしっかりして 若干ですが システムへのコールも少なくなり動きも 良く確実になりました。 久しぶりの アイディア変更のヒットです。

此までも 考えていた事ですが 各 Windows のインストールされている言語に関係なく プログラムや メニューに表示される 文字が 文字化けしない ソフトが良いのではないかと考えて 何個かのソフトは メニューや 表示されるテキストは 出来るだけ 全て ASCII 文字で表示しようとした物もありました。
こうすると 結局は 表示言語は全般的に大多数の人が解る 英語 ( English ) と言う事になってしまい 結局日本で使うのは 不便になってしまうと言うジレンマが起こってしまいます。一部のソフトは 此の文字部分を Language ファイルにして 全ての言語が表示出来る様にした物もありますが 此処 ソフトの小物たち でこの様に扱うにはサイズも 効率も そぐ合わない 感じです。
そんな訳で 日本語の文字列を指定してギチギチに最適化していたのですが 今回 他からのリクエストで 英語表記にして 欲しいとの要請がありまして ( リクエストをされた方は 英語圏の人ではありません ) 確かに 英語表記の ASCII 文字だけに しておけば 一応どんな言語の方も使用できる と言う事で SubFolder 英語版を作りました。ただ プログラムを 英語表記に するのはたいした手間でもなく 自分で使用しても違和感なく使用は出来るのですが 他の人が使用するのは 説明テキスト と  ヘルプを 変えなけれいけません。( 変えなくても一応は使用は出来ますが ) こちらは 英語のプロではないので  この英訳は大変 手間がかかります。又 ホームページも 一応は英語説明版を用意したい所です。まあ自分の出来る所で ゆっくりと 誰にもお勧めソフトから変えて行きたいと思いますが 英語版リクエストが SubFolder なのは割と鋭い所を突いて きたかなと思ったりします。

新しく開かれるフォルダー表示ウィンドウ ( エクスプローラー ) を 此が アクティブになる前 表示される以前に ( まだ 見えない時点で ) 捉えられる方法が新たに解りました。此の為 08/15 日の CabwcPos より 16 〜 180ms 程度 早く準備が 出来る様になり サイズの調整と 位置の移動での ちらつきが 大幅に軽減できました。
だいぶ早い時点で 認識出来る様になったので デスクトップの変化検出の 頻度を下げる事も出来て 若干ですがプログラムの システムへの付加も減ったのではないかと思います。( 最初からそれ程有る訳ではないのでたいした事は有りません。) とりあえず 此で安定して長く使用できるのではないかと思っています。

Windows の予め持っている Hook 機能は 32bit プログラムHookは 64bit プログラムの Hook は出来ない事が解りました。 したがって CabwcPos は 64bit プログラムには無力で 同時に 64bit Windows のエクスプローラーにも 無力なのが解りました。( 64bit Windows 環境のシステムには働かない。32bit プログラムには反応する。)
此では あまりに不便で 不備なので Hook プログラムはやめて 全ての環境 全てのプログラムで 反応する様に自前の デスクトップ変化検知コードに変えました。とは言っても タイマーと マウスのボタンや動きを組み合わせて  Hook の時と同じメッセージを作り出しているだけですが 自前だけに 調整と 扱いは 楽になりましたが 変化した結果の 検知ですから Hook の反応速度には及びません。
反応は遅くなりましたが 全ての プログラム Windows で安定して動く様になりました。

殆ど周回遅れの様な感じもありますが メイン使用の PC の１つを 64bit Windows にしました。これまでは動く事だけを テストしてきましたが 常用使用になれば何かと もっと細かく気がついた所まで詰める事が出来るだろうと思います。
これまで通り 作成プログラムは 32bit版ですが より 両方の環境に適合した物を作成出来るのではないかと考えています。

割と最近気がついて プログラミングティップス にも書いたメッセージキューの取得順序を意識してメッセージ取得ループに 手を加えると 何個かのプログラムは 予想した期待通りの結果と 動きがスムースになる事が解りました。もちろん通常通りの 此までのメッセージ取得ループでも全く問題の無い物の方が多いのですが サンプルに有る様な典型的なメッセージ取得ループは プログラムがどういう動きをするかによって変えていかないといけない様です。
結局 この辺の事も MSDN にも書いて有ったのですが よく読まないといけないと言うことでしょうか。

今更 こんな事が起こるなんて と思ったのですが ウィンドウの特別なフォルダーを求める API で SHGetSpecialFolderPath と 言うのが有って結構以前から ( 殆ど Win 98 の時から使用しているのですが ) 私の インストールした Visual Studio 6.0 の MSDN ライブラリ Visual Studio 6.0 では この関数について WINSHELLAPI HRESULT WINAPI SHGetSpecialFolderPath (・・・  Returns NOERROR if successful, or an OLE-defined error result otherwise. ( NOERROR = 0 ) と書いてあり 此を信じて コーディングをしてきたのですが 何か結果が おかしいので この部分は結構独自の 成功 失敗 判断をコーディングしていた のですが ふと ネットで API SHGetSpecialFolderPath を調べてみると MSDN - Microsoft に BOOL SHGetSpecialFolderPath   TRUE if successful; otherwise, FALSE. と書いて有るではないですか。此では Returns NOERROR if successful, と全く逆で 今まで 何となく 結果がおかしかったのも 納得でこの部分をシンプルにすると結構すっぃりします。やはりおかしい時は いろいろな 情報を集める方が良いのでしょう。とりあえず 此までのコーディングでも   間違いは出ないのですが おかしい物を残しておくのも気持ちがすっきりしないので 気の付いた出来る物から修正して行こうかと 思います。

タスクトレイアイコンの置き場所での機能の違いをちょっと テクニカルインフォーメーション に書きました。
GetWinTx も マウスカーソル位置判定の HitTest 関連で 確認の為 1年半程前のコードをそのまま何もせずにビルトしてみると Defender に Trojan:Win32/Fuery.B!cl と判定されて 一挙に削除されてしまいました。Defender の判定基準も日々進歩して 厳しくなっているのを実感します。この辺の所は プログラミングティップ に も書いた事が関連していて クロ とされてもおかしくは無いのですが ( 本当は Defender が おかしい。) とりあえずは Defender の 除外リストに入れて使用するかな とも思いましたが クロと判定されて削除された物を除外リストに入れるのは 意外とたいへんです。ましてや他の人に配布して使用してもらう物が Defender でクロ判定はいかにもまずい感じです。
GetWinTx も 必要な所を 適切なコードに変えてビルドしたのですが やはりクロ判定でした。じっとコードを見ていると 結構大きなブロックを先にした方が場合の割合で無駄が無くなり 効率が良さそうな所が有ってこの部分の順序を変えたら  なんと シロ判定になりました。此を調整して アップしようかと思っています。ただ順序を変えただけで クロ←→シロが 変わっただけですから やはり 判定の定義が変われば 又 クロになるかもしてません。 ( Google の巡回ロボット の シロ クロ 判定と 同じ事です。) シロ 判定でも 特に最初の立ち上げの時には Defender が  ああでも無い こうでも無いと 考えているらしく 2〜3秒 ぐらいかかり どちらにしても かなり疑われいるのは 間違いありません。

本日の OnScroll も 05/25 の CabULCmu も同様ですが 左上の アイコン部分を右クリックすると出る ULC メニュー ですが 右上の アイコン部分を認識する方法を効率の良く正確な物に変えました。この辺の所をプログラムチップの マウスカーソル位置判定の HitTest に書きました。
考え方は応用が利き 他にも転用できそうなので 何らかの機会が有れば利用していきたいと思います。

CabwcPos のフォルダー 位置 サイズの記憶タイミングを テクニカル インフォメーション に書いた様に変えました。 此により 記憶バッファの無駄遣いが無くなり 検索の効率も良くなるかと思います。今までの記憶が澱の様に溜まっていると 考える方は一度リセットしてしまうのも 手かもしれません。

BwFwButn の バーチャル キーコード出力に コード 1 2 4 でマウスボタン L R M ボタンクリックを出力をする様に  改良しました。此で ある種の マウスドライバーの様に ミドルボタンや サイドボタンに W クリックを割り当てる事が 出来る様になりました。
又 メニューが出る前の位置に マウスカーソルを 移動してから始める /CP を 内部コマンドに加えたので メニューからと マウスボタンにアサインした動作の齟齬を埋める事が出来る様になり 始める時にマウスカーソル位置が問題になるソフト等 使い方によっては コマンドの利用範囲を広げる事が出来る様になりました。

ExecSlct は メニュー型ランチャーとしては スタートメニュー代わりにもなるし SendTo において実行ファイルを 切り替えるのにも非常に便利な物だと思います。ただ メニューの体裁を整える為のテキストファイルのハードルが 若干高い所は一度作ってしまえば済む事ですが 各メニューアイテムに表示するアイコンの取得はメニューポップ アップの オンデマンド取得で 行っていたので 最初の立ち上げでは その都度 実行ファイル等から取得する事になり  Windows Defender やら ビールス検知ソフトで いちいち指定ファイルを 調べられてしまう事になり 此のアイコン取得で メニューの 描画に時間がかかってしまいます。
此をなるべく解消する為に メニューを教示するルーティンと平行して 各メニュー描画用のアイコンだけを取得する ルーティンを別スレッドで専用に廻す事にしました。こうする事で メニューポップアップの オンデマンド取得より 先回りして取得できる様になり だいぶイライラが減りました。ただし 規模の大きなスタートメニュー等ではメニュー アイテムは 300個を超える事も有るでしょうから Windows が立ち上がった当初の時にはメニューの一番後の方の アイコン取得は まだ間に合っておらずに ポップアップの オンデマンド取得 になる事も有りますが 次回の使用時には 全てのアイコンを取得していますから かなり軽快に使用できる様になりました。

此処にある 他のプログラムと関連して働くソフトは多かれ少なかれデスクトップの大体最上位にあるにあるタスクバー (クラス名:"Shell_TrayWnd")と 最下位に有るプログラムマネージャー (クラス名:"Progman") を認識して (ウィンドウ ハンドルを取得して) 動いています。
此までは立ち上がる時に 何らかの機会を捉えて 此の２つのウィンドウハンドルを取得して 変わらない前提で いたのですが テクニカル インフォメーション に詳しく書きましたが 此からは タスクバー プログラムマネージャー の ウィンドウハンドルが変わる事も有るので 有効かどうか確認する作業をするコードを付加して行こうかと思います。

テクニカル インフォメーション に書いた様な事情で ClipSaver のクリップボード取得のタイミングと クリップボードに代入して投げ出すタイミングを 現在の実情に合う様に変えました。考えて見れば今までのタイミングは 2004 年ぐらいから変わっていませんでした。又 この時の 相手にしていた プログラムは Office 2000 の ワードですから ずいぶん反応の悪い物を相手にタイミングを決めていた事になります。
全体的には 反応は良くなったのですが ひょっとしたら速すぎる所もでてしまうかもしれません。ただ 速いキーボード 入力でも取りこぼす事は無いと思います。

Windows 8 もついに延長サポートフェイズに入るそうで Window 7 に至っては 延長サポートフェイズも 残す所 2年を切った そうです。いつの間にそんなに時間が と思ったりしますが Window 7 は延長サポートフェイズが 残す所 2年をと 言う事で Windows 7 で使用していた ノートの OS を Windows 10 メインに切り替えるべく 昨年の秋の Update をかけて 環境を整えました。昔から Windows 7 Windows 8.1 で使用していた パソコンは 常に ←→ Windows 10 とシステムを 行き来出来る様にしていましたが と言うか 考えたら使用しているパソコンは 全て Windows 10 に無償アップグレード した物で Windows 10 そのものは一度も購入していないのです。それで過去のシステムパーティションの Image ファイルと Windows 10 の Image ファイルとを 適宜切り替えて行き来していたのですが もうそれも必要ないかな と思っています。
後は プログラムの 検証用に Windows 7 環境も必要なのですが 此は 立ち上げ用の HD ( SSD ) を差し替える事で対処 出来るので 此には たいした時間はかかりません。ただ 全体的には Windows 7 より Windows 10 の方が若干重いので 古い ノート PC ( 2009年製 ) は全体的に遅くなるのは 致し方有りません。

Windows 10 を使用していて 結構違和感が有って なんとかしたいと思っていた ファイルのコピー等と ユーザーアカウント制御 の 確認ダイアログ のソフトの立ち上げ後のアクティブウィンドウの状況等を自分なりに ある程度は修正できたと思う CabwcPos を アップしました。 此の辺りの詳しい事は ウィンドウズ ８ 10 対応コードへの プログラムチップ に書きました。
ここの所 Windows 7 からアップした物も Windows 8 から Windows 10 にアップした物も殆ど 元に戻す事無く  大半の時間を Windows 10 上だけで過ごしているので 余計に 今までとの 挙動の違いが気になるのかもしれません。