[テクニカル インフォメーション ]

最終更新日 2024/04/15
　 プログラムを書いていて考えた事や 諸々の事を書いていきたいと思います。
　　　 ＊ 2024/04/15 各々の Program での コマンドラインの受け取り方。
　　　 ＊ 2024/01/25 *.inf ( インストールファイル ) でのインストール。
　　　 ＊ 2023/03/20 縦に並ぶメニューの数。
　　　 ＊ 2022/11/10 他のウィンドウの持つテキストを取得するプログラム。
　　　 ＊ 2022/10/15 Windows11 のタブファイルエクスプローラー。
　　　 ＊ 2022/08/10 プログラム開発環境のプラス。
　　　 ＊ 2022/06/25 マウスカーソル下のウィンドウ。
　　　 ＊ 2021/11/05 メニュー 選択 決定の マウス 右 ボタン。
　　　 ＊ 2021/10/25 デスクトップに残るキー出力。
　　　 ＊ 2021/08/10 メニューのカラム。
　　　 ＊ 2021/07/25 マウスボタンのチャタリングについて。[2021/12/15 追記]
　　　 ＊ 2021/03/01 Windows 10 デスクトップ上の見えないタスク。
　　　 ＊ 2020/10/20 マウススクロールホイールについて。
　　　 ＊ 2020/08/25 プロセス ( プログラム ) と 日本語 IME について。
　　　 ＊ 2020/08/01 日本語 IME デスクトップの 言語バー について。
　　　 ＊ 2020/05/10 マルチ ディスプレー 対応にについて。
　　　 ＊ 2020/03/05 BwFwButn 等の コマンド行 について。
　　　 ＊ 2019/11/30 MessageBox API について。
　　　 ＊ 2019/09/20 フォームを表示しないプログラムについて。
　　　 ＊ 2019/06/15 Windows 10 で新設された テキストサイズ 拡大機能について。
　　　 ＊ 2019/06/05 JPG ファイルの Exif データ と 更新時間 について。
　　　 ＊ 2019/01/10 エクスプローラーの ファイル フォルダーの ポップアップ表示について。
　　　 ＊ 2018/10/05 マウスボタンイベントドリブンプログラムについて。
　　　 ＊ 2018/06/10 タスクバーに表示するアイコンについて。
　　　 ＊ 2018/05/30 マウスカーソルの ウィンドウ位置について。
　　　 ＊ 2018/05/10 CabwcPos のフォルダー位置記憶タイミングについて。
　　　 ＊ 2018/03/05 タスクバー プログラムマネージャー のウィンドウハンドルについて。
　　　 ＊ 2018/02/20 ソフト ( プログラム ) のバージョンアップについて。
　　　 ＊ 2017/12/20 ClipName 終了時のメモリーエラーダイアログの可能性について。
　　　 ＊ 2017/08/30 タスクトレイにアイコンを表示するプログラムについて。
　　　 ＊ 2017/03/25 エクスプローラーのタイトルバー表示される文字数について。
　　　 ＊ 2017/02/25 CabwcPos の Hook 機能について。
　　　 ＊ 2017/02/05 ボタンに移動 の機能について。
　　　 ＊ 2016/09/25 プログラムのユニコード化について。
　　　 ＊ 2016/08/30 32ビット整数値の限界。
　　　 ＊ 2016/08/25 Windows 10 の ウィンドウ枠について。
　　　 ＊ 2016/04/20 SHBrowseForFolder API について。
　　　 ＊ 2016/04/10 ShellExecuteEx API について。
　　　 ＊ 2016/03/25 ファイル時間について。
　　　 ＊ 2015/09/25 Windows 10 での *.HLP ファイル。
　　　 ＊ 2015/08/20 4 行で作る スタートメニュー。
　　　 ＊ 2015/07/25 スタートメニュー作成用 ExecMenu について。
　　　 ＊ 2015/05/25 DPI スケーリング について。
　　　 ＊ 2015/02/25 フォルダー表示の 左上アイコンのコンテキストメニューについて。
　　　 ＊ 2015/01/30 ファイル フォルダーの 更新 作成 日時参照 について。
　　　 ＊ 2014/12/20 フォルダーの 作成 更新 参照 ( アクセス ) 日時 について。
　　　 ＊ 2014/08/25 説明テキストで使用している排他的トグル動作について。
　　　 ＊ 2014/08/11 立ち上げ時から管理者権限で立ち上げるには。
　　　 ＊ 2014/05/10 クラス名とタイトルの指定方法について。
　　　 ＊ 2014/04/10 ドライブの準備時間 について。
　　　 ＊ 2014/03/02 CabwcPos Ver.1.200 について。
　　　 ＊ 2014/01/20 Vista から 導入された UAC について。
　　　 ＊ 2013/11/15 アクティブなウィンドウのマウスホイールでのスクロールについて。
　　　 ＊ 2013/10/20 インアクティブウィンドウでのマウススクロールホイール使用について。
　　　 ＊ 2013/09/30 Win XP からサポートの HID スタックから直接読み取りについて。
　　　 ＊ 2013/08/25 パソコンのオーディオボリュームコントロールについて。
　　　 ＊ 2013/06/25 自分がフォアグランドにならない動作について。
　　　 ＊ 2013/06/01 デスクトップに新しく作成表示されるウィンドウについて。
　　　 ＊ 2013/05/05 ドライブを指定して USB 接続機器をディスコネクトする 機能について。
　　　 ＊ 2013/04/02 立ち上がる時にアクティブウィンドウを参照するプログラムについて。
　　　 ＊ 2013/03/02 マウスのサイドボタンに任意のプログラムを割り振る BwFwHook について。
　　　 ＊ 2013/02/09 SbFolder の Windows 8 でのメニュー表示色対応について。
　　　 ＊ 2013/01/30 Windows 8 の USBメモリー等の安全な取り外しについて。
　　　 ＊ 2012/11/27 Windows 95 / 98 / ME の 送る からの コマンドライン対応について。
　　　 ＊ 2012/10/18 の ClipName 3.300 からの インストールファイル *.INF ( セットアップ情報 ) について。
　　　 ＊ 2012/08/31 子ウィンドウとしてのコントロールのサブクラス化について。
　　　 ＊ 2012/01/17 ファイル名として認められない文字を使用した URL ファイルについて。
　　　 ＊ 2011/11/08 からの インストールファイル *.INF ( セットアップ情報 ) について。 ( 2012/10/03 追記 )
　　　 ＊ 2011/09/10 本日 アップした ExecSlct について。
　　　 ＊ 2011/09/05 ClipSaver 用 リスト保存ファイルにパスワードを設定出来る様にした事について。
　　　 ＊ 2011/05/16 配布アーカイバ形式を ZIP 形式に変更した事について。
　　　 ＊ 2010/12/12 他のプログラムをクリップボードをコマンドラインにして立ち上げられるプログラムについて。
　　　 ＊ 2010/02/20 ドライブを列挙するプログラムについて。
　　　 ＊ 2010 年からのWindows 2000 検証について。
　　　 ＊ 06/03 2009 SbFolder の キーボード操作対応について
　　　 ＊ 04/01 2009 プログラムのリンク オプション 変更について
　　　 ＊ 08/13 2008 SbFolder について
　　　 ＊ 07/13 2008 GetWinTx について
　　　 ＊ 10/20 2007 ClipName.DLL の Date Time について
　　　 ＊ 05/08 2007 ClipSaver の ，；， 以降を代入　の設定オプションについて
　　　 ＊ 04/18 2007 ファイル ( フォルダー ) を メニューにして表示するプログラムについて
　　　 ＊ 12/13/2005 常駐型 プログラムについて
　　　 ＊ 05/14/2005 応答のない ( ハングアップした ) プログラムへの対応について
　　　 ＊ 01/18/2005 プログラムのコマンドライン について
　　　 ＊ 12/26/2004 SetDetail CabFixer OnlyDetl の アップについて
　　　＊ 10/28/2003 ClipSaver.DLL Ver 1.200 の機能拡張 と サイズ に ついて
　　　＊ 05/17/2003 K_Launch Ver 2.1000 について
　　　＊ 05/07/2003 DIalUpDs Ver 1. 020 について
　　　＊ 04/15/2003 SbFolder 2.303 に関しての コンパイルオプション について
　　　＊ 06/28/2002 ターゲット Window の アクティベート色について
　　　＊ 03/06/2002 SbFolder の リアルタイムメニュー変更に関して
　　　 ＊ 10/01/2001 ClipName の 複数選択時の 右コンテキストメニューについて
　　　＊ 09/14 2001 SbFolder の 左利き用 Reverse M Botton バージョンについて
　　　＊ 07/23/2001 からのクリップボードに書き込む全てのプログラム バージョンアップについて
　　　＊ 04/29/2001 ExitWndw について
　　　＊ 01/19/2001 ClipSaver Version Up について
　　　＊ 12/01/2000 SetDetail CabFixer & SbFolder Version Up について
　　　＊ 11/16/2000 11/10 前後のプログラム Version Up について
　　　＊ 08/04/2000 SetDetail の改訂について
　　　＊ 06/02/2000 SbFolder 2.04
　　　＊ 02/24/2000 ClipSaver 2.14 について

　　＊ 2024/04/15 各々の Program での コマンドラインの受け取り方。 
此も今更ながらなのですが 色々なソフトを使用していると 立ち上げの時に指定するコマンドラインの 解釈が 制作者によって当然の事ながら違う事に気がつきます。
例えば ファイル フォルダー指定をコマンドラインで受け付けるソフトでも１つしか受け付けない物 複数受け付ける物 複数入れるとおかしな解釈になる物とか 此の辺りは一応の全体的な基準は有るのでしょうが プログラムをコーディング する人により前提条件 考え方が違い まちまちになって来てしまう様です。
通常なら 自分自身の為だけに コマンドラインの解釈をすればいいのですが 本日 アップデートした ExecSlct の様に 他のプログラムに 指定されたコマンドラインを渡すと言うプログラムは結構汎用的な(一般的な)方法を使用しないと いけないのかなと思います。それでも 全てのプログラムの立ち上げ時に通用するコマンドラインの与え方は 無いかと思うのでその都度の確認は必要な事なのでしょう。

　　＊ 2024/01/25 *.inf ( インストールファイル ) でのインストール。 
此処に有るソフトで *.inf ( インストールファイル ) で Registory に関連付けて作動するソフトが何個か有ります。 *.inf でのインストールは比較的簡単で効率の良い物だと思っています。
今回 二年ぶりぐらいに *.inf ファイルを確認して見ましたが なぜか Windows64 環境では インストール出来て関連付けも 出来るのに コントロール パネル プログラムと機能 から アンインストール出来ない事が解りました。( Windows 10 32bit  環境では OK ) Windows 11 64Bit 環境では アンインストール出来ずに 関連付けが残ってしまいます。此まで *.inf での インストールは Win 32 Win 64 で確認してきましたが アンインストールは Win 32 でしか確認してこなかったのが原因です。
良く *.inf ファイルを 見て確認して見ると インストールセクションの [DefaultInstall.ntx86] ; は有るのに (Win32 Data )
[DefaultInstall.ntamd64] ; は無い事に ( Win 64 Data ) 気がつきました。
此では Win 64 環境では UnInstall Data がなくて アンインストールが出来ません。気がつけば単純なミスですが 結構解決に 時間が掛かってしまいました。
その後 確認すると [DefaultInstall.ntx86] → [DefaultInstall.nt] とすれば ntamd64 は無くても良い事に気がつきました。 何の事は無い x86 を余分に付けていたのが問題だったので 後は x86を削っただけで後の動作は解決する事になりました。 ただ 殆どの *.inf ファイル自体は 結構前 ( 2年以上前 )に書かれて そのままになっている物が多かったので 改めて見直すと まだ ミスが散見されたので 纏めて修正しました。
これらの *.inf ( インストールファイル ) を修正した物を同梱して アップして行こうかと思いますが ソフトによってはアップデートも 必要が無い物も有りますが 新しく +.inf だけを差し替えた物を日付だけ変えて挙げて行くのが順当かなと 思っています。 ( アンインストールが出来ないのはどう考えてもまずいでしょう。)
とは 言っても アップデートが何時になるか 解らなくもないので それぞれ 関連した   *.inf ファイルを纏めた物 を アップしておきます。

　　＊ 2023/03/20 縦に並ぶメニューの数。
Windows 11 を使用しだして 一年以上経ちましたが やっと この表題 縦に並ぶメニューの数 に付いて多分 こうなんだろうと言う所を書ける様になりました。
此までの Win 98 〜 Win 10 までの所は 今まで通りの計算で間違っていなかったのですが Windows 11 に なってから なんか変だな と感じる所が有ってその都度調べて観ると やはり Windows 11 では変わって居る様です。
メニューを画面上で縦に並べて表示していくと画面からはみ出してしまい表示出来なくなると 上下に▲▼ が付いた メニューになり ▲▼ をクリックする事で上下を表示出来る所は同じですが Win 10 までは 表示出来るギリギリまで ▲▼ が付かないのに Windows 11 では まだ メニュー幅三個分の余裕の有る所から ▲▼ が付いてしまうようです。
そうすると 今まで通りに まだ並ぶ数まで重ねると Windows 11 では 上下に▲▼ が付いて扱いが悪くなってしまいます。 此は メニューが一列の場合の時で 二列 や 三列の メニュー ( Barbreak 付き ) の場合は Windows 11 でも 今まで 通りの数が表示され ▲▼ は付きません。
プログラム的には 多少やっかいな事になります。Windows の Version を観て コードを変える事は個人的な趣味で したくない所で １つのコードですべてのウィンドウをカバーする事を考えると一列のメニューでも 早めに二列にして ▲▼ は付きを押さえて 確実に二列以上の数が有る物に付いては 画面をフルに使用した 二列 ( Barbreak ) と言う 方法を取るのが良いだろうと考える様になりました。
二列以上の ( Barbreak 付き ) のメニューになりそうな物はこの ソフトの小物たち には結構有りまして いつもの様に 不都合が出る物や 違和感が有る物から 追々手を付けていこうかと思います。

　　＊ 2022/11/10 他のウィンドウの持つテキストを取得するプログラム。 
GetWinTx と ClipSaver.dll の持つ機能 他のウィンドウの持つテキストを取得するプログラム については Programing Tips にも書いていますが 他の ウィンドウの中のコントロール要素とデータのやり取りをするために 結構 トリッキーな 方法になっていて 此が Defender セキュリティーソフト や Google の巡回ロボット等の チェックに掛かって 何回か 痛い目に遭ってきました。( けっして 怪しい方法ではなく きちんとした Windows API Call を使用した物です。)
Windows 10 になり システムは 昔からのコントロールを使用した物も少なくなり 何よりも 32bit Control 部品 しか 対応が出来ていないので 64bit の コントロールを使用した物については取得出来ません。そんな事を考えると  TreeView とか SysListView とかの テキストを取得出来なくなるのは残念ですが これから先 共有メモリーを 確保して あまり取得出来ない 物のためにコードを裂くのもいかがな物かと考える様になりました。( プログラム的 には非常に面白いのですが )
したがって これから先は ウィンドウの持つ通常の方法で取得出来るテキストにターゲットを絞っていこうかと思います。ただし 共有メモリーを使用する プログラムの方が高度の方法ですから ソースコードは 両方を切り替えられる物を 残していこうかと考えています。

　　＊ 2022/10/15 Windows11 のタブファイルエクスプローラー。 
10/12 の Windows 11 Oct Update で遂に ファイルエクスプローラー にタブが付きました。これを止める 方法も無く このまま タブ形式の ウィンドウを認める方法が一番かと思います。( 大多数には Welcome でしょうから )
したがって この タブファイルエクスプローラー に対応しなければならない訳で 最初は 日頃から常用している BwFwButn CabwcPos 等の  CabinetWClass を対象にしているプログラムがうまく動作しなくて 不便でしたが 此処に有る SearchWin や GetWinCnst を使用して 急いで Window構造を調べて なんとか普通に動かせる物が出来たので一安心しています。( そのうち 改訂アップしたいと思います。)
新しい タブファイルエクスプローラーの構造を調べてみると 結構苦労して タブ化している様です。そのためかどうかは解りませんが 一部分を除いては プログラム上の対応は殆ど違和感無しで OS 毎のバージョン切り替えコードも無く対応出来ました。( 細かい所はこれから 色々出てくるとは思いますが。)
私としては 常に オーバーラッピング状態で ウィンドウを使用しているので タブ付きの頭でっかちのファイルエクスプローラーは使用しにくい 所も有るのですが ( なんとなくタッチ操作方向に振って来ている様で ) 此が最新仕様なら使って行って 対応して行くのが正当でしょう。 希望的にはごく簡単な方法で ( ナビゲーションウィンドウを表示しないぐらいの所で ) タブをやめられると良いかな等と思います。 ( 本音を言えば タブウィンドウ は全ての場合に便利 と言う訳でも無く ファイルエクスプローラーではあまり歓迎したい物ではありません。) 
［ 10/20 の追記 ］タブファイルエクスプローラー になって ウィンドウのタイトルバーはタブに占領される事に なって 此の上部での NCAHITTEST ( 何処にマウスカーソルが有るかを表示する値 ) が全く通常のウィンドウと 変わってしまいました。何処に有っても HTCLIENT ( クライアント領域内 ) になって此の部分での NCAHITTEST が 使えなくなってしまいました。その代わりと 言っては何ですが 直下の 子ウィンドウが NCAHITTEST に答える様に なりました。子ウィンドウ が NCAHITTEST に対応する ?? ( 子ウィンドウ は通常 常に HTCLIENT です ) 又 不思議な 事に ウィンドウの範囲の中は ( 通常は HTCLIENT 範囲では ) 常に HTCAPTION ( タイトルバーの上 ) 範囲を超えても 超えた時の値 右下 とか 右横 とか ( 通常は範囲を超えた場合は HTNOWHERE 解らない です ) を出しています。
こうなると 今までの HTCLIENT は正確でなくなって使えません。MS 自身が こんな Windows の作法を破る事をして 良いのかなと言う感じです。まあ 新しいウィンドウは以前の構造を踏襲している物は少なくなってきていますが  長いスパンで観れば変わってもそれなりの対応をして行けば良いのかな と思います。

　　＊ 2022/08/10 プログラム開発環境のプラス。 
此処に有る プログラムは 新しい ウィンドウが 出ればそれに対応して 動作保証をして来ました。 此までは 動作保証をする プラットホームで C++ を 持って開発してきたのですが さすがに Windows 11 に なって 今まで 20年以上使用している Vis C++ 6.0 も インストール出来なくなってしまいました。
未だに VC++ 6.0 と言うのも 長く使いすぎかと思いますが 単に SKD を使った プログラムでは  コンパイル ビルト さえ出来れば良く 新しい API が出ても SKD 2008 等から include ファイルや lib ファイルを コピーして来れば 何とか使用出来てきました。
そんな 事で 私も Vis Studio 2008 等に変えようとしたのですが 何しろ ライセンス料が 高い と 言う事で Express 版も試したのですが リソースエディターは無いという事で さすが無償版で 此では使用出来ずに 此処 まで来てしまいました。
そんな 事で Windows 11 が出て 開発環境をと 思ったら Windows 11 には Vis Studio 6.0 は インストール 不可 になってしまいました。ひょっとすると Windows 10 でもダメだったのが Windows 8 7 からのしがらみ アップデートで使用出来きていたのかも知れません。
こんな状況でも 出来た プログラムは Windows 11 での検証は出来る訳で Windows 11 対応検証は問題 無かったのですが さすがに 検証環境と 開発環境が 違うのは不便になってきました。又 当たり前ですが  20年もすれば VC 6.0 では対応できない API Call も 出て来ています。
此の様な 事情で Windows 11 に 新しい 開発環境を インストールする事にしました。幸いな事に Ms の方からは  大盤振る舞いの Vis Studio Community が出て来ています。( もう 何年か前からですが ) 此は まさしく 大盤振る舞い で 私の様な細々と プログラムをしている物にとっては ありがたい仕様です。( 何十年か 前に 何万円か かけてライセンスを買った時とは 大きな違いです。)
そんな 事で Vis Studio Community を 新しい Windows 11 PC にインストールしました。どの年代の 物を インストールしようかと 思いましたが 年代と共にどんどん肥大化しているようです。ただ 過去の .dsw ( プロジェクトワークベース ) を変換出来るのは Vis Studio Comm 2019 までの様です。私にとって SKD に 沿って 単に コンパイル リンクが 出来れば良いので 年代はいつでも構わなかったので 取り敢えず Vis Studio 2017 をインストールしてみました。此によると 過去の .dsw が .slc ファイルに コンバート出来て 殆どの 場合 手直し無しで ビルド出来る様です。( さすがに トリッキーな設定で サイズを縮小した物は NG ですが )
色々比べて観ると 若干同じ事をする プログラムでも .exe サイズが 2割 ぐらい増加してしまう様です。ただ 今まで 出来なかった 新しい API の プログラムも 出来る様になった事は確かで 此まで発想はあったのに 開発環境で 出来なかった物が出来る様になったので そのうち 新しい 物も アップできるのでは ないかと 思っています。
同じ 事を するのに Vis Studio 6.0 と Vis Studio 2017 でサイズが違う物については ( スピードは全く問題に しません ) Vis Studio 6.0 の ビルドを アップする事にして Vis Studio 6.0 では ビルドが 出来ない物に ついては Vis Studio 2017 ビルドの物を アップすると 言う事にして 当分は 両方の 並列開発環境で行こう かなと 思っています。( 色々 試したのですが Vis Studio 2017 に 統一は現時点では メリットが 無いと 考えています。)

　　＊ 2022/06/25 マウスカーソル下のウィンドウ。 
プログラムをしていると関連するウィンドウを特定するために マウスカーソル下のウィンドウのウィンドウハンドルを 欲しい時があります。欲しい ウィンドウのハンドルはデスクトップに表示されているトップレベルウィンドウだったり マウスカーソル直下の子ウィンドウだったりします。
此までは デスクトップに表示されているトップレベルウィンドウなら Windows API の EnumWindows で Visible で 条件にある物を探す。( これは GetForeGroundWindow でも何とか探せますが ) もし 子ウィンドウなら カーソル ポジションから WindowFromPoint で直に探す。と言う様な使い分けをしていました。
ただ トップレベルウィンドウ だと Windows 10 デスク トップ上の見えないタスク。 の様なフィルターをかけなければなりません。此のフィルターは Window の デスクトップの様子が変わる度に変えなくてはなりません。
それでは API WindowFromPoint で探した時ですが よく見ていると デスクトップ上の見えないタスク は パス している のではないかと気が付きました。まあ Windows API ですから何らかのフィルターが予めかけた物で結果を出しているのでは ないかと思う様になりました。
その為 本日 同時に Programing Tips の中の SerchWin に新に 子ウィンドウから 上の Parent Window を トップレベル まで表示する機能を付加しました。結論を出すにはもう少し係りそうですが もし WindowFromPoint に ある種のフィルターが係っているのなら デスクトップの様子が変わる度に変えなくても 良い事になりそうです。

　　＊ 2021/11/05 メニュー 選択 決定の マウス 右ボタン。 
昔からのタイプのウィンドウズのタイトルバーの下に付いているメニュー ( ファイル とか 編集 とかの )は 出す時は左クリックで出た後も 余程の事が無い限り 決定は 左クリックです。
それでは タイトルバーの右クリックで出る 移動 終了 等のコンテキストメニューは 決定は 左クリックは  OK で認めますが 右クリックはどうでしょうか。昔からのタイプのウィンドウズのタイトルバー の物は 右クリックを認めますが エクスプローラーの タイトルバーの右クリックコンテキストメニュー では 移動 終了 等の メニューアイテムは同じですが 右クリック選択は認めません。なんだかちぐはぐな感じが します。確認し出せば 色々な所でのメニューが 右クリックでの決定がはっきりしません。まあ ソフトに よっては 左クリックは 決定で 右クリックでは特別な意味の有る事も有りますから一概には言えませんが 右クリック で何も無いなら 右クリックでの決定も認める方が整合性が有るのでは無いかと思います。 特に エクスプローラーの タイトルバーの右クリックコンテキストメニュー では右クリック選択での   X 閉じる(C)は認めない 仕様は理解に苦しむ所です。

　　＊ 2021/10/25 デスクトップに残るキー出力。 
デスクトップの操作をマウスだけで行っていれば マウスボタンでの選択や決定は大方ボタンアップなので 此の問題は出ないの ですが ショートカットキー や メニューのアクセスキー(アクセラレーションキー) 等を使用していると 此の動作は  殆どの場合 キーダウンで始まります。初期の反応は此でキビキビして良いのですが メニューを アクセスキーで選択すると メニューが消えてしまいます。まあ 消えたと同時に キーを離せば良いのですが 中には エクスプローラーのタイトルバー に出るシステムメニューを出して 閉じる を アクセスキー C で選択すると C を押した瞬間に メニューも消えてフォルダー 表示ウィンドウも消えます。そうなると 表示されていた フォルダー表示ウィンドウ の次の Z 順位のウィンドウがアクティブ になります。キー C のアップが遅れればアクティブになったウィンドウが C の入力を受けてしまします。
新に アクティブになった ウィンドウ( プログラム )の作りにもよるかと思いますが 何らかの影響を受けてしまうかも 知れません。此は C キー等の アクセスキーだけでなく ↑↓ で選択 Ent キーの場合も同様です。特にメニューが消えると 同時に ウィンドウフォームも消える様な場合と 最初からメニューだけのプログラムの場合もキーがアップになるまで アクティブを譲らない( 自身を Destroy しない ) で余分なキー出力を自分で吸収するとかのコードを用意して置くとか  逆に こういう時に Z 順位の順番で アクティブにされても 影響を受けない様に キーダウンが無い時には キー アップ動作 ( メッセージ )は 認めないとかの工夫も良いのかもしれません。
まあ それ程頻繁に起こる事でも無いのでしょうが Z 順位の順番で アクティブにされた時には 残りの キー 出力と キー アップ メッセージが来るかも知れない事を考えてプログラムをするのも 場合によっては必要ではないかと思います。

　　＊ 2021/08/10 メニューのカラム。 
マウスの右クリックで出るコンテキストメニューやフォームのメニューからのドロップダウンメニュー等は通常は 一列で( 一カラムで )上下に並んで表示されます。あまりない事ですが メニューアイテムが多くなって画面の上下 方向に入りきらなくなると 上には ▲ 下には ▼ がついて此を左クリックする事で下の方にスクロールする事で 見えない項目が見える様になって選択出来ます。( 此の仕様についてはクリックは必要無いのでは とか スクロール ホイールで動かせた方がとかの不満は有りますが仕様です。)
此の様なメニューの中で プログラムのファイルメニューの中に有る最近使ったファイル等は便利に使用出来る 物です。ただ通常は数の設定で16 とかに 制限されるので上下に ▲ ▼ が付く事は有りません。同じような ファイルメニューを 此処 ソフトの小物たち の ClipSaver や LHAComp WMFCopy もファイルメニューの中に ワークフォルダーの中の利用リストファイルを全て列挙してメニューを出します。ClipSaver で 179 *.csl LHAComp の *.LCQ は 91個ぐらい有ります。此を全てメニューにすれば 当然上下一列では画面からはみ出して 上下に ▲ ▼ が 付いてしまいます。此ではすぐに選択出来ないのと 見通しが悪いので画面に収まる数で カラムを変えて 又 並べ なおします。これぐらいの数だと特に表示上簡潔で問題はないのですが 此が任意のフォルダー以下をメニューにする SbFolder や SubFolder になると 全く以下の数の違う物も相手にする事になり Total 数をある程度制限しているとは 言っても場合によってはメニューだけで画面がいっぱいになり非常に使い勝手が悪い場合も出てきてしまいます。
此までは 基本 SbFolder SubFolder は 上下画面に入らない時には 次のカラム ( Multi Column, API 的には Menu Break ) で考えていましたが 上下に ▲ ▼ が付いている 一カラムの メニューの方が使い勝手が良い時が有るのでは無いかと 考える様になりました。もちろん 上には ▲ 下には ▼ がついて此を左クリック しないとスクロールしない仕様は プログラム で対応する事にして SubFolder SbFolder には 一カラム で表示する オプション SW を新設する事にしました。

　　＊ 2021/07/25 マウスボタンのチャタリングについて。 
常用している BwFwButn の動作がおかしくなってしまったので 何か間違った所が有ったかなと コードを調べていたら 動作的に サイドボタン の ON OFF が短い期間に何回か起こっている挙動の様だと推測がつきました。それで 確認の為の コードを入れた BwFwButn を立ち上げて見ると サイドボタン Down で 同じ時間内( 0ms )に Dwon Up Down  サイドボタン Up で Up Dwon Up がそれ程の頻度ではないのですが散見されました。 ( Windows の通常の経過時間取得は 0 16 32 ms ずつです。 ) 此は明らかに マウスサイドボタン SW のチャタリング 現象 です。BwFwButn はサイドボタンの Dwon Up 時間のタイミングで動作を切り替えているので 此の SW の チャタリング で 動作が 安定しない事が出てしまったようです。結構 良い マウスで SW はオムロン製と書いて有ったのに 経年変化で しょうか 少々残念です。ただ古い物でもう生産中止で発売もしていません。
ただ はっきりした確認は出来ないのですが 通常の Windows を使用するのにはそれ程不具合は感じていないので Windows の 使用している マウス関連の ドライバー API は SW の チャタリングは 折り込み済みなのかも知れません。
BwFwButn の様に HID マウスの動作を 直に WM_INPUT で取得しているから 此の チャタリングも 気が付いたのかも 知れません。とりあえずは マウスを換えたり 直したりする( サイドボタンを何回か強く ON OFF したら何となく 不具合 回数は減りました )よりは プログラム的に チャタリングを防ぐ コードを挿入する方が 簡単だし 安定性 汎用性も 高く なるだろうと思います。
　＊[2021/12/15 追記]　防止コードの最初は押されて短いインターバル(30ms以内とか)で離される事は無い と言う発想で 考えていましたが 此だと プログラム的に作られた mouse_event Down Up ( 0ms )に耐えられません。ご丁寧に WM_INPUT は此のイベントにも正直に反応してしまいます。もう一度 物理的な ボタンのチャタリング とはどういう現象か 考え直すと ON (Down) - (OFF (Up) ON (Down))----OF (Up) と言う事で ボタンの動作は ON--OFF が欲しい訳で 途中で出た パルス状の OFF ON のワンセットは無視したいイベントになります。
したがって 発想を変えて トリガーは OFF(Up) で 非常に短い時間に ON(Down) になる ワンセット は排除する事にしました。 此だと プログラム的に作られた mouse_event でも OK ですし ワンセット で排除するので ON-OFF の動作にも セットの矛盾が 無くなります。コードを工夫すると 2セットのパルス性のチャタリングにも対応出来るので 当分此かなと思います。

　　＊ 2021/03/01 Windows 10 デスクトップ上の見えないタスク。
Windows 10 で デスクトップ上で ウィンドウスタイルは Visible なのに 何故か見えないマウスでも 触る 事の出来ない タスク ( ウィンドウ ) が増えています。此は Windous 8 ぐらいから始まっていたと記憶して いるのですが 以前の様に ウィンドウを列挙して Visible の物を相手にすると言う単純な 考え方 ( コード )  では 効率が悪いだけでなく ターゲットのウィンドウを取り違えたりして 通用しなくなってきました。
そこで Programing Tips にも 書いた様な事を参考に ウィンドウの列挙をするプログラムは 予め タスク ( ウィンドウ ) の絞り込みを する事に しました。現在の状況では 思いついた フィルターコード ( 徐々に実装して行きます。) で絞り込める 筈ですが Windows 10 の機能が ( 余分なお世話や見場の良さ ) が増えるにしたがって デスクトップ上での見えない ウィンドウが増えていきそうです。したがって 此からも 余分な 常駐タスクが出て来るか見て 現在の  フィルターコードで OK かどうか確認していかなければ思います。

　　＊ 2020/10/20 マウススクロールホイールについて。
マウススクロールホイールについては 以前 にも書いていて この時は OnScroll について主に書きました。それ以降に Windows 10 が発表されてこの時からアクティブ ウィンドウでなくても マウスカーソルオーバーのウィンドウはスクロールホイールでスクロールさせる事が 出来る様になり大分使い勝手が良くなりました。アクティブで無いウィンドウでもスクロール出来る OnScroll も Windows 10 ではそれ程意味の無い物になりかけていましたが 横スクロールも出来るかも知れないと言う事で 全く 意味の無い物でも有りませんでした。
此の 間に 横スクロールの方はどうかと言うと だんだん横スクロールスイッチ( ホイールは無い )の付いた マウスも流行らなくて無くなって来ている様な気がします。 ウィンドウズ の方はどうかと言うと 一番使用するフォルダー表示ウィンドウ ( 所謂エクスプローラー )が マウスの横スクロール信号に対応していない様です。タスク マネージャーも同様に横スクロールしません。 ( さすがに IE や Edje はする様です。) 後 プログラム ソフトの 方の対応は まちまち の様で新しいソフトは きちんと 対応してきて居る様です。
そんな 事で 肝心の フォルダー表示ウィンドウ が 横スクロールしないとなると 此を横スクロールさせる 為には スクロールバーを掴んで移動するか △ボタンを押す事になる訳で 此のウィンドウはアクティブに なって 全面に出てきてしまいます。なんとかして インアクティブなままで 横スクロール させたいと考え 又 横スクロールボタンの無いマウス環境でも 使用したいと 言う事で OnScroll のコードをいじっている内に マウスカーソルの位置によってスクロールシグナルを切り替えて出してやれば実現出来る事に気が付きました。
一応 出来た物を確認すると エクスプローラー や タスク マネージャー は下の横スクロールバー上に マウスカーソルが有る時には 横スクロール ボタン ( SW ) で横スクロール出来る様になりました。又 付帯 コードで 下の横スクロールバー上にマウスカーソルが有る時には 縦方向のマウスホイールで 横スクロール 出来る様にもしました。( 残念ながら この時には 同時に縦スクロールもしてしまいますが。) これらの動作は 全く アクティブ インアクティブ は関係ありません。下にあるウィンドウでも影でスクロールさせる事が出来ます。 後 横スクロール ボタン ( SW ) が有る環境なら あまりしないかも知れませんが 縦スクロールバー上に マウスカーソルを置いて 横スクロール ボタンで縦スクロールを行う事も出来ます。( ホイールと違って 廻し続けなくても連続してスクロールさせる事が出来ます。)
横スクロール ボタン の無い環境でも スクロールホイール で横スクロールが出来るのは便利だろうと 思います。又 以前からと同様に 横スクロールについては 新しい横スクロールホイール信号と 古くから有る 横スクロール メッセージを送出しているので 新しい横スクロールホイール信号をサポートしていない ソフトも 横スクロールホイール( SW ) で横スクロールさせる事が出来る可能性が高くなります。
私も 全ての プログラムで試した訳ではないのですが マウスオーバー + スクロールホイール で ウィンドウをアクチブ にしなくても 縦 横 スクロールが出来るのは結構はまります。

　　＊ 2020/08/25 プロセス ( プログラム ) と 日本語 IME について。
ここの所 日本語 IME Control API をいじっていて気が付いたのですが プロセス ( プログラム ) によっては デフォールトの IME ウィンドウが最初から無い物が有るという事です。以前から ScrnOff や ExitWndw は パスワードをかける時に IME がらみの文字が入らない様に IME は OFF にしていたのですが MSDN IME の概要 では IME はプロセス スレッド 絡みで用意され ウィンドウが作られる時に デフォールトの IME ウィンドウが アサインされるとの事のようです。
ちなみに 此処にある GetWinCnst で 説明窓に IME と入れて Visible を外して 全体情報 を検索させれば 確かに プロセスの数ぐらいは Class:IME / Title:Default IME が見つかります。此を作成した ソフトも列挙され ますので どの プロセス ( プログラム ) の IME か解ります。ざっと流しても 35 ぐらいは有りそうです。
ただ プログラム ( ソフト ) によっては 全く文字入力の無い物も有りますし ScrnOff や ExitWndw の様 に IME 入力は邪魔で して欲しくないソフトも有ります。此までは 漫然とプログラム を作成する時に あまり IME の事を意識しないで始めていましたが IME 入力をしない ソフトは 最初に 私は IME は要りません と 宣言してから プログラム をスタートするのも無駄にならなくていいかもしれません。
最初に 私は IME は要りません と API で宣言するのは もちろん imm32.lib をリンクするのでその分の コードは 60bytes ぐらいは大きくなってしまうのですが 常駐してからのメモリー消費量は却って IME が ない分だけ減るようです。08/10 の ScrnOff は IME 禁止の代わりに IME 無しにしたのですが これから IME 無しを 積極的に進めるかは その時の ソフトの アップ状況かなと思います。
・[ P.S. 09/01 ] 何個かの ソフトで タスク マネージャーのメモリー常駐量を 確認してみると ソフトによって それ程 変わらない物 大きく変わる物がある事が確認出来ました。大きく変わる物は 3Mb → 0.8Mb と 1 / 3 以下に なる様な物も有り 結構大きな違いが出るようです。此だけ違うと 積極的に採用する価値も有るかと思います。 ただし 当たり前ですが ソフトは IME 入力 しない前提で 文字入力は無いか 入力しても アルファベット 数字  記号 に限られる訳ですから どちらにしても制限付きです。

　　＊ 2020/08/01 日本語 IME デスクトップの 言語バー について。
私は 日本語 IME は 此処 20年ぐらい ズーッと ATOK を使用してきました。Ms IME より アルファベット文字の 混じった ( 英単語 ) 文章を入力するのが便利なのと 直接入力( IME を介さない ) と IME を通した入力の判断が しやすかった事が有ります。( 変換効率が 良かったからと言う訳ではありません。)
特に ATOK には ATOK パレットがあって この設定が IME を使用しない時には デスクトップから消せる(無くす) 設定が有ったので キーボード直接アルファベット入力 IME ( ATOK ) を介した 日本語入力 の区別が付きやすく Ms IME の様に 今どうなっているの アルファベットを打ちたいんだけど と言う様な迷いが無かった事も 有ります。
ただ この所 Windows 10になってから ユニバーサルアプリ の仕様や Windows の設定ウィンドウが此に準拠して 来ると ATOK パレット を出す設定にしている ATOK では ( テキストサービスを使用しない 設定 ) これらの 入力には 使用できなくなっています。ATOK パレット を出す設定にしている ATOK では ( テキストサービスを使用しない ) さすがに不便になってきました。それで テキストサービスを使用する 設定にして 言語バーをデスクトップに表示する設定で 使用を始めましたがやはり 直接入力と IME 変換 入力の 区別が 付きにくく 不便です。
そこで いつもの事ながら 不便なら何とかしたいと考えて IME 関連の API を見ていると 何とかなりそうな  API が見つかりました。これらを組み合わせて確認してみると IME 入力をしない時には 言語バー を消して  IME 入力する時には 表示する事が出来る コードが何とか出来ました。細かい タイミングを取れば ATOK の  ATOK パレット の ON OFF の様に使用できそうです。
現在 持っている環境が Windows 10 環境だけ ( 32bit 64bit ) ですから 検証は それだけでしか出来ませんが 多分 使用している API は Windows 95 から新しくなった IME の物ですから Windows 10 以前の物にも対応出来ると 思います。もう少し 自分で使用して 動作確認して OK なら 新たに ソフト として アップしたいと思います。 旨く行けば まさしく ソフトの小物たち らしい ほんの小さな プログラムになるかと思います。
しかし 考えて見れば Ms が単に IME を使用しない直接入力の時には 言語バーを表示しない と言う オプションを 付加してくれれば こんなソフトは必要無い訳で 何かしない確固たる理由でもあるのでしょうか。まあ 付いて いないので ATOK が売れる事になるのかもしれません。

　　＊ 2020/05/10 マルチ ディスプレー 対応にについて。
此処にある プログラムは 私の環境がどれも シングルディスプレー環境なので 此までは マルチディスプレーに ついては あまり考えずに プログラムをして来ました。ただ 結構前から ノートパソコンとか Graphic カード とか M/B とかを見ていると 表示用 出力は DVI HDMI ディスプレイポート とか複数持つ物が多くなってきました。
確かに これらに 新しいディスプレーを繋げば Windows 10 環境なら 設定を少し 調整するだけで マルチ ディスプレー 環境が構築できる様です。
此処に有るソフトは シングルディスプレー 環境前提で プログラムをしていますから 自分がディスプレーから 消えてなくなるのを防止するため 他のディスプレーに移動できないとか 再立ち上げすると プライマリー ディスプレー に 戻ったりとか する物が有るはずです。もちろん プライマリーディスプレー の中だけで使用するのは何の問題も 無いのですがで マルチ ディスプレー環境の方は あまり面白い事ではないかと思います。
それで ユーザー様からの要請もあり 本質的に マルチ ディスプレー 対応を考えてコードを書いていくのが 本筋かなと思う様になりました。試しに マルチ ディスプレー 対応のコードでプログラムをしてみると それ程 難しい物ではないのですが 此までより コードサイズは 500bytes 程度増えるようです。 まあ殆どの場合は決め打ちの統一コードで対処できる様ですし 却って 今までよりも 表示画面に沿った はっきりした 判断コードになる事も解りました。
従って これ以降は 必要な物から マルチ ディスプレー 対応コードにして行きたいと思います。
2020/05/06 の トップページの [ ご協力をお願いします。 ] にも書いた様に 効率の良い コードを書く ために 確認したい所が有るので マルチモニター で PC を運用している方には MonitTst.zip をダウンロード 解凍して その中の MonitTst.exe を立ち上げて 結果を ( クリップボードに入ります。) 私に メールして下さると 大いに参考になり 助かります。宜しくお願いします。

　　＊ 2020/03/05 BwFwButn 等の コマンド行 について。
此処にある プログラムを立ち上げる BwFwButn K_Launch StartQut Scriptac 等 所謂 ランチャー系のプログラムは  その 立ち上げ動作を指定する コマンド + パラメータ + その他の指定 ( コマンドセット )を 一行の中に 入れ込んでいます。
(一般的な 名称では ないのですが コマンド + パラメータ + その他の指定 ( コマンドセット )の入った 行を 此処 では コマンド行とでも呼びたいと思います。)
そうすれば その行を 何行か 纏めれば マルチ コマンドランチャーになるからです。
Win + R で出る ファイル名を指定して実行 ダイアログの マルチ コマンド 版 の様な物です。コマンドセット の書式 ですが ただ 内部的に使用する物ですし 一行の中に 多い時では 5個の 指定が入るので 指定位置を間違えない様に  区切りとして Tab 区切りを使用する事にしています。( ファイル名を指定して実行 の区切りは Space です。)
自分で書いたコマンドセットの原稿だけを使用する時には 此で何の問題も無いのですが BwFwButn に限っては クリップボードを実行という内部コマンド /CB が 有ります。この時でも クリップボード の内容は Tab 区切りで と 強要しても良いのですが あまりに不便です。したがって BwFwButn に限っては
立ち上げコマンド + パラメーター 形式の コマンドセット に限って Space 区切りも認める様にしています。 ( 内部的に使用する コマンド行 書式も 此に準拠して認めています。) 此で ファイル名を指定して実行 ダイアログ の方式と同様に使用できます。ただ ファイル名を指定して実行 も そうですが 区切りが Space ですから C:\Program Files の様な  Space 付きの フォルダー名 や ファイル名 等は 自分で判断して区切るのは正確に出来るのですが ( 此の為に Tab  区切りを 原則にしているのですが ) 此を プログラム的に コマンド / パラメーター 位置を決めるのは 結構 工夫が 要るようです。
そんな 訳で 旨く行かない 事例が出てしまったので もう一度 コマンド と パラメーター の関係を考え直して 判断の重みを変えて まあ 大方満足出来る様になりました。ただ こちらを立てれば あちらが立たずの 事も 起こりうるので 再度 旨く行かない 事例が出れば 対処しなければ いけないのかと思います。( プログラム上で  全事例に対処するのは 結構 頭の体操です。)
ファイル名を指定して実行 ダイアログ でも旨く行かない時も有るので そんな所かとも思います。

　　＊ 2019/11/30 MessageBox API について。
この話は 若干 プログラムティップスにも 係るのですが それ程の量でも 複雑な事でもないので こちらに 書いておこうかと思います。
ウィンドウズの最初から用意している API に MessageBox が有ります。メッセージを表示してそこでプログラムは 停止して 情報や 警告やらを表示する (メッセージボックス)一番プリミティブで 使用しやすい UI を実現出来る  API です。結構汎用的にも使用できるし 色々な場合に使用できる様に UINT uType でメッセージボックスのタイプも 指定出来ます。此処 ソフトの小物たち にあるプログラムの大多数は Version 情報に此を使用しています。 ( なにせ 使用するのが非常に簡単です。)
ただ 制限事項も 当然有りまして 一番の制限は 警告や システムエラーを表示する為でしょうか 必ず画面の中央に 配置されます。又 此が出ると プログラムはそこで止まって( キーや マウス入力 が出来なくなりますが 内部的な メッセージは動いています。)しまいます。警告や システムエラーは 真ん中に表示されても良いのでしょうが 単なる 情報表示 等では 表示場所が真ん中ではそぐわない事も出てきます。MessageBoxEx API 等が有って 表示場所も指定出来ると良いのですが 残念ながら有りません。
此までにも 新たに出す時には 古い物を消すとか 何秒後には消すとかはしていたのですが 今回表示位置を指定出来る 方法 ( 指定出来ると言うよりは 表示される前に指定位置に移動する ) が見つかりましたので 情報表示 等の中央では あまりに違和感の有る メッセージボックス では適宜 表示場所を変える方法でプログラムしようかと思います。

　　＊ 2019/09/20 フォームを表示しないプログラムについて。
此処 ソフトの小物たち の中にあるプログラムの内 常駐するのにフォームを表示しない物 表示してもタイトルバー だけしか 表示しない物とか 結局フォームはどういう形でも有れば良いと言う物が 結構 有ります。
此は Windows プログラムなら メッセージを受け取って機能させる事になれば ある種のフォーム( Windows )を 作り 此で メッセージを受け取ったり メニューを出したりする事になる訳ですが この時フォームは見えなくても Windows の基本的な機能は使用出来て それなりに動かなければなりません。もちろん 見えないフォームですから 大きさも どうでも良く位置もどこに有ってもかまいませんし 見えなくても 前面に有って フォアグラウンドウィンドウにも なれるし キーボードフォーカスも持つ事が出来ます。メニューだけでのプログラムとか 何かのイベントを待って 機能するプログラムとかは 本質的に此の様なフォームを持っています。
此までは 此は此で 無駄も無いし 良いとは思っていたのですが 何かをする時に何らかの案内の様な( 所謂 ツール チップとか ツールヒント 的な ) 物が有った方が親切だったり 解りやすくなるのは事実です。 最初は ツールチップを付加しようと思いましたが ツールチップもひとつのウィンドウです。増設する無駄が出て しまいます。そこで 自分自身の見えないフォームを必要な時に適宜ツールチップの様に表示すればツールチップを 付加する無駄も無くなる事に気が付きました。
実際にコーディングをしてみるとなかなか小回りも利いて 便利な物になるのが解りました。今まではフォームを 作っても 表示にはあまり利用されなかった物が 結構便利に利用出来そうです。これからは 此の ツールチップ 擬きを 適宜 使用していこうかと思います。

　　＊ 2019/06/15 Windows 10 で新設された テキストサイズ 拡大機能について。
Windows 10 Ver.1809 からは、テキストサイズを以前よりも簡単に大きくなるよう変更できるようになりました。
此は 「設定」−「簡単操作」−「ディスプレイ」−「文字を大きくする」 の スライーダーで 以前の様に システム全体のスケーリング設定を変更することなく、テキストのサイズだけを大きくすることが 出来る仕様になりました。まあ 以前から 隠し機能として
HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics の
CaptionFont, IconFont, MenuFont, MessageFont, SmCaptionFont, StatusFont のサイズを 変える事で 各々調整が 出来たのが スライーダーで すぐに 調整できる様に 表に出した物だとは思いますが 便利にはなりました。
特に 高解像度ディスプレー では システムの表示文字が小さすぎて DPI を大きくしても スケーリングの 影響で ぼやけてしまったりするのを防ぐためには朗報だと思います。
ただ 此処 ソフトの小物たち に有るフォームを表示するプログラムは 以前の Windows の User Interface Font を 基準に サイズを決めていたので 新しいテキスト拡大とは齟齬が出てしまいます。そこで これ以降 フォームを 表示する プログラムは 徐々に 新しいテキストサイズを基準に表示していきたいと思います。 ( テキストサイズが大きくなればその分フォームも大きく表示されます。)
此だと 高解像度ディスプレー でも むやみに小さくならずに 表示出来る事になります。又 この方法で テキストを 大きくした時には むやみに 高DPI にしなくても良いので プログラムも DPI Aware を宣言をして 拡大を防止するより 個々の プロパティーからの 互換性タブ→高 DPI 設定の変更→高 DPI スケール設定の上書き から そのプログラム毎に 指定した方が良いのではないかと思う様になりました。 ( 大きく表示したい時には システムの 仮想スケーリングに任せて拡大してもらう 自由度が有った方が良いのかも しれないと考える様になりました。)
又 完全には把握していないのですが 新しい 1809 から 実際に表示している メニューの高さが場合によって 違ったり プログラムのサイズ調整に必要な API GetSystemMetrics の戻り値が以前と変わったりしてきているようです。 ただ 現在の様に ターゲットは 日頃から使用している Windows 10 最新版だけに絞れば良いと思うので 対応は却って 楽で 気の付いた 不都合の大きい所から 徐々に 対処して行けば 良いのかなと思っています。

　　＊ 2019/06/05 JPG ファイルの Exif データ と 更新時間 について。
現在は事ある度に デジカメ たら スマホで 写真を撮り記録に残します。それらは 自分のカメラで撮った物や  自分で撮っても スマホで撮ったり 他の人が カメラ スマホで撮ったりして 整理する時の 入手経路も 直に カードからコピーしたり メールに添付されて来た物を保存したりとか 色々です。
又 スマホの中では 閲覧したり データを 纏めたりすると 撮影画像をいじって 更新日時がその時間に変わって しまう事も有ります。もちろん ファイルの作成日時はコピ−した日付になってしまい参考にはなりません。
同じ フォルダーに 同じイベントの写真を纏めても ちょっと 整理軸がバラバラで 収集がつきにくくなってしまいます。 そんな事で 集まってきた写真 ( JPG ファイル ) を確認してみると殆どの写真には 意識して削除をされた時以外は  殆どの 場合 Exif ( 撮影条件に関する情報 メタデータ ）が付いている事が確認できました。
Exif データはの アイテムは 様々な 物が有りますが 中でも オリジナル撮影日時 と デジタル化日時 ( 殆ど同時刻だとは思いますが ) どちらかが有れば 此を元にして ファイルの 更新時刻 ( ついでに意味なく作成時刻も ) を合わせる事が出来ます。ファイルの 更新時刻 が撮影時刻に なれば 画像を 整理している フォルダーで 時間軸で整理する事が出来る様になります。
Exif データはのアイテムは種々有り 此を マニュアルで呼び出してセットする等は 当然不可能ですから 此の為だけに 新しい プログラム ExifTime を作成してみました。更新時間が正しく実時間にセットできれば 更新時間を ファイル名に 入れ込む事が出来る ソフト ( 此処 ソフトの小物たち では FileNOer が 更新時間を入れ込んだ ファイル名を 設定できます。) を使って ファイル名を変えれば 色々なソースからの写真を 朝から晩までのスライドショーを 順序だって 見る事も出来る様になります。

　　＊ 2019/01/10 エクスプローラーの ファイル フォルダーの ポップアップ表示について。
Windows 7 から フォルダー表示ウィンドウ 所謂 エクスプローラーの 構造が変わりまして メインで 表示している クラスが SysListView32 から DirectUIHWND と言うクラスになりました。DirectUIHWND は 新しいコントロールですから 他から利用する為のクラスの資料も無く したがって 此のコントロールの テキストを他から取得する事も出来ません。その代わりと言う訳ではないのでしょうが ファイル フォルダーの ポップアップ表示が 結構詳しくなり 殆どのコラムを改行して表示する様になりました。此なら 此処ソフトの 小物たち に有る GetTipTx で比較的 安全 簡単に取得可能です。
取得して テキストエディターに貼り付けて利用してみると おかしな事に気がつきました。( Windows 10 で それ 以前 Win 8 7 でも 同じですが。) ANSI ( S-JIS ) で取得すると ? ( 判別不能文字 ) が付く所が有り  例えば 更新日時: ?2015/?10/?29 ??14:34 の ? の所で UNICODE で取得するとどうも表示されない Character Code が ? の所にに入っているようです。 それで UTF-16 で保存した テキストファイルを Binary Editor で調べてみると Character Code 0x200E 0x200F  と言う Code が ? の所に入っていました。 UTＦ-16 では 0x2000〜0x200F は 文字コードアサインが無く 此では 表示出来ないし UTF-16→S-JIS 変換では ? に なってしまうのも 当然と言う感じです。何の為に 0x200E 0x200F が入っているのか不明ですが ( Ms としては内部的に 意味が有り何らかに使用しているのかもしれませんが ) とりあえず テキストとして取得して利用するには 迷惑以外 何の 意味もありませんから 此のコードは 除く方向で考えて行きたいと思います。何の 断りも無くバッサリ除いても かまわないのではないかとも思いましたが 最初は 選択肢の有る コマンドライン オプション SW 扱いかなと 思っています。

　　＊ 2018/10/05 マウスボタンイベントドリブンプログラムについて。
此処にある何個かのプログラムは Windows API RegisterRawInputDevices を 使い WM_INPUT メッセージを取得して  マウスボタンのダウンアップ 又は 動きの様子を Hook DLL 無しで取得しています。Windows XP からサポートになった 此の API ですが 扱いも楽で 何よりも マウスメッセージよりも速い 一番上流で捕らえられる所が重宝します。
此を 典型的に 使用したのが BwFwButn ですが 此は一種のランチャーですから 直前のアクティブウィンドウを覚えて いると 都合の良い事がずいぶん増えます。此の 直前のアクティブウィンドウを補足する為に定期的なタイマーで アクティブウィンドウを捉えていたのですが 今回 WM_INPUT メッセージ と BwFwButn の動きをを良く考えているうちに  定期的な アクティブウィンドウを補足する のは必要ない事に気がつきました。
BwFwButn はマウスの Fw Bw ボタン ( 場合によっては Rボタン ) のクリックがトリガーとなって動作しますが 動作 するのは 必ず ボタンが放された時です。押された時には単に後で押されていた時間を取得する為にただ現在の内部時間を 記憶するだけです。WM_INPUT メッセージ の マウスボタン の押されたと言う メッセージはシステムがデスクトップを 書き換える前に来るので この時点では アクティブウィンドウ は以前のままで 切り替わっていません。この後 どれぐらいで切り替わるかと計測してみると 16 ms ぐらい有れば切り替わる様です。したがって 16ms 以降に  アクティブウィンドウ を取得すれば マウスボタン の押された時にアクティブになった物 ( 当然 以前からアクティブ  だった物が 押された場合には 変わらずにアクティブです。) が取得出来ます。
それでは ボタンが 押されてから 離されるまでの時間はどれくらいかと計測してみると 意外と長くて どんなに頑張って 短いクリックを意識しても 90 ms を切るのは 難しい様です。
そうすると BwFwButn の様に マウスボタン がアップされる ( 離される ) のを受け取って何らかの動作をするプログラムは マウスボタン が押されて から 16ms 後に アクティブウィンドウを確認すれば 必ず アップされた ( 離された ) 時には アクティブウィンドウ のハンドル値は 現在の物で それ以上の余分な事は必要有りません。クリックの 押す 離す 時間は  最短 90 ms ですから コード上は 時間の余裕を見て 48 ms 後にアクティブウィンドウを確認しています。ただし此の話は  デスクトップ上でのクリックの話で タスクトレイアイコンの クリックでは常にタスクバーが アクティブウィンドウに なるのは 以前と全く同じ事です。

　　＊ 2018/06/10 タスクバーに表示するアイコンについて。
Winfows 10 からか ( もっと以前かも知れませんが ) タスクバーの設定から 通知領域 タスクバーに表示するアイコンを 選択します。とたどり 通知領域 タスクバーに表示するアイコンを選択 出来る様になり タスクバーの右下の方を すっきりさせる事が出来る様になりました。此は此で 良いのですが 隠した ( オフにした ) アイコンでもアクセス 出来る様に タスクバーに有る ∧ をクリックすると隠れているアイコンにアクセス出来る様になります。
何となく 合理的な様ですが タスクバー上に 有った時と 隠れているアイコンを表示した ウィンドウとは 違いだいぶ 挙動が違い 隠れているアイコンを表示した ウィンドウは独立したフォアグラウンドのウィンドウで 今までの フォアグラウンドウィンドウはフォーカスを失ってしまいます。したがって タスクバー上にアイコンが有った時には 此のアイコン上でマウスカーソルが動いた時には ( アイコンをクリックする為にマウスカーソルを移動させた時 ) 此の MouseMove のメッセージで 現在の フォアグラウンドのウィンドウ を取得する事が出来ました。
此を アイコンを隠してしまうと 隠れているアイコンを表示する為には 隠れているアイコンを表示するウィンドウが 新たに開き 此のウィンドウがフォアグラウンドのウィンドウとなってしまいます。確かに 表示された アイコン上で  MouseMove のメッセージは出るのですが 此のアイコンを表示するウィンドウハンドル を取得しても何の意味も有りません。
此処 ソフトの小物たち に有る タスクバーにアイコンを表示するプログラムの中で アイコンをクリックする直前の フォアグラウンド ウィンドウ を必要とする物が何個か有ります。と言うより 殆どが アイコン上で MouseMove が 有る事 前提でプログラムがされています。したがって アイコンを隠してしまうと本来の動作が出来なくなって しまいます。なるべくなら アイコンを隠さないで使用する事をお勧めします。
この辺りの事は 立ち上がる時にアクティブウィンドウを参照するプログラムについて。 にも関係してくる話です。

　　＊ 2018/05/30 マウスカーソルの ウィンドウ位置について。
プログラムをしていると マウスカーソルが今何処に有るか が問題になって来る事が多々有ります。基本的な話は  プログラムチップ 関連な話ですので マウスカーソル位置判定の HitTest　2015/08/25 の方にに書き留めました。
いずれにしても 使用する方は 楽で 正確ですから これからは 機会が有れば WM_NCHITTEST を使用して いこうと思います。

　　＊ 2018/05/10 CabwcPos のフォルダー位置記憶タイミングについて。
CabwcPos は常駐させればすぐに デスクトップに有るフォルダーウィンドウを列挙して記憶して 次にそのウィンドウが 開かれた時にはその位置に移動させる。考え方はシンプルで 此で良かったのですが よく考えて見れば 別に記憶しなくても いい物も有るし 圧縮庫から解凍ソフトで解凍した付属フォルダー等 多分二度と開かない物も 全て記憶していました。 此の為 記憶バッファも 256個 → 384個 → 512個 と増やしてきましたが やはり満杯になるのは否めません。
此の為 Ver 2.300 では 記憶フォルダーに重みを付けて対処しましたが バッファの最後の方の １/３ 程度は 無駄に なってしまうようです。気にしないと言えばそれで終わりですが 二度と使用しない物が有るのは 無駄な事で  検索スピードもかかって遅くなってしまいます。
そこで 原点に戻って 何でいつもの位置に移動させたいか を考えれば それは OS ( Windows ) が開いた位置が気に 入らなくて 不便だから 自分で使いやすい位置に移動したり サイズを変えたからです。この様に 考えれば 初めから 記憶していなかった物は 位置を移動したり サイズを変えた時だけ 新たに記憶していけば良いのではないかと言う 発想で 記憶バッファに入れる事にしました。こうする事により 記憶数がむやみに増えていく無駄も減りました。 又 移動して使用していたが 記憶する必要も無い時の為に 記憶消去機能も設けました。
今までの 記憶数が フルになっている時には 一度 メニューからリセットをして無駄な物を振り落として 新たに 始めた方が 良いかもしれません。そんな考えで 記憶バッファも 512個 → 384個 に戻そうかと思いましたが 今回は 様子見の為に見送りました。( 私の使い方で 220個前後で上下しています。)

　　＊ 2018/03/05 タスクバー プログラムマネージャー のウィンドウハンドルについて。
此処にある 他のプログラムと関連して働くソフトは多かれ少なかれ デスクトップの 通常最上位にあるにあるタスクバー  ( クラス名:"Shell_TrayWnd" )と 最下位に有るプログラムマネージャー ( クラス名:"Progman" ) を認識して  (ウィンドウハンドルを取得して) 動いています。 したがって 此までは立ち上がる時に 何らかの機会を捉えて 此の２つのウィンドウハンドルを取得して  その後 此の ウィンドウハンドルは変わらない前提でプログラムコードを書いてをしていたのですが 2017/08/30 の テクニカル インフォメーション にも多少関連して書いた様な事情で システム( ウィンドウズ )の 何らかのトラブルが 起こると 此の２つのウィンドウハンドルがリセットされて変わってしまう事が 起きてしまいます。 ( 実際には もっと多数の物が リセットされているのかもしれませんが ウィンドウハンドルは 同じモノを立ち上げる 場合でも必ず違う値を使用してきます。) したがって最初に取得した  ウィンドウハンドル は無効になって プログラムによっては不具合が出てしまったり 場合によっては 此が原因で他に 悪さをしてしまうかもしれません。
立ち上がって 比較的すぐに 終了するプログラムなら 一回の立ち上げ時の確認だけで良いでしょうが ウィンドウの立ち 上がりから 終了まで常駐して使用されるソフトは システムは何らかのトラブルがあったとは通知してくれませんから  自分が参照している ウィンドウハンドル 特に タスクバー や プログラムマネージャー のウィンドウハンドルが 有効かどうか 適宜 機会を捉えて確認する作業をするコードを付加する事が必要になってくるかと思います。

　　＊ 2018/02/20 ソフト ( プログラム ) のバージョンアップについて。
ソフト( プログラム )は 不具合 ( バグ ) が出た時や 新しい機能を付加する時等は もちろんバージョンアップを する訳ですがそれ以外にもバージョンアップが避けられない事が 出てきます。
長い事使用していれば ウィンドウズが 新規になってきて 此により新しい機能や制限も加わってきます。 OS として提供される API も Windows の バージョンによって変わる事も有り 此らに対処する為にはやはり  バージョンアップが必須となってきます。
又 同じソフトでも長く使用していると パソコンのハード面の世代交代も有り 処理スピードもずいぶん変わってきます。 処理スピードにタイミングを取りながら動作するソフトの場合も 少しずつ何らかの改良が 必要となってきます。
後 ソフト( プログラム ) の中で 自分だけでなく 外部のプログラムを相手にする物は 外部プログラムの主体は何なのか 相手にするプログラムの速度にも 変化が出たりして此にも対処しなければ 狙っている正常動作が出来ない所も出てくるかも しれません。
結局 作りっぱなしの ソフトではなく 常に使用しているソフトについては忘れた頃の バージョンアップ はしなければ いけないのかもしれません。

　　＊ 2017/12/20 ClipName 終了時のメモリーエラーダイアログの可能性について。
本日 アップした ClipName は 久しぶりの メモリーエラーが出てしまう可能性の バグ 潰しとなりました。
ClipName で プログラム上は動作は完結して 最期の事後処理の時にメモリー参照エラーの警告ダイアログが出る可能性が 有り 此が出るとメモリーリークの可能性も有りあまり嬉しくない感じがします。 ただ メモリーリーク と行っても プロセスはそこで終了してしまう訳で システムには 影響は無い筈です。
ClipName 自体は テクインフォ 2001/10/01 に書いた様な 自分が 多数の立ち上がる可能性の有る事情から できるだけ メモリー取得を 少なくして 使い回しています。此は DLL に渡すのにも 帰ってくる時も 共通して行っています。
通常はメモリーバッファを取得して それ専用に使用するのですが 有る機能を終えて ClipName.dll から帰った時には 予め取得したメロリーバッファではなくて Dll から帰った結果の先頭にポインターを移動して そこから前に書き込んで 最期に エクスプローラーにコマンドとして渡すコードが有りますが Dll から帰った結果の先頭からの余裕は 8 バイト しか無かったのを 11バイト 書き込んでいていた部分が有りました。エクスプローラーはコマンドを受け取り 正しく 動作をするのですが ClipName の最期の事後処理に余分に書きもまれた部分が メモリーの解放などの 参照に当たった時に メモリーエラーダイアログが出てしまう様です。プロセスはそこで終了してしまうので あまり目くじらを立てる様な物では ないのですがエラーダイアログが出るのはまずいので Dll から帰った結果の先頭 のバッファを増やして対処しました。

　　＊ 2017/08/30 タスクトレイにアイコンを表示するプログラムについて。
こと Windows 10 だけの事でもないのですが Windows 10 もずいぶん落ち着いてきて 見た目も変わりなく動いていますが  まだ時々 エクスプローラーが エラーで イベント ID :1002 1000 で落ちる事が起こってるようです。このエラーは 多少反応が 無くなり 自動的にエクスプローラーは 立ち上がって リカバーしてシステムが落ちる事は無いのですが 画面が書き換わり  タスクトレイに有ったアイコンが消えたり プログラムマネージャー等も 再起動したりして ウィンドウハンドルが変わったり しているようです。此の辺りは 以前のブルースクリーンで システムの再起動になっていたのかもしれません。
プログラムのうち 常駐してタスクトレイにアイコンを表示するプログラムは タスクトレイにアイコンが表示されたのを確認して 内部の設定保持で 自分は アイコンを表示している事にしている訳で 勝手にアイコンを消されてしまうと その状況で今度は タスクトレイのアイコンが消せない(消したつもりでもエラーになってしまい) アイコンを表示している事になり いつまでたってもアイコンが表示出来なくなり タスクトレイアイコンしか出さないプログラムは 自分自身の設定も出来ず 終了もままならなくなってしまいます。
又 プログラムマネージャー や タスクバー のウィンドウ ( Shell_TrayWnd )を確認しながら動いている プログラムも ハンドルが変わると これらにとんでもないメッセージを送りつけたりする可能性が生じます。 ( プログラムマネージャー や Shell_TrayWnd は殆ど とんでもない メッセージは受け付けない様ですが。)
したがって エクスプローラー が落ちてシステムは無事引き続き動いていても 常駐しているプログラムは何らかの 内部と  外部との調整修正をする必要が有りそうです。まあ プログラムも おかしくなったら再起動させれば良いのですが  おかしくなった事の確認と 終了できない物の再起動は難しい事になります。

　　＊ 2017/03/25 エクスプローラーのタイトルバー表示される文字数について。
エクスプローラー ( フォルダー表示ウィンドウ ) のタイトルバーのアイコンの右クリックでフォルダー コンテキスト メニューを出す CabULCmu.exe は タイトルバーにファイルのパス名を表示する のオプションをチェックしている状態で 此の表示を利用して フルパスから フォルダー認識をしています。
CabULCmu.exe のフォルダーメニューを 立ち上げる所のコードを改善する為に 全てユニコードで扱う事にして コードを修正しだしたのですが 以前から気になっていた深いフォルダーの時に 失敗して表示出来ない事をこの際だから 解析しておこうとして調べてみると タイトルバーにファイルのパス名を表示させても 此までは 長いパス名でも表示 されるスペースが無くて切れて見えないだけだろうと思っていましたが そうではなくて Windows XP 7 10 共に あまり長いパスは はっきりした意識を持って文字数を 95 + 1 に切って表示している事が解りました。此は C:\ ・・・ から始まって 全角 半角関係無しに 95文字 + 最後の ゼロ区切りで 統一です。此は何処にも書いては ないのですが 最初からの既定の事実だったのかも知れません。
そんな訳で 95文字を超えるフォルダーは タイトルバーテキストからは 正確に認識出来ないのでこれ以下のフォルダー コンテキストメニューを出す事は出来ませんし プログラムのバッファーも 192 Bytes 用意するだけで事足りる様です。 まあ 文字数 95 ですから実用的には 殆ど問題は無いとは思いますが 全てのフォルダー対応では無い事は 認識して おかないといけないようです。

　　＊ 2017/02/25 CabwcPos の Hook 機能について。
話が若干 プログラム的な事柄ですが 現れた現象からの事ですからこちらに書いておこうかと思います。
CabwcPos の主目的は 新しく開かれる フォルダーウィンドウ ( エクスプローラー ) の位置を 以前有った所とサイズに する機能です。この為 新しく開かれる ウィンドウ を確認するのに CabFixer では タイマーで確認していましたが タイマーだと タイマーインターバルをそう短くするする訳にもいかないので どうしても打てば響く様な反応を得るのが 難しいので CabwcPos では システムが 元々用意している 変化を予め捉えられる Hook を使用する事にしました。 CabwcPos.exe が CabwcPos.dll とセットになっているのは 此の Hook を掛ける為です。そして CabwcPos が使用しているのは ウィンドウが 作成 アクティベート 移動された サイズが変更 最大化 最小化 等が された時に メーッセージを出してくれる CBT Hook と呼ばれる物です。
これらは システムが 今からしようとしている時に 搬出されるので 非常に早いタイミングで来るし 又それまでは プログラムは 何もしなくていいので負荷の掛からない物です。此を使用するのは都合の良い事は多いのですが ウィンドウが作成されるメッセージは子ウィンドウまで含めた全てのウィンドウで 来てしまうのと 非常に早いタイミングで来るのでまだ形が整っておらずに 可視で無い事が殆どです。取りあえず 子ウィンドウは必要ないので フィルダーを掛けます。此は まあ ウィンドウスタイルが 子ウィンドウでない事と キャプション(タイトルバー)を持っている事で選択したのですが Windows 10 で ある種の 映像再生ソフトを フルスクリーンで起動再生すると子ウィンドウでなくてキャプションが有るウィンドウで可視にならない物を たぶん マウスムーブのメッセージの数だけ作成している事が解りました。 此だと１秒に20回以上 メッセージが送られて来てしまいます。作成されたウィンドウはある程度待って ( 今の所 200ms ぐらいですが ) 可視になるか判断して 可視にならない時には 何もしない事になりますが １秒に20回以上 送られて来てしまうと 此を待つだけで 手一杯で 他の自分自身のメッセージは 何時処理出来るかな と言う事になって 殆ど無反応状態になってしまいます。ただ 自分のスレッドは 放棄して待っているだけですから 他には殆ど悪さはしません。
最終的には ウィンドウ作成時のフィルターを厳しくして それで漏れる様な物は ウィンドウのアクティベートの 方で拾う事で 却って今まで漏れていた物も拾える様になり 余分なメッセージ処理も無くなり 反応も早くなりました。 反応も良くなり落ち着いた動作が出来る様になったので 他の出来る オプションも加えました。
上記 動作と メッセージ解析の為に KHdebug に新機能を入れたので あまり通常の方には関係がないと思いますが プログラムティップス に有る KHdebug もそのうち改訂アップをしたいと思います。

　　＊ 2017/02/05 ボタンに移動 の機能について。
コントロールパネルのマウスのプロパティ→ポインタ オプション→動作 ポインタを自動的に既定のボタン上に移動する の 機能は CabFixer が持っている ボタンに移動 と同様な物です。全く 同じ機能なら CabFixer に付加したりはせずに このまま使用するのが良いかと思います。違う 機能が欲しいので CabFixer に実装しています。
同じように見える機能ですが マウスのプロパティ の方は 開かれた直後だけなのに CabFixer は そのウィンドウが アクティブになった時にはいつも この 既定のボタン上に移動 します。又 既定のボタンもより 範囲を広げて 直下のボタンだけで無く子ウィンドウ全体に広げています。此の様な事で私は CabFixer の ボタンに移動 を使用して いるのですが 逆に 多少のやり過ぎの不便も感じていました。それは 下の アクティブでないウィンドウのテキスト窓 に入力しようとして 此をクリックすると ボタンに移動 機能が働いて マウスカーソルを移動してしまうのです。 テキスト を選択しようとして無意識にボタンを押すと OK ボタンだった等という予想しない事が起きてしまいます。
此の様な事が頻繁に起きる作業の場合は 設定から ボタンに移動 のチェックを外していましたが やはり手間が かかってしまいます。それで 最初の立ち上げ時は除いて マウスカーソルが アクティブになったウィンドウの 子ウィンドウ上に有った時には ボタンに移動 の機能をしない様にプログラムをする事にしました。この機能を 実装すると かなり 使用上のイライラが 減る様になり 此まで何でしなかったのかが 疑問なぐらいです。

　　＊ 2016/09/25 プログラムのユニコード化について。
此処にあるプログラムは Windows 98 からか そのベースをWindows 98 に持つ物が多いので プログラムの内部では ANSI ( 実質的には SJIS ) で作ってきました。
Windows 2000 から ウィンドウズ内部動作では UNICODE になっています。この為 プログラムも 内部的には UNICODE で動作する方が Windows とのテキストをやり取りする時には 親和性の観点からは ウィンドウ内部の変換も無くなって効率も良いようです。
ただ 既存の プログラム内部を変えるとなると 結構ハードルも高い感じがします。又 保存データや コンフィグレーションデータを 新たにする事を考えると しにくい物もあります。
ただ 此までは ANSI ←→ UNICODE 変換でそれ程違和感は無かったのですが Windows 10 が出て ツールチップスとか等で結構 ANSI に無い文字を使用して来ている様で ANSI でコピーすると文字化けを する物も多くなって来ている様です。
こんな事を考えると内部的には UNICODE で Keep するというのもこれからは良いかもしれませんし 文字列の 扱いを考えると バッファサイズは 大きくなる可能性は有りますが常に 2バイトずつの UNICODE の方が プログラム的には 扱いが楽になるかも知れません。
この UNICODE の事は Windows 2000 が出た時に これからのプログラムは内部的には UNICODE 対応を する事を勧めますとの MS の勧告も出ていましたが 現在 遅くに失した感はありますが出来る物から 又 矛盾が出やすい物から 内部的動作を UNICODE 動作に変えていきたいと思います。
ただ 私も常用している テキストエディターでも 内部的に ANSI Keep と UNICODE Keep が有るくらいで 全く さくっと切り替えられる物でもない様です。

　　＊ 2016/08/30 32ビット整数値の限界。
今更 此を改めて書くのも 何だとは思いましたが 結構計算方法によっては オーバーフローしたりしなかったり と実感した物ですから 何となく書き留めておく気になりました。
かなり以前の話ですが プログラムの処理系のデフォールトの整数値が 16bit から 32bit になった時には 此で殆どの事は整数計算で事が済むと思ったものでした。現在でも 表示桁等を考えれば 32bit 整数で ほぼ事が足りて十分の事の方が多いのではないかと思っています。
ただ この所の 記憶装置の記憶域とか ネットワークの速度とかの 爆発的な増加を考えたり 此らを内部で計算して 平均したり割合計算をするとなると気を付けていないと落とし穴が出るかも知れません。
表示桁だけなら 32bit 整数で 40億ですから 表示は出来ますが 整数計算をする時には浮動小数点計算と違って 値は切り捨て 切り捨てで進みますから計算の基本は ( A * B ) / C かけ算 割り算の順序になります。この ( A * B ) が 32bit 整数を超えたら オーバーフロー です。平均を出す時でも ( A + B + ・・・・ ) / サンプル数 と なり ( A + B + ・・・・ ) が 32bit 整数を超えたら オーバーフロー です。サンプル数 100個なら 40Mb 平均までと 言う事になり 4Gb とはずいぶんな大きな差になってしまいます。ファイルなら 40Mb ぐらいは当たり前の様に 有るでしょうし 気の利いたネットワーク や USB2 でも 40Mb/sec ぐらいは出るかも知れません。
そんな事を考えると USB3 や 10Gbit ネットワーク等は とうの昔に 32ビット整数値の限界を超えてしまって そういう用途には 64bit 整数を使いなさいと言う事でしょうか。ただ 0〜127までしか変化しない用途に 64bit 整数と 言うのもいかがかとも思いますし CPU にもクイック値 ( 8bit整数 ) が有るのもうなずけます。

　　＊ 2016/08/25 Windows 10 の ウィンドウ枠について。
ネットでも既に話題になっているようですが Windows 10 の ウィンドウ枠の表示は 1ピクセル枠の表示と Win8 と同様の太い枠 表示が有る様で 1ピクセル枠の表示の物は 1ピクセル枠の外側に表示されない何ピクセルかの枠が 有る様で 此処がサイズ変更ゾーンになっていて ウィンドウを隙間無く並べたつもりでも隙間が出来てしまいます。
それでは 太い枠 表示を使えばとも思いますが あのフラットの表示は如何かなと思うし 色の自由度も違い アクティブ ウィンドウが解りにくいので 1ピクセル枠の表示を我慢して使用しているのが現状です。期待の新星 Anniversary Update で この辺の表示が変わらないかと期待していたのですが全く以前と同じでした。
Windows 10 ( Windows 8 かも ) から MS はウィンドウの使い方の方針を オーバーラップから 一画面 1ウィンドウ に 変えたのかも知れません。( AeroSnap 等もその流れの中に有る物かもしれません。) 常にウィンドウを最大化して 使用する方は此の方式で全く違和感無く使用出来るとは思いますが 私の様に ウィンドウは有る程度並べてオーバーラップ させながら 他の物を参照しながら使用するにはずいぶん不便です。Windows 10 が全てを 此１つで 使用するから この仕様で良いと考えているなら ならずいぶん デスクトップ使用を ないがしろにした仕様だと思われます。 ( せめてカスタマイズの自由度を上げるとかして欲しかった。)
とは言っても直らなかった物にあれこれ言っているより もうズーッとこの仕様なのだ と言う事で 今後 プログラムも 考えて行きたいと思います。

　　＊ 2016/04/20 SHBrowseForFolder API について。
色々な所にコピーしたりする時に コピー先 フォルダーを選択 指定するのに 結構な頻度で フォルダー選択ダイアログを 使用する事と思います。この時 殆どは ウィンドウの API の一環である SHBrowseForFolder を使用して 此の ダイアログを出します。此は 定型で大変に便利な物ですが フォルダーの選択といいながら 内部的には以下のファイルまで 確認している様で フォルダー以下のファイルの多い時や ファイルのサイズが大きい物を含むフォルダーでは非常に遅く なってしまいます。又 最近は Defender のリアルタイムスキャンが入るので ますます遅くなって来ています。 大きな 動画ファイルをネットワーク上に保存しているフォルダー等を選択する時など 殆どロック状態で 応答無しに なって まさしく お手上げ状態になってしまいます。
こんな時には フォルダー選択ダイアログ の TreeView からその都度選ぶより 此の TreeViewは ストップ 若しくは 経由をやめて 最近の経歴からとか 他でコピーした フォルダー名 だけで指定したり フォルダーのドラッグドロップで 直に 指定した方がよほど 速く決定出来る様になるかと思います。やはり 場所と用途を考えて 何を使用するか 機能を 動かす 動かさない の オプションを考えて 切替機能を 付加した方が良さそうです。

　　＊ 2016/04/10 ShellExecuteEx API について。
この話は どちらかと言うと Programing Tips 向きの話かも知れませんが それ程長くないし単独の ページにも なりそうも無いので 此処に書いておく事にしました。
確認と 新たな事項がないかと思って MSDN ( Microsoft Developer Network ) の ShellExecuteEx の項目を見ていると 若干気になる事が書いてあるのを発見しました。
ShellExecuteEx は他のプログラムをプログラムの中から立ち上げるのに頻繁に使用する API で 此処のプログラムの 中でも結構使用頻度の高い API です。その MADN の中で
立ち上げる プログラムが using Component Object Model (COM), COM should be initialized before ・・・ In that case, COM should be initialized と言う条文が なぜか有りました。COM を使用する プログラムを立ち上げる 時には COM should be initialized だそうです。此まで 自分で COM を使用する時には CoInitialize をするのは 当然ですが ShellExecuteEx で立ち上げる時でも するべきだと書いて有ります。又 would not require COM it is good practice to always initalize COM before using this function. 使わないかも知れない時でもしておくのも 良い習慣だと言う事でしょうか。と言う事は ShellExecuteEx を使用する 特に頻繁に使用する ランチャー系の プログラムは CoInitialize を 統一して始めにしておいた方が良い事になります。
次に SEE_MASK_NOCLOSEPROCESS での hProcess The calling application is responsible for closing the handle when it is no longer needed. と言う事で 自分で 此をしないと リソースリークが出て来るかも知れません。 と言うより出るという事でしょうか。
どちらにしても 新たに注意する事が増えて来た様で気を付けないといけない事が増えました。

　　＊ 2016/03/25 ファイル時間について。
この話は どちらかと言うと Programing Tips 向きの話かも知れませんが 全体的なインフォーメーションにも 近いので こちらに書く事にしました。
ファイル時間 と言えば ファイルの 更新時間 作成時間 が通常は関連しますが より身近なのはいつ変えられたかの 更新時間だろうと思います。此が 新しい 古いで どちらを選択するか決める事は多いだろうと思います。更新ソフト プログラムも 殆ど此に頼って動作している事だろうと思います。
ウィンドウのシステムでは 古くは FAT FAT32 共に 秒は 2秒毎 1/1000 秒の単位は 0 で無し NTFS では 1/1000 秒単位で 記憶出来る事になっています。それでは NTFS の 1/1000 秒単位の有るファイルを FAT32 の所にコピーしたら どうなるかと言うと 1/1000 秒単位を切り上げて 2秒毎 の時間になります。したがって NTFS → FAT にコピーした 時には コピーされたファイルの方が最大 1.999 秒新しい時間が付く事になります。FAT → NTFS の時には FAT と 同じ時間となります。したがって この FAT のファイルを NTFS の元のファイルに上書きコピーすると元の ファイルは 1.999 秒新しい時間が付く可能性が有ります。此処までは ウィンドウのシステムを使用している時の話です。
ただ この頃は ファイルは直に ウィンドウのシステム下に置かれる物では無くなって ネットワーク上のストレージに 置かれたり その USB上に置かれたり ルーターの USB コネクター上のメモリーやら HDD 上に置かれたり 色々なシステム 上に置かれる事も出てきました。
そんな中で 今回話題にしたいのは あるルーター( ASUS )の USB コネクターに繋いだ USB メモリー USB HDD の ファイル時間の挙動が ウィンドウのシステム下 とずいぶん違っている事です。USB メモリー HDD 共に FAT NTFS との フォーマットに関わりなく 秒単位は 1 秒単位 1/1000 秒は切り捨ての 000 秒時間になります。此は FATからのコピーは ファイル時間は 同じ NTFS からのコピーは コピーされた物は最大 999 ms 古いと言う事になります。この事は ファイル時間 をみて更新コピーをするプログラムは何らかの対処をしないと 常に更新コピーをする事になりかねません。 今回は此の辺りの気になっている事を書くに留めますが 此処 ソフトの小物たちの プログラムの中でも何個かは 引っかかって来る物が有りそうです。此からは プログラムをするに当たってファイルの置かれる環境によっては この時間を確かめて 考慮しないと 不具合が出て来る事も有りそうです。

　　＊ 2015/09/25 Windows 10 での *.HLP ファイル。
Windows 10 も正式リリースされて 2ヶ月程経ちますが Windows Vista 〜 8.1 まで有った KB917607 ( 以前の HLP ファイルリーダー WinHlp32.exe ) はまだ出て来ていません。HLP ファイルは 公式的には Microsoft 内ではサポート外となってしまった様です。したがって KB917607 は出てこないかも知れません。Windows 8.1 でも WinHlp32.exe がまともに動作するのは 2015/06/15 以降の KB917607 ですからあまりやる気を感じません。
かといって 古いソフトでも Windows 10 で問題なく使用出来るのに HLP が読めないのは 不自由です。結構 ウェブ上でも 話題にはなって Q & A にもなっている様です。そんな中で Windows XP の WinHlp32.exe が Windows 10 でも何の問題も 無く使用出来る事が解りました。( 灯台もと暗し ) Windows Vista〜8.1 の KB917607 での Windows フォルダーに インストールされる WinHlp32.exe では何か動作に制限が有るのか うまく動きません。今更 Windows XP の WinHlp32.exe と 言っても入手出来ないかも知れません。Windows XP のインストールディスク の i386 の中にある WINHELP.EX_ ( 此は単なる CAB 圧縮ファイルです。) を解凍すれば WinHlp32.exe が得られます。この場で 此を配布していいのかどうか解りませんが 無ければ不便でしょうから WINHLPXP.CAB ( i386 の WINHELP.EX_ を解凍し易い様に名前だけを変えた物です。) として置いておきます。解凍したら WinHlp32.exe を Windows フォルダーに置けば 自動的に *.HLP と関連付けられて HLP を読む事が出来る様になります。他のフォルダーに 置く時には WinHlp32.exe の名前を WinHlpXP.exe とかに変えないといけないようです。( WinHlp32.exe は特殊な名前の様です。) そして *.HLP との関連付けは自分でして下さい。
取りあえず Microsoft のサポート外かも知れませんが +.HLP を読める様になります。此処 ソフトの小物たち に有る物で Windows 10 でもきちんと働くのに ヘルプファイルを書き換えていない事で Windows 10 対応と言いにくい物でも 此で Windows 10 対応と 言う事にしたいと思います。
[ 2021/02/21 ] まだ Microsoft のサイトから Windows XP SP3 のアップデートアーカイバ ( KB936929 約325Mb ) が ダウンロード 出来る様です。此をダウンロード解凍して i386 以下にある WINHELP.EX_ を解凍すれば 公式的に ( ?? ) WinHlp32.exe を 取得する事も出来る様です。

　　＊ 2015/08/20 4 行で作る スタートメニュー。
Windows 10 で スタートメニュー は復活したのですが 全てのプログラムに展開しても 全体の様子を把握するのも 難しく アルファベット順に並んではいるのですが何が有るかを探すのも時間がかかる事も多く 又 その場所の フォルダーを開けるのも不便です。
そんな訳でスタートメニュー関連のフォルダーを開けるのとスタートメニューの中のリンクを直に開く為の 設定を SbFolder 用にして使用している物を書いておきます。

@個人メニュー
C:\Users\UserName\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
@共通メニュー
C:\ProgramData\Microsoft\Windows\Start Menu\Programs
@デスクトップ
C:\Users\UserName\Desktop

( フォルダー位置は Windows 10 8 用です。UserName に自分のログイン名を入れて下さい。@デスクトップ以下はおまけです。)
と書いたテキストファイルを何処でも良いので SbStartMu.txt 等の名前で保存します。
SbFolder.exe のショートカットを作り プロパティーに
・・・・\SbFolder.exe /-R-H ・・・\SbStartMu.txt ( /-R:経歴ファイルに入れない -H:隠しファイルは対象外 )
と 入れた物を立ち上げれば簡易スタートメニューになります。デスクトップとかクイック起動等にピン留め するのが良いかと思います。こうすれば 直にプログラムを立ち上げる事も出来ますし各メニューのフォルダー も開く事が出来ますし 何個かの項目を一度に処理する事も出来ます。唯一のネックはアイコンが出ない事ですが その分サクサク動きます。

　　＊ 2015/07/25 スタートメニュー作成用 ExecMenu について。
Windows 10 の仕様も殆ど決定して スタートメニューの様子も固定された様です。印象としては Windows 8.1 + 文字の スタートメニュー と言う所で 結局あまり使用しない下の方( 奥の方 ) に有るアイテムは確認して立ち上げるのは Windows VISTA 以前のスタートメニューの方が 何が何処にあるか ポップアップメニューの下に有る物を確認しながら 追って行くのには 適していた様な気がします。
私は 本来 スタートメニュー と言うのは究極のランチャーの1つだと思っているので メニューアイテムの位置が都合に よって変わったり隠れたりするのは かえって使い勝手が悪くなるのではないかと思います。いつもの所にいつもの物が 有って立ち上げられる 結構そういう位置関係で 覚えているのではないかと思います。
今まで 主目的は 送るメニューに入れて立ち上げプログラムを指定する ExecSlct が有りました。此は ランチモードにすれば メニュー型ランチャー としても 軽快に動きますが メニュー設定をテキストエディターで ExecSlct 用に編集するのは 結構面倒で 数が多くなると時間も相当かかってしまい 挫けます。又 ExecSlct 自体も全てのメニューアイテムをアイコンまで 確認して作成してから メニューを出すのでアイテム数が何百にもなると表示まで 時間がかかってしまいます。
そんな訳で 有るフォルダー以下の ( 想定はスタートメニュー と デスクトップ ) ショートカットを検索してフォルダー構造は そのままにショートカットを解析した物を ExecSlct の設定メニューにする ExecMenu と言う補助プログラムをアップ しました。此だと 私の環境で 500個ぐらい有る 個人用スタートメニューを 作るのに 3秒程度で出来てしまいます。 此と All User の スタートメニュー を加えれば ExecSlct に スタートメニューを代行させる事が出来ます。
ExecSlct 自体は 700個ぐらいのメニューアイテム全てを アイコンの展開も含めて終了するのを待つのは Windows 7 までだと 1秒程度ですむのですが Windows 8 10 だと延々と 30秒以上やっていて実用的では有りません。( 何でこんなに遅いのか 理解に苦しみます。) それで 文字とポップアップは最初に作成して アイコンの展開はメニューを描く時にその都度する事にして 又 一度 展開したアイコン は二度としない事にして 最初の立ち上げスピードを大幅アップしました。立ち上がりは劇的にアップ しましたが メニューが出てから Windows 8 10 だと下のサブメニューメニューアイテムが多いとアイコンを1つ1つ描いているのが 見えるぐらい遅い時が有るのは やはり 理解に苦しみます。
とにかく 出来た物を クイック起動に入れれば 此で 以前のスタートメニュー擬きは出来ましたが ExecSlct のメニュー設定用 ファイルは絶対的な物ではなく 単なるテキストファイルです。切ったり はったり 削除したり 新たに加えたり 順序を変えたり するのは自由です。新たに デスクトップアイテムを加えたりも出来ます。そんな事で 今回から ExecSlct に ExecSysItem.txt を同梱しました。此をどこかに挿入すれば 此のアイテムもメニューの中に出る様になります。
[ 2016/04/30 追記 ] Windows 8 10 だと下のサブメニューメニューアイテムが多いとアイコンを1つ1つ描いているのが 見えるぐらい遅い時が有るのは EXE ファイルからアイコンを抽出する時に Windows Defender のリアルタイム保護が それぞれの EXE ファイルに掛かる為だろうと推測されます。

　　＊ 2015/05/25 DPI スケーリング について。
此の関連にについては 以前 ウィンドウズ ８ ( 10 ) 対応コードへの プログラムチップ でも若干述べてはいたのですが Windows 10 IP 10122 で DPI スケーリング の適用 が変わったと思われる所も有るので 新たに書いておこうと思います。
Windows 10 は此で色々な器具に使ってもらおうとしている様で 画面サイズも 解像度もまちまちでしょうから OS 自体が 積極的に DPI スケーリング を行い DPI仮想化によるスケーリングの方向も 必然だろうとも思います。此は exe ファイルか ショートカットの [プロパティ] をクリックし、[互換性] タブをクリックし、[高 DPI 設定では画面のスケーリングを無効にする] チェック ボックスをオンするか exe ファイルが DPI スケーリング は対応しているから自分ですると 宣言しなければ 必ず OS が DPI スケーリング を行うと言う事になります。
此処 ソフトの小物たちに有る フォームを表示する プログラムは 若干数を除き プログラムチップの フォームのサイズとコントロールの配置 に多少 関連事項を 書いた様に フォームのサイズを決める時に システム UI の 基本フォントのサイズを取得してそのサイズの倍率がけをして 決めています。したがって UI の 基本フォントのサイズ は 画面によって適切な大きさにされているので フォームのサイズは それにより変わり 基本的にプログラム自身で DPI スケーリング機能を持っている事になります。その為 OS に DPI スケーリングをしてもらう必要はなく してもらうとかえって ぼやけてしまったり 大きくなり過ぎてしまったりする事に なります。当面は 此処に有る ソフトは 高 DPI 設定では画面のスケーリングを無効にする で 運用される方が良いと思います。
ただ プロパティ から 此を各々セットするのも結構手間ですから 追々 プログラム的に DPI スケーリング は対応していると 宣言を入れていこうかと考えています。試験的に コードを入れた所 300 Bytes 程度余分にかかりました。今までと同じ事をする 為に 余分な事をするのもどうかと考えたりもするのですが DPI スケーリング へのソフトの対応 は Vista が出た時に MSDN の 方で 互換性の推奨事項として出て そろそろ避けられない事だとは思いますが デスクトップだけで使用する為の プログラムに各々これらの宣言を入れ込むぐらいなら 又 開発が終了して アップも期待出来ない以前から使用しているソフトも 有る訳ですから 各々で対応するよりも デスクトップ使用の時は 全面的に OS は DPI スケーリング をしない様なオプションを 付加していただいた方が合理的ではないかと思ったりもします。

　　＊ 2015/02/25 フォルダー表示の 左上アイコンのコンテキストメニューについて。
フォルダー表示ウィンドウ ( エクスプローラー ) は そのフォルダーに何が有るかを表す ウィンドウズにとっては 一番基本的な ベースのウィンドウだろうと思います。私もとりあえずはその関係のフォルダーウィンドウを開いて そこから始める事が多いのではないかと思います。
そんな フォルダー表示ウィンドウ ( エクスプローラー ) ですが Vista から タイトルバーの一番左のアイコンの 機能が変わってしまいました。Windows XP までは 此の左上アイコンは 表示している フォルダー その物で アイコンの ドラッグ ドロップも出来るし 此のアイコンの右クリックは此のフォルダーに対するコンテキストメニューを出す様に なっていました。此が 何でそうしたのか解りませんが Vista からは単なるタイトルバーの模様扱いになってしまいました。 出来る事は 他の部分のタイトルバーと同じで メニューも単なる 移動 だの 最大化 だの 閉じる だのの システムメニュー しか出なくなってしまいました。表示しているフォルダーに対する右コンテキストメニューを表示させる為には 左の ナビゲーションウィンドウ( TreeView ウィンドウ ) での自分か 一段上に戻った所の自分で 右クリックしてコンテキスト メニューを出させるしか無くなってしまいました。確かに左の部分にナビゲーションウィンドウを表示して 常に表示 フォルダーまで展開する としておけば まあ問題は無いのですが ナビゲーションウィンドウは展開するのがずうっと たどって行くので深い時にはかなりの幅も高さもとり やっと見えるのは隠れ掛けた フォルダーが自分自身 又 ネットー ワーク等の時は延々と展開して落ち着くまでに非常に時間もかかってしまいます。
私も仕方なくその様な方法を採っていましたが 場所も取るし 遅いし と言う事で エクスプローラーでのフォルダーの コンテキストメニューをフォルダーパスを指定すれば 比較的安定して出す ( 拝借する ) 事が プログラム上で出来る様に なったのを機にフォルダー表示ウィンドウのタイトルバー上 左上アイコンの右クリックメニューで此のフォルダーに 対するコンテキストメニューを出す様なプログラムを作成しました。あくまで コンテキストメニュー 自体は エクスプローラーの中でまだ開いていない アイコンの物ですから XP までの様に 自分が開いている前提の物ではなく メニュー項目も若干おかしな時も有るのですが あまりおかしな所はプログラム的に修正して表示しています。
此のプログラム CabULCmu を使用する様になって Vista 〜 8 ( 10 ) まで左にナビゲーションウィンドウ( TreeView ウィンドウ ) を 表示していた設定を全てやめにしました。フォルダー表示ウィンドウは小さく表示出来るし 表示する速度も速くなりました。
結局は 良くなったとは言っても Windows XP が出来る事が 同じ様に出来る様になったという事だけで 此の辺りの フォルダー表示 ウィンドウ ( エクスプローラー ) の仕様は Windows XP 以前の方が優れていたのではないかと思ったりもします。
[ 03 / 05 の追記 ] Windows XP は意味が無いと思っていましたが 若干出るメニュー内容に違いがあり 削除が加わっています。したがって 何らかの形で その都度使い分けられる様にすると 開いているフォルダーから削除が出来て 便利になるかも知れません。
又 同じ 情報を得て動く BwFwButn OnScroll も 此の コンテキストメニュー実装の付加コードは 1.5 Kb ぐらいなので切替の 出来る様にして付加して行こうかなと思います。

　　＊ 2015/01/30 ファイル フォルダーの 更新 作成 日時参照 について。
此処にあるソフトの幾つかは ファイルやフォルダーの 更新 作成日時を表示したり 内部で比べたり 利用したり している物がいくつかあります。2014年 年末までは 此までの FAT の型式と合わせる為と 前から使用していた為に 内部的には DOSDATE DOSTIME の形で処理をしていましたが さすがに FAT はそろそろ古い と言う事で 新たに SYSTEMTIME 型式に変えました。此の方が内部型式は 単なる WORD の並びになり計算や表示はループ処理が出来て楽に なります。又 NTFS では 1000ms 単位まで記録する事が出来るので 此も考慮に入れる事が出来る様になります。 最近の LHAComp と 本日の ClipName の Date Time は此を反映して 1000ms 単位までにしています。通常は 1000ms 単位は 目にしないと思いますが ファイルの古い新しいの判断は 1ms 単位まで有りますから 何かの参考になるかも 知れません。ただ 先に述べた様に 此は NTFS の話で FAT FAT32 共に以前の DOS 型式記録ですから 2秒単位で それ以下は無しです。残念ながら 多くのと言うか殆どの デジカメ等の カードメモリーを使用する物は カードを FAT でフォーマットしますから 此の 2秒単位の呪縛から逃れる事は出来ません。

　　＊ 2014/12/20 フォルダーの 作成 更新 参照 ( アクセス ) 日時 について。
ファイルの 作成 更新 参照 ( アクセス ) 日時 と言うのは通常のプロパティーの事で割と解りやすいものですが フォルダーの作成日時は直感的だしプロパティーでも出るので解りやすいのですが フォルダーの更新 参照 ( アクセス ) 日時 は プロパティーにもでないので何となく解りにくい感じです。
通常は フォルダーのプロパティーを開くと 作成日時しか出ないのですが 内部的には 更新 参照 ( アクセス ) 日時も変わっています。此は NTFS の場合で FAT の場合は 作成日時しか正確でない様です。
フォルダーの更新日時はそのフォルダーの中身が変わると 例えば フォルダー や ファイルが作られる 削除 されると 変わる様です。ファイルの上書き保存や 子フォルダー以下のフォルダーファイルの新設 削除も更新時間には ならない様です。参照 ( アクセス ) 日時 はそのフォルダーを開いただけでは変わらず あまりはっきりしませんが 殆ど更新日時と連動している様です。フォルダーのプロパティーにも 作成日時 しか出ませんし フォルダーを コピーすると 全ては作成時間に統一されてしまいます。ただ フォルダー を移動した時には全ての時間は以前の 時間を持ち越して移動される様です。実質的にはあまり意味の無い話になりましたが参考までに書いてみました。

　　＊ 2014/08/25 説明テキストで使用している排他的トグル動作について。
此処にあるソフトの中の説明テキストやヘルプの中で 排他的動作 や 排他的トグル動作 と書いてある部分が何個か見られるかと 思います。特に 排他的トグル動作 と言う言葉は はっきりした定義が有る訳では無く いい文言が無いので 勝手に使用している のですが これらの事を いつかは説明しておかなければならないとは思っていました。
プログラムを立ち上げる時に コマンドライン SW で動作を規定する事は良くあります。コマンドライン SW を入れるのは ショートカットのプロパティーで入れる事になるのですが此を入れたショートカットを再度編集して 此の SW を除くのは 結構面倒な事です。そんな事で プログラムを立ち上げる時に同時に Shift キーを押していれば 此の SW と同じ機能が 出る様な仕様にしているプログラムが何個か有ると思います。それでは コマンドライン SW が入っている ショートカットを 立ち上げる時に Shift キーを押しているとどうなるか この時 コマンドライン SW をキャンセル出来れば同じショートカットを 編集せずに 2通りに使用出来ます。此の様に コマンドライン SW で指定するか Shift キー で指定するか どちらか一方の 時には 指定機能 どちらも指定していない時 又は どちらも指定している時も 通常機能で立ち上がる方が便利に使用出来ます。
此の様な事をプログラミングで行う時に 排他的論理和 ( XOR ) を使用すると簡単に実現出来るので 排他的動作 や 排他的トグル動作 ( ON OFF 動作 ) と言う 文言を使用して説明しています。特に コマンドライン SW が多数有り 立ち上げ時の 同時押し キーも何個か有る時には ビット毎の排他的OR で処理するとコード効率がかなり良くなり殆ど１回でその後の動作が 規定出来る様になるので 問題の出ない限り使用していこうかと思います。

　　＊ 2014/08/11 立ち上げ時から管理者権限で立ち上げるには。
此処にあるソフトの中で最初から立ち上げて他のプログラムに何かをする物がいくつかあります。
その中で CabwcPos は 操作対象が フォルダーウィンドウ限定なので特に問題にはならないのですが CabFixer OnScroll BwFwButn は操作対象がどういう物か特定出来ず ( 色々な物を相手にする ) ので 2014/01/20 のテクニカル インフォメーション に書いた様に自分が通常の権限で立ち上がっている時に 相手が管理者権限で動いている時には動作が限定されて期待された動作が出来なくなります。
管理者権限で動いている物は意外と多く ( インストーラー等も此です。) 相手にするプログラムによって 挙動がそれぞれ違うのは あまり嬉しくないという事で最初から立ちあげって他のプログラムに何かをする物については 管理者権限で 立ち上げる方がいいのではないかと思う様になりました。( Windows Vista 以降の話です。)
ただ スタートアップで 管理者権限 で立ち上げるのは テクニカル インフォメーション で書いた様に難しく ( ほぼ失敗します。 ) 此を確認も無くするのは タスクスケジューラーから立ち上げるのが確実で トリガーは ログイン 若しくは立ち上げで 全般タグの中で 最上位の特権で実行する にセットして実行するのが良いのではないかと思います。
こうしておけば相手によって挙動が変わる事も無くなります。但し 管理者権限 で立ち上げた物から立ち上げられたプログラムは 暗黙の内に 管理者権限 で立ち上がりますから CabFixer のデスクトップメニューや BwFwButn のコマンドから立ち上げられた物は 管理者権限 で立ち上がってきますから 逆に他での挙動が ( 通常の権限でのプログラムとの兼ね合いが ) 変わってくるかも知れません。

　　＊ 2014/05/10 クラス名とタイトルの指定方法について。
此処にある何個かのプログラムは デスクトップにあるウィンドウを コマンドラインで指定する時に クラス名と タイトル名で指定する方法を採っています。此はコマンドライン指定では妥当な方法だと思いますが クラス名は ともかく タイトル名の指定方法で柔軟性が有る物は 文字列の部分一致方法を採っている ClsClose の指定方法しか 有りません。ウィンドウを指定する時にクラス名はそのクラスで変わりませんから指定する時に柔軟性は必要ないと 考えられますが ( かえって柔軟性が有る方が指定以外も入ってしまって指定しにくいかも知れません。) タイトルの 方は比較的長いものも多く 又 同じウィンドウでも変わる事も多いと想われます。( 例えば エディター等では ( 更新 ) と出たり プログラムによっては修正した時に * が付くとかです。)
そんな事で タイトルで指定する柔軟性を関係するプログラムで上げていこうかと想います。今まではまさしくタイトル 文字列でしたが 具体的には 含まれる文字列 ( 部分一致 ) で良い事にして 大文字 小文字を区別しない方が使い易いかも 知れません。又 時に よっては 排除文字列を指定出来た方が良い事も有るでしょうし 今まではタイトル文字を指定しない 時には タイトルは 何でも OK でしたが タイトルが無い物を 指定出来た方が良い時も有るでしょう。
柔軟性を上げるとウィンドウの取り違いが多くなる事の懸念も有るかも知れませんが そんな時には 以前の様に長くて 全てを指定したタイトルにすれば良い事ですし 部分一致で試用してみると 今までの様に All or Nothing 的な 指定方法 より タイトルに何らかを指定出来るので より確実な指定が出来る様になっていると感じます。

　　＊ 2014/04/10 ドライブの準備時間 について。
事 コンピュータ物で ドライブの付いている 特に CD や DVD 等の リムーバルディスクの付いている物の宿命でしょうか 此のディスクを確認に行った時に此が準備が終わらずに応答を返さないと此処で固まってしまって結構待たされた 経験は 何方もお持ちだと思います。此は コンピュータ だけでなく テレビ録画の HD 付き BR / DVD レコーダー 単なる CD / DVD プレーヤー等にも当てはまる事で 私などは待たされるのが嫌で CD や DVD を入れるタイミングや 順序を 考えたりしています。
一番典型的に解るのは 新しく DVD や CD を入れてすぐにマイコンピュータを開いてみて下さい。ドライブの準備が 出来て此が応答を返すまで マイコンピュータの中はグレーのままで 同じプロセスで開くエクスプローラー( フォルダー 表示ウィンドウ ) は他の事が出来なくなってしまいます。特に CD DVD BR 等の Multi ドライブで 規格も何でも 読めます能力の ドライブは ああでも無い こうでもないと 私の環境では 準備に 40秒以上かかるようです。
この様な 事を待たない為にと SbFolder には /-M と言うコマンドラインオプションを付けています。此は SbFolder が ドライブメニューから始まる時には リムーバルディスクの内容はチェックしないと言うオプションで 此により 準備中のドライブ 又は 応答の遅いリムーバブルディスク が有ってもすぐに HDD のメニューだけは正しく出して始める 事が出来る様になります。( もちろん 確認しなかった ドライブのメニューはグレーになってはいますがマウスカーソルが 置かれて指定されれば確認に行きます。) /-M が無い時には 先程の マイコンピュータ状態で 作業中ドライブが有れば かなりの間 作業中 で固まった様に反応を待つ事も出てしまいます。
此の /-M オプションは 此で良かったのですが 経歴ファイルの反応を良くする為に メニューが出ている間に予め 経歴ファイルを調べておく先出しルーティンが 経歴項目に此の準備期間中のドライブが有ると 結局此をズーッと待つ事に なり メインのメニューが新たにすぐにポップアップしない ( いつかはするのですが ) 事になってしまうのに気が 付きました。
まあ 予め リムーバルディスク を入れて置けば良い話ですが 常にそういう順序と言うのは 出来ない話だろうと思いますし 最初に言った様に コンピュータ物でドライブの付いている製品についてはあきらめるしか無いのでしょうか。 認識時間 1秒とかの DVD ドライブが有ると助かるかなとも思いますが 電源オプションで ハード ディスクの電源を切る に 入っている時の HDD からの リカバリーも結構時間がかかりますから無理な話かも知れません。CD DVD 等の リムーバル ディスクドライブも ディスクが入って認識済みになっていても ファームウェアーはより勝手にパワーダウンさせて お休みさせていて 立ち上げるのに時間のかかる事も有るようですから。

　　＊ 2014/03/02 CabwcPos Ver.1.200 について。
02/10 に Windows 7 8 の フォルダー表示のウィンドウ ( エクスプローラー ) の 最後に 閉じた位置とサイズを 記憶して 次に開く時にそれを再現する CabwcPos を新たにアップしまして 此が Windows 7 8 で軽快に作動し結構 有効な物でしたが その後 必要な事を整理すると 新しく フォルダー表示のウィンドウが開かれる時の動作 又 此が閉じられる時の位置とサイズを記憶すればそれで動作は完結するとの結論に達しました。( まあ はっきり 言って 当たり前の事です。) ところが 閉じられる時の位置とサイズは システムは 閉じる前に此のウィンドウを デスクトップの見えない所に移動しているので 此の 位置を記憶する訳にはいきません。したがって どうしても 見えて 現存しているうちに位置とサイズを記憶しておかなければならないので Ver 1.000 では予め定期的に プラス 機会を見てデスクトップの状態を探っていたのですが メッセージを予め取得する方法を見ていると 各ウィンドウの サイズが変更された時もメッセージを取得出来る方法が有りました。此を使用すると 開かれた時 閉じられた時 サイズが変えられた時 が全て取得出来る様になり 予め定期的にと 機会を見てデスクトップの状態を探る必要も 無くなり メッセージを待つだけの動作で事が済む様になりました。したがって常駐している時に 必要の無い時には メッセージを待つだけで何もしなくてよい事になり システムへの負荷も大幅に軽減出来る様になりました。 又 余分な 機会を伺う コードも無くなったので サイズももう一段小さくなりました。

　　 ＊ 2014/01/20 Vista から 導入された UAC について。
Windows Vista から UAC ( User Account Control ) と言う セキュリティ向上の為の仕組みが導入されました。 此は 此で良い事ですが この機能によって此処にある 他のプログラムに何かをする ( ウィンドウの位置を移動するとか テキストをリクエストするとか ) 何個かのプログラムの内で相手が 管理者レベルで動いている時には リジェクト されてしまい本来の機能を完結出来なくなる物が出てきてしまいました。此は此で そういうウィンドウズの仕様だとあきらめれば 良いのかもしれませんが 此を回避する方法も有り 他の管理者レベルで動いているプログラムに何かをする時に 此の UAC 機能に よって リジェクト された時には 自分も立ち上がる時に 管理者として実行 されれば 通常どうり作動する事になります。
又 管理者レベルで動いている プログラム ( ランチャー等 )から立ち上げられたプログラムは 管理者レベルを引き継いで実行 される様です。したがって 適宜 右クリックメニューの 管理者として実行 とか ショートカットの プロパティー の 互換性タブ の 管理者として此のプログラムを実行 チェックボックス 等を使用するのも良いかも知れません。但し UAC の設定にもよりますが 確認のダイアログが出る事になるのは避けられません。したがって 最初に 立ち上げる物で スタートアップで常駐させる物を 管理者として実行 させるのは多少工夫が要るかも知れません。

　　 ＊ 2013/11/15 アクティブなウィンドウのマウスホイールでのスクロールについて。
ウィンドウがアクティブな時にはマウスホイールでスクロール出来る。此はごく当たり前の常識です。ただ スクロールさせる物が 1つだったり スクロールさせたい物がフォーカスを持っていれば問題は無いのですが ウィンドウによっては 2 ペイン だったり 3 ペインだったりして アクティブな時はマウスホイールを廻しても フォーカスを持っているコントロールがスクロールする様に出来ています。
ソフトによっては 左のペインの TreeView で選択した物が 右ペインの リスト や ListView に反映される物が 結構有るかと思います。( Regedit や イベントビューア やら システムツールは 殆どこの形を取っていると思います。) この時 左ペインで選択した内容が右ペインに出るのですが リストされた項目がたくさん有ってスクロールしないと下の方が 見え無い事も良くあります。此の下の方を見る為に スクロールホイールを廻しても 選択した後にフォーカスを持っているのは 左ペインですから スクロールするのは左ペインです。
インアクティブな時には OnScroll 機能でマウスカーソルの有る方がスクロールしたのに アクティブな時にはかえって 不便を感じる様になってしまいました。まあ そんな時のために Tab キーでのフォーカスの切り替えが有るのでしょうが 単に下の方を見るだけの スクロールの為に Tab キーを押すのも冗長かなとも思います。
そんな考えから アクティブな時もマウスカーソル直下のウィンドウにはスクロール信号を送るオプションを 付けました。此なら アクティブ インアクティブ にかかわらずマウスカーソル位置の物を スクロールさせる事が出来ます。 ただ システムが出すスクロール信号を止める訳では無いので アクティブな時は マウスカーソルが直上に無くても フォーカス の有るウィンドウはスクロールしてしまいます。
又 プログラム的にはアクティブな時にマウスカーソルが 直上に有る フォーカスを持っているウィンドウには システムがスクロール信号を送るので 此の スクロール信号を送らないのが筋で 最初はその様にコードも書いたのですが 此を無視して何時でもマウスカーソルが直上に有るウィンドウにスクロール信号を送る様にすると マウスカーソルが 直上に有る フォーカスウィンドウ は 2倍速スクロールになるので それも捨てがたく ( どんなウィンドウでも 2倍速になる 訳でも無くてこの辺は そのソフトの作りによるのですが ) 最初に有ったフォーカス確認コードは 敢えて無くしています。
マウスの操作だけで ながら的に一覧する時にはなかなか楽になったかな と思います。( 所謂 何処でも 何でも スクロール と言う所でしょうか。)

　　 ＊ 2013/10/20 インアクティブウィンドウでのマウススクロールホイール使用について。
マウスのスクロールホイールは大変便利な物で ソフトも殆ど此に対応しています。( 横スクロールについては まだまだだと思いますが。) ウィンドウを並べたり一部重ねたりしながら一方を参照しながら作業していると 此の下にあるウィンドウをスクロールしたいと言う必要は結構ある事だと思います。そんな時通常だと ホイールによるスクロールはアクティブウィンドウにしか効きませんから 一度下の物をアクティブにして スクロールして 又 作業中のウィンドウをアクティブにすると言う繰り返しになります。
ある種のマウスドライバーが オプションで マウスカーソル下のウィンドウをインアクティブでもスクロールする と言う機能が 特定マウスに限ったドライバーで有ったと記憶します。そんな機能を汎用に実現出来るソフトも 有るのですが 今回 BwFwButm で使用した マウスの状態を直に取得出来る XP から実装された機能で マウス メッセージをフックしなくても スクロールホイール機能が使用出来る事が解ったので 此をプログラムして OnScroll を作成しました。マウスメッセージをフックして下流に流さない操作は していない ( 出来ない ) ので アクティブ ウィンドウも同時にスクロールする事も有るのですが ( 此の辺りは 個々のソフトの作りと構造によるかと思いますが テキストエディター や NotePad 等を ２つ並べて 内容を比べる時等には アクティブな物と インアクティブな物が 同時に スクロールするので かえって便利な時も有ります。) メッセージフックより扱いがずいぶん楽になるし反応も良いので こちらも良いのではないかと思います。 どちらにしてもマウスカーソルだけそこに持って行ってホイールを廻せば OK なので アクティブな時は フォーカスを 変えなければならないのが インアクティブな時はマウスオーバーだけで出来るので オーディオミキサー等の ボリュームコントロール等を変えるのにはかえって便利になる様な気がします。
此の辺のプログラムに興味の有る方は プログラムティップス もご覧になって下さい。

　　＊ 2013/09/30 Win XP からサポートの HID スタックから直接読み取りについて。
前出の 2013/03/02 BwFwHook は 戻る 進む ボタンメッセージを 他のプログラムが使用した後の一番最後で取得してしたので先に使用したプログラムが有るとボタンメッセージは 流れて来なくて反応は出来ません。此は此で 戻る 進む をサポートしたブラウザー上 等には良いとは思ったのですが 出来る物 出来ない物が 自分のコントロール上に無いのは不便な事もあり他の方法も考えていました。
そんな時に Windouws XP から サポートされだした ヒューマン インターフェイス デバイス (HID) スタックから 直接読み取られて メッセージを送ってくれる WM_INPUT を使用する アイディア に行き着きました。( Windows 自体は 新しいキーボードや 高解像度マウスを プログラムが直に扱える様に この API を設定したようです。)
此を使用すると マウスの 戻る 進む ボタンメッセージ を直に取り扱う事が出来 又 一番 上流 でキャッチ 出来るので 必ず反応をするプログラムも作成可能になります。又 メッセージのフックも無くなるので プログラムの 扱いも簡単になります。但し サポートする Window は XP からになってしまいますが 現実的には もう特に問題も 無いかと思います。
此で処理するとフォアグラウンドのウィンドウがどんな物で有ろうと指定コマンドを出す事が出来るので プログラム的にはずいぶんすっきりするのですが 直接読み取りは 単に読み取りだけで このメッセージを下流に流す 流さないの抑制作用は全く有りません。したがって 他のプログラムが反応する様な 要らない時まで反応してしまう 事が有るので 逆に 抑制フィルターを指定出来る様にしました。
反応の早さやキビキビ感を考えると新しい方法の BwFwButn が 良いのですが Windows 2000 の事を考えて当分 BwFwHook も残しておこうかと思います。

　　＊ 2013/08/25 パソコンのオーディオボリュームコントロールについて。
　パソコンのオーディオボリュームコントロール と言えばミキサーパネルからWave や SW シンセサイザー CD Line 等 各々の入力レベルを調整して 最終的には スピーカーのメイン音量を決める。と言うのが通常の方法ですが 音楽の MP3 WMA OGG ACC だの 映像の MOV MPG MP4 WMV M2TS だの色々な種類の物を再生し出すと殆どは Wave 経由で 音量は その都度変わるし 又 プレーヤーが変われば音量が その都度変わる。又 プレーヤーによっては ボリューム コントロールも色々な仕方が有るようです。
この頃の プレーヤー は音量は自分の内部的な ボリュームコントロールで行いグローバルなミキサーは変えなく なってきている物が多いようです。又 Windows Vista からは グローバルなミキサーも変わり同じ Wave でも プログラム毎に現れる様になり XP までの様に 1つの Wave ボリュームコントロールでは無くなった様です。 この為 以前の Wave ボリュームコントロール は仮想化されて此をコントロールしても音量は変わらなくなってきて います。此ならある プレーヤー の時は常に同じ音量で問題は無いのですが 新しい物でもプレーヤーによってはまだ グローバルなメインボリュームと自分のボリュームコントロールと連動と言うのも有るようです。
結局 オーディオボリュームコントロールを調節しなければならない訳で Wave が1つで共通して行っている XP 以前は 調節機会がより多くなります。ミキサーパネルを出すのも結構な手間ですしスライダーをいつもの場所に置くのも 気を遣う と言う様な訳で オーディオボリュームをコマンドライン指定でセット出来るプログラムを作る事に しました。但し Win Vista からはミキサーコントロールは仮想化されて仕組みが変わっていますから今までの mmsystem API でのプログラムではコントロールは動かせるのですが効果は有りません。( 音量は変わりません。) まあ 使用機会の多い Win XP 以前 用と言う事で良いのではないかと思います。

　　＊ 2013/06/25 自分がフォアグランドにならない動作について。
　通常 ウィンドウは何らかの子ウィンドウのコントロールを持ち何らかの機能をする様に作られているのですが 何かをさせたり機能を切り替えたりする時にはマウスの左右クリックとかキー入力とかが必要な訳で此の様な時には 普通のやり方だと自分がアクティブ ( フォアグランド ) になる事になります。自分が アクティブ になると言う 事は アクティブ から インアクティブ になるウィンドウが有る訳で この インアクティブ になると 様子が変わって しまう ウィンドウが多々あります。
例えば フォルダー表示のエクスプローラーの名前の変更の窓はインアクティブになった瞬間に閉じてしまいますし インアクティブ になって 再度 アクティブになった時には フォーカスの有るコントロールが失われるとか フォーカス は以前の物を取り戻しても キャレットの位置が違うとか選択範囲は失われるとか 以前の状態がそのまま 再現される保証も無いし そのまま再現されるのは希でしょう。
此の様なウィンドウにテキストを貼り付けるには 予め クリップボードにテキストをコピーしておいて貼り付ける事も 考えられますが 予めが出来ていなかったり 貼り付けるテキストが複数だったとかした場合にはお手上げになって しまいます。
此までの ClipSaver でも 出来るだけ 以前を再現するように フォーカスコントロール キャレット位置 選択範囲を 相手が アクティブ な時に記憶して 再度相手を アクティブにした時に 同じ様な状態になるようにはしている のですが 全く同じように再現するには限界も有り さすがに入力ウィンドウを閉じられた物には無力になって しまいます。
此の様な時のために 今まで コントロールキー + リストの上でのマウスカーソルのムーヴという方法で自分が アクティブでなくても貼り付ける事は出来ましたが それ程使い勝手もスムースでなく まあいざとなれば出来る 程度の物でした。
本日の ClipSaver から この自分がアクティブにならなくてもフォームのコントロールを操作出来るように オプションで 内部タイマーをセットして機能させる様にしました。もちろん 自分がアクティブになれない訳ですから メニューは出せませんし場所も変えられませんが 相手をズーッとアクティブにしておいて 必要な所に必要な数だけ はリストを出す事が出来る様になりました。

　　 2013/06/01 デスクトップに新しく作成表示されるウィンドウについて。
　此処 ソフトの小物たちに有る プロフラムで デスクトップに新たに表示されるウィンドウを認識して此を相手に 何かをするソフトがいくつかあります。例えば SetDetail CabFixer BwFwHook TaskSwck 等です。これらのソフトは 何らかの手段でデスクトップに表示されるウィンドウを認識しようとする訳ですが 新しく デスクトップに現れる ウィンドウは通常は最初フォアグラウンドウィンドウとして出てきます。( フォアグラウンドウィンドウで無い物も 現実にはあり得るのですが ) ただ フォアグラウンドウィンドウ として出てきても 見えるとは限りません。 不可視のウィンドウでもフォアグラウンドウィンドウとして現存出来ますし 又 フォアグラウンドウィンドウ として 有るのに まだウィンドウの内部は 出来ていないと言う事もあり フォアグラウンドウィンドウとして認識されて 全てが終わって 表示されるまでに 10秒以上かかる事も有るようです。
ご存じの様に Windows は Multi Task OS ですから それそれの Task はタイムスライスで実行されています。 Windows ME ( 98 ) まではこのタイムスライスもいい加減で 各タスクが切りの良いところまで使用できた様なの ですが Windows NT 2000 になってから タイムスライス はきっちり切り替わる様になり 新たに作成表示される ウィンドウも途中のまま 他のプログラムに順番が回って来てしまします。
こんな時に この作成中のウィンドウを認識すると まだ 子ウィンドウも出来ていない 可視にもなっていない と言う事もあり得ます。此の様なウィンドウを相手にするのに 出来るだけ早い時期に相手にする候補に相当するか どうかを判断して余分な待ちをしない様に見切りたい所です。この見切りを間違えると今度は 本来は不可視の ウィンドウを 延々と意味無く待って 自分の他の機能が滞ったり 早く見切りすぎて肝心な相手を見落としたり します。
結局 色々なタイムディレイが有るのですが 即判断するのは難しく 確かなのは最初に取得したウィンドウスタイルは 後の事を考えて CreateWindow をされているので その ウィンドウスタイルで大まかに判断して 有る程度したら 子ウィンドウの存在を確認して 候補なら可視になるのを有る程度の時間待つと言う動作にするのが間違いもなく かえって無駄な待ちも無くなる事になる様です。
全ての存在するウィンドウを調べると 可視でもなく 子ウィンドウを持ち システムメニューまで持つ物も有る 様ですがそういう物は表に( フォアグラウンドに )現れて来ないと言う前提で考えれば 全般的には 間違いも 少なくなり 余分な待ちは無くなって この部分での引っかかりも無くなったのではないかと思います。
此の様な話は テクニカル インフォメーション よりも プログラミングチップスの方が良かったかも知れません。

　　 ＊ 2013/05/05 ドライブを指定して USB 接続機器をディスコネクトする 機能について。
　ブロードバンドルーターのファームウェアーをアップしたらそれまでは USB メモリータイプの機器しか認識 出来なかったのに HD タイプのストレージも認識出来る様になりました。此はちょうど良かったと言う事で 余った SSD を入れた物をルーターに繋いでLAN全体のデータストレージとして使い出しました。スピードも 以前より速くなり都合は良くなったのですが 容量が大きくなった分だけ ルーター廻しの遅さも気になりだし 結局 大きなデータを書き込む時には USB 接続で取り扱う事になりました。
ただ この HD に見える USB ストレージ を Windows 7 8 で取り扱うと タスクトレイの通知領域に USB 記憶装置を 挿入しても ハードウェアの安全な取り外し のアイコンが出なくて 書き込みが終わっていればいきなり外しても 良いと言われても何となく不安がつきまといます。USB メモリー等のリムーバルメディアとして認識される物は 以前から有る EjctClse でも取り外しの準備が出来るのですが HD ディスクとして認識されるドライブでは安全な取り外し をするためにやはり何らかのプログラムが有った方が良いだろうと言う事で ドライブレターを指定して USB 接続の 場合はディスコネクト出来る USBremove をアップしました。
ディスコネクトする前に読み書きしていないか確認して バッファもフラッシュしてから作業に入るのでかなり 安全です。又 プログラム的には リムーバル HD( Fix ) FD CD-ROM に見える物にも対応しています。

　　 ＊ 2013/04/02 立ち上がる時にアクティブウィンドウを参照するプログラムについて。
　通常のと言うか普通の独立したプログラムは自分自身が立ち上がって何らかの動作をして終わるかそのまま 居続ける訳ですが 此とは別に 相手有っての動作をするプログラムのうち 自分が呼ばれた時に デスクトップにある アクティブウィンドウを見て動作をするタイプのプログラムも有ります。
此処の ソフトの小物たちで言えば ClipName や ClsFoldr CabFixer TaskSwch 等でそれぞれ色々な方法で 立ち上がった時や 動作をする前に アクティブウィンドウを取得する様にしています。
CabFixer や TaskSwch 等は 常駐している物ですから タスクトレイでの マウスムーブ やタイマー等で現在の 状態を取得しています。ClipName や ClsFoldr は フォルダーの右コンテキストメニューから呼ばれる事が 前提で この時には アクティブウィンドウは 表示フォルダーになります。
それでは 此の様なプログラムをランチャーの様なソフトから立ち上げるにはどうしたら良いのでしょうか。 スタートメニューからは出来ません。スタートメニューはメニューを立ち上げた時にはタスクバーが アクティブウィンドウになってしまいます。ランチャーもプログラムの一種ですから何か動作をさせるには 特別な工夫をしない限り 自分がアクティブにならなくてはいけません。自分がアクティブになって 他の プログラムを立ち上げる直前に自分が動作を起こす前のウィンドウをアクティブにしておけば この様な 用途に対応できますが 自分が動作を起こす前のウィンドウを常に把握するのは自身は常駐型になり 何らかの 情報を常に取得していなければならず ランチャープログラムには若干の負荷かなと思います。

　　 ＊ 2013/03/02 マウスのサイドボタンに任意のプログラムを割り振る BwFwHook について。
　私自身は普段から サイドに 2個 ボタンの付加された ( デフォールトでは 戻る 進む ボタン ) マウスを使用して います。別に ブラウザの 戻る 進む に利用する訳ではなく 此のボタンにそれぞれ タスクスイッチャー機能の プログラムと他のテキストコピー用のプログラムを割り振って使用しています。特に タスクスイッチャー機能を サイドボタンから起動出来るのはデスクトップが ウィンドウで重なり合ってぐちゃぐちゃになっている時には非常に 有用で これ無しではいらいらして作業効率が落ちてしまう程です。
此の機能は もう 15 年ぐらい前でしょうか Logcool の サイドボタン ( 1つしか無かった ) マウスに マウス ドライバーを入れるとタスクスイッチ機能が使用出来る様になったのが最初だと記憶しています。
その後 マイクロソフトとロジクールは サイドボタンが普通に2個ついたマウスを発売していましたが日本のメーカー は なぜか なかなかサイドボタン付きのが無い時代が長く 結局 マイクロソフトとロジクールを選択するしか無い事が 多かった様な気がします。
マイクロソフトはインテリポイント 5.2 ぐらいで サイドボタンにユーザーが決めた任意のタスク ( プログラム ) を 立ち上げる機能を付けたので長い間 マイクロソフトマウスを使用していました。ロジクールの方はいつのまにか サイドボタンの機能割り当てから プログラム立ち上げ機能が無くなってしまったようです。
ただ 此処 2年ぐらい前から マイクロソフトはマウス事業から殆ど撤退の様相を見せています。確かにマウス ドライバー インテリポイントはそれなりに アップして Windows 8 対応にもなっているし サイドボタンへの 機能のアサインもそのまま残ってはいるのですが 何となくインテリキーボードと統合されそうな感じだし インテリポイントもどんどん肥大化して インストールするのに 30〜40Mb と言うのはベラボーな気もしますし ( サイズは ロジクールも同様 ) 何しろ肝心なマウスが無くなってきました。残った コンフォートマウス 6000 を使用しても 全く コンフォートでなく作業が中断されそうな感じです。古い サンワのマウスが サイドボタン 割り振り機能が有ったので ここの所使用していたのですが 古くなったので買い換えようにも 新しい物は 割り振り 機能が無くなって来ている様です。
そんな状況でしたが この頃の Buffalo と エレコム のマウスは サイドボタン を きっちり付けてきている物が 多くなって 使いやすそうな雰囲気です。Buffalo も エレコム も ドライバー と言うか ユーティリティー を用意して サイドボタンに何かをアサイン出来ると宣伝していますが 肝心な ユーザーが決めるプログラムの項目が無くて 割り振り出来るサイドボタンで notepad を立ち上げてもね とも思ったり マジに 立ち上げたい プログラム名を notepad,exe と変えて Windous フォルダーに入れておこうかなと思ったりもしていました。
そんな マウス選びのもやもやを解消するには もう自分で作るしかない。と思い立ったので プログラムを 始めました最初は何からメッセージを取得すれば良いか色々迷いましたが 試行錯誤の末 確かに 戻る 進む メッセージをプログラム上で取得する事が出来る様になりました。但し ブラウザや 戻る 進む をサポートしている プログラムがフォアグラウンドにある時には 此のメッセージは これらが使用して下流に流れてきません。 又 気をつけて見ていると 戻る 進む は押した時のマウスカーソルの下にあるウィンドウをアクティブ ( フォアグラウンド ) にしてから メッセージを送る事が解りました。したがって マウスカーソルを ブラウザ上ではなく此を避けた所で押せばブラウザがアクティブで有ってもサイドボタンを押した時にブラウザを インアクティブにしてくれるので すぐにメッセージを取得して 使用出来ると言う事で 無理をしないでこの状態のまま 使用する事にして ブラウザのアクティブな時には 本来の 戻る 進む その他の時には 指定した 立ち上げ機能 と都合良く使い分ける事にしようと方針が決まりました。
決まった 後は プログラムをするだけですから それ程規模の大きな プログラムでは無いので コーディング自体は 大した手間では無かったのですが 安定して ON OFF 出来る様にするのに 又 結構 試行錯誤が必要でした。
こういうプログラムは ウィンドウズの違いが大きく出そうだなと思いながら 使用してみると わずかな 調整で 非常に安定して動作する事が解りました。又 色々なメーカーのマウスを( もちろん 2 サイドボタンマウス ) 取っ替え引っ替え使用してみると 全く再立ち上げも無しで連続して同じように使用出来る事も解りました。
ウィンドウズの違いも XP Vista 7 8 と ( 残念ながら 2000 では確認出来ませんが ) 何のトラブルもなくそのまま 通りました。( こんなにすんなり全てのウィンドウズで OK 確認出来るのも珍しい事です。) 使用感も全く同様でウィンドウズの違いを感じさせません。
上記の様な結果だったので 現在 私の持っている全てのコンピューターから マウスドライバー ユーティリティー の類は全て アンインストールしてしまいました。それでも 此の BwFwHook を入れておく事で メーカーが違う マウスで ボタンが 戻る 進む さえサポートしていれば繋ぐだけでいつも 同じ様に使用出来る事になりました。
これからは マウス選びは 見ただけで 良さげな 2 サイドボタンマウスを選択するだけだと思うと 大変にすっきりします。
此の改良版 BwFwButn の事もその後 前の方で書いています。

　　 ＊ 2013/02/09 SbFolder の Windows 8 でのメニュー表示色対応について。
　Windows 8 になってから プログラムチップスに書いた様に メニューの淡色範囲が変わった様で この為 SbFolder でファイルを現す部分のメニューが通常の黒ではなくて 薄い色の淡色表示になってしまいました。此でも特に動作には問題は無いのですが 淡色表示だと常識としても 何となく選択出来ない様な印象なので 通常の黒文字にしたい所です。
プログラム的には 此までは SbFolder は ポップアップメニュー以外は全て メニューとしては淡色では無いけれども 無効と言う扱いにして 選択されたのも 終了するのも 全て プログラム的に コントロールしていましたが Windows 8 で 淡色表示を避ける為に有効なメニューに変えた事で 此のメニューを選択されると全体が終了されて しまう事になるので内部的な プログラムは結構変わりました。とは言っても 新しい 物は 見た目も 動作も殆ど 変わりません。
個人的には 選択も 終了もプログラムでコントロール出来る以前の方が都合は良かったのですが変わってしまった 物には対応して行かなければいけないのでしょうが なぜ今更 此の様な動作仕様に変えたのかの必然性が解りません。

　　 ＊ 2012/01/30 Windows 8 の USBメモリー等の安全な取り外しについて。
　Windows 7 8 共に 意識的に設定しない限り USBメモリー等の安全な取り外しのアイコンはタスクトレイに表示は されないのですが プログラム的に 此のドライブを取り外しをすると Windows 7 では タスクトレイにアイコンが 無いにもかかわらず　 "安全に取り外せます。" のメッセージが出たのですが Windows 8 になってから出現しなく なってしまいました。
又 １つの機器で 複数の ドライブをアサインする メモリーリーダーも 各々のカードは 取り外せているのに どのバージョンのウィンドウでも タスクトレイからのメッセージは出ません。
この様な事情で 一応 切断確認を確かめる為には何らかのメッセージを出した方が良いのではないかと言う事で EjctClse にオプションで プログラム的に切り離せた時には メッセージを付ける事にしました。
まあ 何もしないで引き抜くより 今までも EjctClse で取り出せば OK だったのですが メッセージが出た方が より 安心かもしれません。
又 此までは メディアが 読み出し 書き込み をしている時にも 此を オーバーライドして 取り出し動作を始めたのですが そのような時には 動作をしないで 警告メッセージ を出すだけにして より安全性を高めました。

　　 ＊ 2012/11/27 Windows 95 / 98 / ME の 送る からの コマンドライン対応について。
　本日アップした LHAComp は 2001/10/11 のテクニカルインフォメーション にも関連した Windows 95 / 98 / ME からの送るからのコマンドライン で長いファイル名や 途中にスペースが 有る場合等に起こる 8.3 形式の場合に 此を展開してから代入する事の対応の必要性は少ないと考えられるので 8.3 形式 から ロングパス名への変換コードを無くしました。
此は そろそろ 95 / 98 / ME への対応は必要ないだろうと考えられるのと 送る から LHAComp を使用する 機会も そう多くはないと思われるので NT 系のウィンドウの方を主体にする事にしました。
したがって Windows 95 / 98 / ME で LHAComp を どうしても 送る から使用すると言う方は 古いバージョン ( 2012/07/25 Ver 2.214 ) の物を残しておいて下さい。( 本日のバージョンでも 95 / 98 / ME で 送るから使用出来ない訳ではなく 8.3 形式のファイル名であった時にこの名前で 圧縮 解凍 してしまうと言う話です。)
Windows NT 系 2000 / XP / Vista / 7 / 8 の方は ただ 本体サイズが小さくなっただけで何の問題もなく 送る から 通常の名前で使用出来る事に変わりは有りません。
[ 12 / 02 ] FileNOer も同じ様に 8.3 形式 から ロングパス名への変換コードを無くしましたがこちらは 8.3形式 でもファイル自体は認識出来て そこから自身の名前を変えてしまうので 実質的には何の問題も無いと思われます。

　　 ＊ 2012/10/18 の ClipName 3.300 からの インストールファイル *.INF ( セットアップ情報 ) について。
　本日の ClipName Ver 3.300 に同梱している レジストリー関連付け操作の為の セットアップ情報ファイル ClipName.inf から 若干 此の inf ファイルの動きを変えて ClipName.inf だけはやはり windows\inf フォルダーに コピーする事にしました。
此は 今までの inf ファイルを動かさない方法だと 此の inf ファイルを削除されるとレジストリー関連付けの アンインストールが出来なくなってしまう為 より削除されにくい windows\inf フォルダーにコピーしておく 事にしました。此で インストールしたフォルダーごと削除されても レジストリー関連付け はプログラムの追加と削除 から確実にアンインストール出来ます。又 コピーされた inf ファイルはこの時点でwindows\inf フォルダーから 削除されます。
以前の2011/11/08 からの インストールファイル *.INF で既に関連付けをインストールされている方は今まで通り ClipName.exe ClipName.dll ClipName.chm を上書きすれば OK です。( ClipName.inf は以前の物を残しておいて 下さい。)
もし 疑問が残る様だったり 後の事を考えるなら 全てのファイルを上書きして右クリックメニューのインストール からもう一度関連付けを再設定していただいても良いと思います。( ClipName.inf ファイルの指定位置が windows\inf に変わるだけです。以前のファイルでアンインストールする必要は有りません。)

　　 ＊ 2012/08/31 子ウィンドウとしてのコントロールのサブクラス化について。
　08/29 にアップした EmpFolder ですが検索結果を表示する 子ウィンドウのリスト は此まで手間をかけるのも 何だから と言う事でそのままの規定のメッセージで使用していました。
まあ 此は此で普通に使用できるのですが 結構検索結果も多く ( 200 個とか ) なると選択するのに一個一個 では時間がかかりマウスで押しっぱなしでずーっと選択する方が便利で有る事は間違い有りません。
この機能を実装するには 通常のリストボックスメッセージレベルではダメで途中でメッセージを横取りして それで実現すると言う事になります。所謂 プログラム的には サブクラス化すると言う事です。 一度 コードを追加すればマウスの動きや キー入力等必要に応じて 実装するだけですからずいぶん使い勝手が 良くなります。
本来は プログラムチップス レベルの話なのかも知れませんが まあ しましたという話で それ程のチップでも ない様な気もするのでこちらの テクニカルインフォメーションに書き留めました。
−目次−戻る−

　　 ＊ 2012/01/17 ファイル名として認められない文字を使用した URL ファイルについて。
　通常はファイルやフォルダーの名前を入力して決定した時には ファイル名には次の文字は使えません: \ / : * ? " < > |　とか出てこれらの文字のファイルや フォルダーは作成する事が出来ない事になっていますが IE のお気に入りをみて下さい。おかしな文字の 名前を持った お気に入りファイル ( URL ) は有りませんか。
ある URL をお気に入りに追加する時に入って来る 名前のデフォールトはタイトルに書いてある文言ですごく 長かったりファイルに使用出来ない文字を含んでいたりします。それをそのまま追加するとファイル名は そのまま入ってしまいます。それはそれで後で IE で開く時には問題は無いのですが プログラムで此の URL ファイルの中を調べようとするとファイルに使用出来ない文字を含んでいるので指定した名前のファイルは 無いと言う事でオープン出来ないのです。ウィンドウズの IE 等は此を開く事が出来るので rundll32.exe shdocvw.dll,OpenURL は何らかの操作をしている物と思われます。ただ ファイル検索等で 使用するファイルの列挙ではファイルに使用出来ない文字を含んでいるファイルもそのまま列挙します。 又 此の様なファイル名のファイルは殆ど ショートファイル名も合わせて列挙してきます。 此のショートファイル名だとファイルのオープンも出来て内容を読み出す事が出来ます。
多少 冗長な所はありますが 01/12 の InvadURL 本日の URLnewop は此の様な操作のバックアップを持たせ ました。読めないであきらめるよりは良いとは思いますが 基本的には ファイル名としてそれらを防止するのが 筋ではないか等と考えてしまいます。
−目次−戻る−

　　 ＊ 2011/11/08 からの インストールファイル *.INF ( セットアップ情報 ) について。
　此処に有る何個かのプログラムはレジストリー関連の関連付け操作の為に セットアップ情報ファイル *.INF を 同梱してあります。此の *.INF の右クリックで出るコンテキストメニューで インストール を選べば 関連ファイルの コピー スタートメニューの作成 アンインストール情報を含んだ レジストリー関連の書き込み とワンセットになった 操作が 此の *.INF だけで出来る訳で非常に便利な物だと思います。此の中身は単なるテキストで通常のエディターで 作成 編集出来るし内容もそれ程難解な物でも有りません。
但し一度エディターで編集してしまうと インストール先が決まってしまい 此のインストール先を選択出来ないのが 不自由と言えば不自由です。もちろん個々にエディターで編集してもらえば何処にでもインストール出来るのですが そんな事が出来る方は 最初から *.INF ファイル等は必要無いでしょう。そんな訳で 此までは インストール先は どんな環境の方にも有る Windows フォルダーに決め打ちして関連ファイルをコピーし レジストリー関連の情報も プログラムが Windows フォルダーにある前提で書き込んでいましたが やはりドライブが複数有ったりするとそちらに とか C:\Windows では ??? とかだったりする事が有るのでは無いでしょうか。( 私自身 プログラムはどこかに 集中的に纏めたいと思います。)
　そんな訳で 本日の ClipName 以降の *.INF ( セットアップ情報 )同梱のプログラムについては 関連ファイルの コピーは やめにしました。その代わり関連ファイルは個々に都合の良い所に自分で決めて置いてください。そこの *.INF ( セットアップ情報 ) ファイルの右クリックで出るコンテキストメニューで インストール を選んで いただければ レジストリー関連の書き込みが終わる様にしました。もちろん レジストリー関連の書き込みを 消去する為に此までと同様に プログラムの追加と削除 に アンインストール情報も出ます。 但し レジストリー関連は消去しますが 関連ファイルは削除しません。( 削除する様にも出来るのですがしない方が 良い事が多い様です。) したがってこれらのファイルは自分で削除と言う事になります。
何となく手抜きが多くなった様な気もしますが この方がインストールする方の自由度が増えるし *.INF ファイルも 失われないので便利な事も多くなったのでは無いかと思います。注意事項としては 以前インストールしている方は 一度 アンインストール して 関連ファイルを良い所において再インストールするのと 此のインストールした フォルダーとそこに有った *.INF ファイルはそのままにしておいて下さい。無くなるとアンインストールが 出来なくなります。
　此までと同様に Windows フォルダーの関連ファイルに上書きしてもそのまま使用できます。プログラム事態は 単なる バージョンアップですから。
2012/10/03 追記
＊ 2012/10/03 Win Vista 7 でのインストールファイル ( *.INF セットアップ情報 )でのセットアップについて。
インストールファイル ( *.INF セットアップ情報 ) での Windows Vista 7 に 関連付けをする時にひょっとすると 右クリック → インストールでは "アクセス許可が無い"とはじかれてインストール出来ない事がある様です。 フォルダーやレジストリーのアクセス権の設定が厳しく設定されていてだめな様です。
そんな時には INF ファイル 右クリックメニュー → プログラムから開く → Windows セットアップ API と進んで 選択してみて下さい。蹴られずにインストール出来る事と思います。

−目次−戻る−