Layout Window 　ダウンロード

Layout Windowは特定のウィンドウを任意のタイミング、
指定した方法で位置やサイズ、ウィンドウ状態を変更します。

主に次の機能を有します。

　・ウィンドウ情報の取得
　・ウィンドウ情報の変更
　・任意のタイミングで指定されたウィンドウ情報に従いレイアウトを実行
　・指定ウィンドウを自動的に閉じる･非表示･強制終了する
　・マウスで指定したウィンドウのみレイアウトを実行

2021.05.15 5.0.1版 ･アプリケーションをフルスクリーン表示時に､ そのアプリが自動で画面中央に表示するように設定されていた場合､ 一部のアプリにおいて､タイトルバーの高さ分､上部にずれて表示される問題を修正

2020.04.04 5.0.0版 改善 ･自動レイアウト実行時のCPU負荷を0にした 　従来はcorei7環境でも定期的に5,6%程度消費していたが､今版からは事実上無負荷にした ･レイアウトの反応速度を更に高速化 変更 ･｢実行契機｣から｢自動(常に)｣､｢自動(起動時のみ)｣｢自動(OS終了時)｣を 　アプリ起動時のみ自動でレイアウトを行う　｢自動｣　に統合した ･新規ウィンドウ追加時の実行契機のデフォルトを｢手動｣から｢自動｣に変更 ･メニューの｢ウィンドウの監視｣､｢ウィンドウ検知の高速化｣を無効化 　将来的にメニューから削除予定

2018.10.25 4.0.4版 ･休止状態から復帰後､自動レイアウト(実行契機に｢自動…｣を指定)が 　効かなくなる問題を修正 ･レイアウト対象のプリケーションの起動を高速に検知する機能を 　デフォルトで有効化した 4.0.1版で追加した試作機能は安定的に動作することを確認したため､ 正式採用とし､デフォルトで有効にした

2018.10.08 4.0.3版 ･レイアウト用のホットキー設定画面における以下を修正 　�@"全体レイアウト"のホットキーを変更しても反映されない問題を修正 　�A既に登録済みのホットキーを入力すると､設定画面にキー情報が表示されず 　　該当するレイアウトが実行される問題を修正 　�B個別･全体レイアウト用ホットキーに同じキーを登録できないように修正

2018.08.11 4.0.2版 ･ウィンドウ情報取得時のファイルパスと､ 実際にアプリケーションから得られたファイルパスが同じでも 文字の大小が異なっていた場合は違うアプリケーションと誤判定する問題を修正 例えば､以下のファイルパス自体は同じだが､"memo"の部分の大小が異なるため 異なるアプリケーションと誤判定していたが､ 文字の大小に関わらず正しく判定するよう修正した｡ 　ファイルパス1　c:\editor\memo.exe 　ファイルパス2　c:\editor\MEMO.exe ･新規にウィンドウ情報を取得した直後のデフォルト検索条件は 　ファイルパス以外にウィンドウクラスも有効にするように変更 従来のデフォルトの検索条件はファイルパスのみであったが､ それだけでは設定画面などの子ウィンドウまで 親ウィンドウと同じようにレイアウトされる状況となる｡ 通常は問題ないが､ 実行契機に｢自動(起動時のみ)｣または｢自動(常に)｣を指定する場合､ 子ウィンドウも常に親ウィンドウと同じ位置､サイズに変更されるため 意図しない結果となってしまう問題が発生する｡ そのため､デフォルトの検索条件にウィンドウクラスも有効化されるようにした｡ 意図しない結果になる例: メモ帳に対して､以下のようにレイアウト設定を行うと､ 親ウィンドウは問題ないが､ 子ウィンドウ(設定画面やバージョン情報など)も同じように レイアウトされてしまう｡ 子ウィンドウ1 子ウィンドウ2

2018.04.26 4.0.1版 ･レイアウト対象のプリケーションの起動を高速に検知するオプションを追加 設定メニューの｢ウィンドウの検知を高速化｣オプションを追加した｡ このオプションが有効時には レイアウト対象のプリケーションの起動を高速に検知するため､ 自動的なレイアウトが従来よりも素早く行われるようになる｡ この機能の特徴は以下のとおり メリット　 レイアウト対象のアプリケーション(32bit/64bit両対応)の 起動を検知する速度が従来に比べて飛躍的に向上する (それにも関わらず､CPU負荷は変わらない) デメリット �@一度使用すると､OS終了まで 　インストール先のファイル"EventHelper.dll"と"EventHelper_x64.dll""が 　書き込み禁止になる場合がある｡ 　その状態でLayoutWindowをアップデートすると 　アップデートが失敗するため､ 　以下の対処でアップデートを行う必要がある｡ 　対処方法: 　　1.設定メニューの｢ウィンドウの検知を高速化｣オプションを無効化する 　　2.OSを再起動後､アップデートを行う 　　3.｢ウィンドウの検知を高速化｣オプションを有効化する �A実験的な試みであるため､サポート対象外とする

2018.04.19 4.0.0版 1.CPU負荷を軽減し､従来に比べて1/100以下の省電力で動作するようにした CPUの利用を極力抑えるように改良し､ 性能･機能は変わらずに省電力で動作するようにした｡ 実際にタスクマネージャで確認すると､常時ほぼ0%であることが確認出来る｡ 2.メニュー　→　"ウィンドウ監視を停止" を実行すると2秒間停止する問題を修正

2018.03.18 3.9.9版 ･ターゲット選択のハイライト枠の描写がWindows10で残像が残る問題を修正 ･自動起動オプションと管理者権限起動オプションを追加 管理者権限で起動する 　…　 Windows10において､ カーソルを消す対象のアプリケーションが 管理者権限で起動している場合でも､ 通常のアプリケーションと同様にカーソルを消すことが 可能になる｡ 例えばタスクマネージャのような他プロセスに関与する アプリケーションは管理者権限で起動しているケースが多い｡ OS起動時に 自動起動する … OS起動と同時に本アプリケーションを起動する 管理者として起動している場合は､ バージョン情報に｢(As Admin)｣が表示される

2018.01.21 3.9.8版 ･Windows10 "Fall creators update"にて起動に失敗する場合がある問題を修正

2017.01.12 3.9.7版 ･スリープ､レジュームからの復帰後にホットキーが無効化される問題を対処

2016.10.29 3.9.6版 ･ターゲットウィンドウに｢特殊ウィンドウ｣を追加 Windows10で全画面に表示されるアップデート通知に対応した｡ Windows10で自動アップデートを禁止して手動で行うようにすると 次のような有無を言わせぬ通知が表示されるようになります｡ 全画面かつ最前面表示､そしてトドメの選択肢が1つという驚異のデザインです｡ このような通知は従来の方法で制御できなかったため 制御可能とする｢特殊ウィンドウ｣オプションを新たに用意しました｡ 上記の設定を行うことで､通知自体を自動で消すことが可能になります｡ この設定情報はレイアウトウィンドウのメニューから "設定→指定したウィンドウ情報取得"機能で通知画面を選択することで得られますが､ 通知画面が最前にあるため､通常は他の操作を行うことが出来ません｡ そこでマウ筋Liteの｢どこでもドラック｣にて次のように邪魔な画面を退かすことで LayoutWindowを操作できるようになり､通知画面を自動で消す設定が行えます｡ もしマウ筋Liteを導入していない場合は LayoutWindowに次の情報を手動で登録しておくと良いでしょう｡ 項目名 設定値 アプリケーション名 windows10 アップデート通知 ファイルパス C:\Windows\System32\MusNotificationUx.exe ウィンドウタイトル 更新プログラムを利用できます ウィンドウクラス Shell_SystemDialog 特殊ウィンドウ 有効 状態 強制終了 実行契機 自動(常に) アップデート通知に限らず､レイアウト対象を指定しても上手く動作しない場合は ｢特殊ウィンドウ｣オプションを試してみてください｡

2016.05.16 3.9.5版 ･ウィンドウの状態に｢画面中央に表示｣を追加 ･子ウィンドウに対しても自動的なレイアウトを行えるようにした 前者はウィンドウを画面の中央に表示する機能です｡ 単に中央に表示するだけならば既存の機能を使用すれば ほぼ同じようなことが出来るのですが､ 後者と組み合わせることで絶大な威力を発揮します｡ それは"子ウィンドウが表示されると自動的に画面中央に表示"されることです｡ 個人的にどうしても欲しかった機能なのですがようやく実現できました｡ どのように便利になるのか実例を挙げましょう｡ 事例1　一般的な設定画面が常に見やすい位置に表示される 設定画面はメインウィドウの左上に表示されることが多いです｡ そのため視線を左上に固定したまま､ 多くの項目が並ぶ細かい画面を凝視することになります｡ 正直､目が疲れる作業です｡ 視線は正面に向いているときが最も負担が少ないので 画面を中央に移動しても良いのですが､ 設定画面というのは意外なほど開く機会が多いため､ 移動自体が面倒になり､つい視線を左上に向けることになります｡ 複雑な画面を操作するならば自動で画面中央に表示して欲しいものです｡ しかも一部ではなく大半のアプリケーションで共通してそのようになれば理想的です｡ でも､どこに表示されるかはアプリケーション次第なので通常は無理です｡ しかぁし､LayoutoWindowならばその理想を叶えることが出来るようになりました!! なにか適当な設定画面をLayoutWindowに登録し､以下のように設定します｡ 以下の例ではIEの設定画面を使用) 設定を反映するためには保存し､LayoutWindowを閉じてください｡ (LayoutWindowが表示されたままでは実施契機の"自動"が開始されないためです) すると､いつもはメインウィンドウの左上に表示されていた設定画面が このように画面中央に表示されるようになりました｡ (例が分かり易いよう予めメインウィンドウを画面中央に表示) また他のアプリケーション(例えば秀丸エディタ)でも同様のことが出来ます｡ この機能のお陰で精神的な疲労(目の疲れはここにきます)が大分軽減されました｡ もっと早く実現しておけば良かったです｡ 事例2　画像ビュワーのビューウィンドウが自動的に画面中央へ表示される 私が使用してきた画像ビュワーは通常､ビューウィンドウの表示位置が メインウィンドウの左上の方に来ます｡ 見やすくなるように毎回中央付近に移動するのですが､ 手で移動するのが面倒なこと以外の問題として､ 視線が左上から中央に移動することが繰り返されるので､眼精疲労の元になっていました｡ 例えば画像ビュワー｢ViX｣の場合､ ウィンドウクラスが可変(表示の度に変化する)であるため､ ウィンドウの判断にウィンドウクラスは使用できません｡ そこで今回はウィンドウタイトルを使用することにします｡ 子ウィンドウのビュワーのタイトルの末尾に"- ViX"と固定で表示されるので 以下のように設定します｡ すると､次のようにどこに表示されるか分からない状況が このように中央に表示されるようになりました｡ 画像の選定は目を酷使するので､極力視線の移動が少ないと精神的にも負担が減ります｡ この新機能､ 実際に使用してみると､従来は如何に目を酷使していたかに気がつかされました｡ 単に便利と言うだけでは無く､精神的に非常に楽になります｡ というのは視線の移動､不自然な方向への固定というだけでなく､ その前段の"どこに表示されるのかを探す"という手間も無くなるためです｡ とりあえず目を中央に向けておけば目的のものが見つかるというのは 想像以上に良いものです｡

2016.01.17 3.9.4版 ･アプリケーションリストの並び順に前版で追加した｢アプリケーション名｣を指定可能にした

2015.12.19 3.9.3版 ･ターゲットウィンドウ情報に｢アプリケーション名｣を追加 これはアプリケーションのリストに表示されるラベルになります｡ 従来は｢ウィンドウタイトル｣を表示していましたが､ 任意の名称を表示できるようになりました｡ 新たにウィンドウ情報を取得した場合は､ デフォルトでアプリケーション名が表示されますが､任意の名称に変更できます｡ ･新たにウィンドウ情報を取得した場合､アプリケーションを判別する情報を ウィンドウタイトル･クラスからファイルパスに変更 基本的にアプリケーションを判別する情報はファイルパスで済むため､ ファイルパスのみで判別するようにしました｡ より詳細に絞り込む場合はウィンドウタイトルやクラスを有効にすると良いでしょう｡

2015.09.17 3.9.2版 ･"指定したウィンドウを取得"でウィンドウを選択時に､マウスカーソル配下のウィンドウの枠を点滅表示させて､どのウィンドウを選択しようとしてるのか明示的に分かるようにした｡ マウ筋LiteやInvisibleMouseCursorで既に実装していた機能だが､ LayoutWindowにも無いと不便だったため追加した｡ ･"実行契機"にOS終了時に自動的に行う｢自動(OS終了時)｣を新たに追加 OSのシャットダウン時は素早く終了して欲しいものである｡ しかしアプリケーションが終了して良いか尋ねてくる場合はそれが遅れることになる｡ 早く終わらせるためにはそのメッセージに対するOKボタンや､タスクリストの強制終了ボタンをその都度押す作業に追われることになる｡ 面倒だからと放置するとOSが自動的に強制終了を行うのだがそれが始まるまで10秒程度待たされることになる｡ いずれにせよ､素早く終了しないことには変わりは無い｡ 更に厄介なケースはOSシャットダウン時に常駐アプリが毎回異常終了のメッセージを出す場合である｡ PCの使い始めは調子よくても使い込んでくると原因不明のエラーが頻発することがあるが､その度にエラーや例外がXXXで発生しました､とメッセージが表示されOKボタンを押すことを要求してくるのである｡大抵原因は不明であり､OSシャットダウン時に見せられても意味は無いにも関わらず見せられるのである｡往々にしてあまり愉快な気分にはならないだろう｡ OS設定用のツールを使うと､OSによる自動的な強制終了の開始時間を短くできるのである程度は緩和できるのだが､それでも遅くなる事実は変わらないし､不要なメッセージを表示しないようには出来ない｡ 一応､有無を言わさず全て強制的に終了させることも可能だが､そうなると今度は未保存のデータがある場合に保存を促す有用なメッセージすらも表示されなくなるデメリットが生じる｡ これを解決するには､OSシャットダウン時に予め登録しておいた条件に合致するアプリケーションのみ強制的に終了されるようにすれば良い｡ その機能をLayoutWindowで実現した｡ LayoutWindowは柔軟な条件指定が可能であるため､ 例えば次のような使い方が出来る｡ 　･メモ帳の場合は無条件で強制終了 　･秀丸エディタの場合はタイトルに｢無題｣が含まれる場合のみ強制終了 　･定期的に異常終了のメッセージを出すアプリケーションを登録し､無条件で強制終了させる 設定例: すると､従来は不要だった複数の問い合わせや意味の無いエラーが一切表示されなくなり､更にOSのシャットダウンが素早く終えるようになるため､非常に快適になる｡ 複数あったウィンドウが一瞬で消えるのは愉快痛快である｡ OSの再起動やシャットダウンを行う契機というのは意外なほどあるため､シャットダウン時に少しでも不満を感じたことがあるならば是非試して欲しい｡

2015.04.29 3.9.1版 ･高DPI環境化でも画面デザインが維持されるように調整 高DPI環境ではアイコンサイズと行間が小さく表示されたため 通常DPI環境と同様のデザインとなるよう適切なサイズに変更｡ 調整前: 調整後:

2015.04.12 3.9版 ･フルHDを越える高解像度環境でケースによっては 　対象アプリケーションが正しく判断できない問題を修正 ･フルHDを越える高解像度環境でケースによっては 　ウィンドウ取得時ができない問題を修正

2014.12.30 3.8版 ･アプリケーションを追加･削除すると､リストが常に先頭へスクロールしていたが 　追加時は追加した項目､削除時は削除した位置の項目を選択状態にして 　選択項目が常に表示されるよう自動的にスクロールされるようにした ･登録項目をDeleteキーで連続削除可能にした ･コンフィグリロード後､メイン画面を閉じた後に再度表示すると､ 　タイトルに｢更新｣が誤って表示される問題を修正 ･設定画面表示時は｢ウィンドウを監視する｣機能を一時的に停止するように変更 ･コンフィグリロード時､稀に異常終了する問題を修正

2014.12.21 3.7版 ･解像度の変更で変えられたウィンドウの位置やサイズを自動で復元するようにした ゲームの全画面表示やリモートデスクトップ等で解像度が変更されると 開いていたウィンドウも画面内に収まるように移動します｡ しかし､終了後に元の解像度へ戻っても既に移動したウィンドウは戻りません｡ 画面サイズが戻るならば､ウィンドウも元の位置に戻ることが自然な流れであると 考えたため､元の解像度に戻るとウィンドウも元に戻るようにしました｡ この機能はメニューの設定→ウィンドウを監視　が有効時(デフォルト有効)に 自動で働きます｡

2014.11.25 3.6版 ･レイアウトを自動で行う｢常に状態を維持する｣機能を拡充し､ 実行契機を新たに設けた｡ 従来は自動で実行しない､または自動で常に実行するの2択であったが 指定アプリケーションが起動したときのみ1回だけ自動でレイアウトが行われる ｢自動(起動時のみ)｣を新たに追加した｡ アプリケーションによっては終了時のウィンドウ位置､サイズを記憶しないことがあり､ 毎回手動で調整する必要に迫られることがあります｡ またそれらの機能を備えていたとしても､次回起動時は毎回指定した定位置で 表示して欲しい場合はウィンドウの位置を変更せずに終了させなければなりませんが 僅かでも移動してしまうと結局は手動で調整することになります｡ LayoutWindowは些細でありながら､しかし繰り返し行われ続ける労苦から解放します｡ なぜなら指定したアプリケーションが起動した時のみレイアウトを自動で行うことが出来るからです｡

2014.07.24 3.5.1版 ･メインウィンドウが非表示時に終了すると､位置･サイズ情報が初期化される問題を修正

2014.07.23 3.5版 ･メインウィンドウをリサイズ可能にした ･終了時のウィンドウサイズを記憶するようにした 従来はウィンドウサイズが固定であったため､ アイテム数の増加に伴いスクロールする必要がありましたが､ 一度に表示可能な数をリサイズして調整することが可能になりました｡

2014.05.31 3.4版 ･メニューの｢ウィンドウ監視｣状態をコンフィグで保存可能にした 従来は一時的にウィンドウ状態の監視を無効化するためのメニュー項目であったが､ コンフィグで管理することにより次回起動時も反映されるようにした｡ メニューの｢ウィンドウ監視｣は ターゲット設定の｢状態｣(通常･非表示･最大化･最小化･閉じる･強制終了)の ｢常に状態を維持する｣機能を全て有効化または無効化する機能である｡

version 3.0版リリース 12/12/01

シェアレジ

version 3.0版､近日リリース予定 12/11/27

次版作成中 12/11/03

開発日誌　11/10/01
自作ソフト第2弾、これも愛用していたアプリケーションがwindows7 x64で動作しなくなったため作りました。

ウィンドウをレイアウトさせるアプリがx64動作しなくなるのは想定外で、著しく作業効率が落ちました。代替手段を捜したところ、ウィンドウ操作関連ソフトはあるにはあるのですが、ショートカットが使用できない・GUI画面から指定したアプリしかレイアウトできない・登録するアプリケーションを選択できない等どうも理想とはかけ離れてしまいます。
また自動でウィンドウを閉じるアプリがx64で動作しない。

あれぇ？x64ではウィンドウ操作って意外なほど選択肢がない。
全般的にx64対応はいろいろ難しいみたいですが、時間がたてばまた優れたアプリが登場するはずなのでそれまで待ちましょうかって、、待つかーい！いつだよ､いつ出てくるの！

ということで、Ryu's Menu Version 4.00の開発で得た技術を応用し、作ってみることにしました。でも単に作るだけではつまらないので、コンセプトを決めます。（ここから専門用語がいろいろ入ってきます）

1．複数の開発言語を組み合わせて、上手に連動させることで1つのシステムしたい
　　（異なる言語間の処理を連動させる実績が欲しい。
　　　しかもサンプル程度の品質ではなく自分が手放せないほど有用なもので。）
2．でも処理速度は落とさない（重要）
3．機能は�@と�Aを統べて満たす（そもそもそれが目的）
4．x86、x64の両方に対応にする（環境を限定したくない）
5．他にはないオリジナルの機能があればいいね！（満足したい）
6．ショートカットキー、特にグローバルなキーは外部アプリケーションに任せる。
　外部とは特定のアプリケーションとは限定せずに、汎用的に使用できるようにする。
　（作者は当然、Ryu's Menu Version 4.00に任せています。元々rmenu4は全ての基幹となることを想定しているのです。）


さて、方向が決まったところで実現方法ですが、

1…選択に困るほど手段があるので、吟味すれば特に問題なし。
　　（まあ、その吟味が難しいのですがね）

2…これは非常に悩んだのですが、検討の末excelsiorの製品にしました。
　　ただ結論に至るまでにはかなり時間が掛かりました。
　　excelsiorのExcelsior JETという製品に関するレビューはほとんど無く、大半は公式HPの内容をほぼそのまま紹介しているだけなので、実際に実用になるのか判断がつきませんでした。（特に日本語ではレビューすら皆無です。）
しかたないので徹底的に調査したところ、いけるという手応えが得られたため採用しました。
以下に挙げたように欠点もいくつかありますが、致命的ではないので把握さえしていれば問題ありません。

調査結果(performance/usability report)：
　利点
　　　�@処理速度の向上（1．5から2倍。流石ネイティブ化は伊達ではありません）
　欠点
　　　�@インストーラにVM環境が丸ごと含まれるため、パッケージサイズが大きくなる
　　　�Aネイティブ化処理に時間が掛かる
　　　�Blog4のデバッグ文を実行した行情報が"??"となってしまう。
　　　　（ネイティブ化によりデバッグ情報が無くなってしまうことが
　　　　理由のようですが、気になる程度で実害は無いです。）

3．VCで実装すれば問題無し

4．x86はいいのですが、x64はいろいろ事情が特殊であり、かつ歴史が浅いので情報はx86に比べて少ないです。これはもう試行錯誤しかないのです。
でも今の内にノウハウを貯めればこれからx64が主流になるので、きっと役に立つはず！

5．自動的に指定したウィンドウを閉じる、または非表示にする機能を実現する。
　　しかもx86、x64対応で。
　　この機能がオリジナルなのかどうか調べてみました。完璧には無理ですが少なくとも著名なものがあればヒットするはず、と国内外を見たところ、x86/x64対応で自動的に指定したウィンドウを閉じることも、非表示にすることも存在しないようです。
　現状(11/10/01)、非表示化については明示的に手動で実行する必要があるものしか見つかりませんし、閉じることに至っては存在しないみたいです。
　　（少し気になったのですが、海外のソフトはちょっとしたUtiltyでさえシェアウェアが多かったです。日本は逆にフリーウェアが多いですね。文化の違いでしょうか）