FreeEcho 掲示板

「処理しない条件：バージョンが違う」と、予告されているプラグイン・スクリプト機能について質問があります。

「処理しない条件：バージョンが違う」は対象ソフトの実行ファイルのプロパティからバージョン番号を取得し、バージョン番号が変更された時にイベント・タイマーの位置・サイズの適用を無効にする（処理のチェックボックスは外れない）、または「知らせる」メッセージを表示してイベント・タイマーのバージョン番号を上書きした上で位置・サイズを適用する、あるいは無効にする（処理のチェックボックスは外れない）。
自分で試した限りではこのような挙動であると認識しております。

しかし、この機能には課題が残ります。
バージョン番号のみの変更をトリガーの条件にしているため、例えば対象ソフトが頻繁にアップデートされている、イベント・タイマーに登録しているウィンドウの数が多いといった場合、むやみやたらにこの機能が働いてしまいます。
この機能の目的は「大規模なアップデートによってUI・サイズが変更されたことを確認して処理方法を選択したい」ですので、それ以外のマイナーアップデート、セキュリティーアップデートは除外されるべきです。

この軽減策として以下のような方法が考えられます。

・メジャーアップデートとマイナーアップデートを区別して検知する
・全てのアップデートを検知した上で、自動的にイベント・タイマーの位置・サイズと比較を行い、変更があった場合のみ自動的にイベント・タイマーの位置・サイズを上書きして修正する

こういった機能をプラグイン・スクリプト機能での実装を考えていらっしゃいますでしょうか？

>この機能の目的は「大規模なアップデートによってUI・サイズが変更されたことを確認して処理方法を選択したい」ですので、それ以外のマイナーアップデート、セキュリティーアップデートは除外されるべきです。

これに関してですが、一部のソフトウェアでマイナーアップデートでもUI・サイズが変更される場合があるので、メジャーアップデートとマイナーアップデートを区別していませんでした。
他の方法も含めて検討します。

>こういった機能をプラグイン・スクリプト機能での実装を考えていらっしゃいますでしょうか？

まだ考えていません。
プラグインやスクリプトの機能は実装方法の検討中なので、決まってから検討します。

お答えいただきありがとうございます。

・全てのアップデートを検知した上で、自動的にイベント・タイマーの位置・サイズと比較を行い、変更があった場合のみ自動的にイベント・タイマーの位置・サイズを上書きして修正する

こちらの方法についても1つ問題を見つけました。
アップデートによるUIの変更が行われる直前にユーザーが手動で位置・サイズを変更していた場合、その位置・サイズで比較が行われてしまう場合があります。
この点も注意が必要かもしれません。

ご意見ありがとうございます。

>全てのアップデートを検知した上で、自動的にイベント・タイマーの位置・サイズと比較を行い、変更があった場合のみ自動的にイベント・タイマーの位置・サイズを上書きして修正する

自動的にイベント・タイマーの位置・サイズを上書きして修正する機能を実装する予定はありません。
自動での修正には問題があるので、位置・サイズを変更するかしないかの判定だけと考えています。

アップデートでUI・サイズが変更された場合に処理するかの判定に関してですが、起動時のみの判定で、起動時のサイズが指定したサイズ以外の場合は処理しないようにする方法を検討しています。
この方法だと、アップデートによるUI・サイズの変更で、初回起動時に決められたサイズに変更されて起動された場合のみですが、変更されないようにすることができます。
毎回決められたサイズで起動される (ソフトウェア側で起動時のサイズが固定されている)、アップデートによるUI・サイズの変更でサイズが初期化される (前回終了させたときのサイズで起動されない)、などの条件が必要になるのがデメリットになります。

メジャーアップデートとマイナーアップデートを区別する方法も検討しています。
この方法にする場合、区別するかしないかの設定を追加しようと考えています。

質問が多くなり申し訳ありません。

位置については変更の必要性を感じていませんが、設定は修正せずにサイズの変更が可能ということでしょうか？
その場合も改めて手動でサイズを修正することになるかと思いますが、それを「知らせる」メッセージから誘導する、また変更前と変更後の状態を比較した結果を表示して分かりやすくするといったことは可能でしょうか？

いずれの場合におきましても、処理をメッセージで視覚化しユーザーが混乱しないようにするのが良いのではないかと私個人は考えます。

>設定は修正せずにサイズの変更が可能ということでしょうか？

メッセージが表示されて「設定を新しいバージョンに変更」が選択された場合は、設定している処理しない条件のバージョンが変更されます。
設定しているバージョンが変更されることでサイズの変更が可能となります。
変更しなかった場合は、処理が無効になるのでサイズの変更はされなくなります。
他の判定方法に変更または追加する場合は、どのような判定方法かで決めます。

>それを「知らせる」メッセージから誘導する

検討します。
設定変更中は変更する項目の処理状態を無効にして、手動での設定変更後に有効にする方法で検討しています。
簡単で実装しやすく、不具合が発生しにくいからです。
ただし、この方法には問題があり、設定変更後に有効にしているイベントが発生するかタイマーが経過しないと処理 (サイズ変更など) されません。

>また変更前と変更後の状態を比較した結果を表示して分かりやすくするといったことは可能でしょうか？

具体的に、何を比較してどのように表示するのか、表示する情報は何か、などの要望や意見を伺ってもよろしいでしょうか？

> 変更しなかった場合は、処理が無効になるのでサイズの変更はされなくなります。

のちほど改善されるおつもりかもしれませんが、この場合、処理は無効でチェックボックスはオンになっていましたので、これがどのような状態なのかがよく分かりません。


> 具体的に、何を比較してどのように表示するのか、表示する情報は何か、などの要望や意見を伺ってもよろしいでしょうか？

すでに実装されている機能で、イベント・タイマーに設定している古いバージョンとアップデート後の新しいバージョンを比較し、イベント・タイマーの古いバージョンを新しいバージョンに上書きするということをやっていると思います。
例えば古いバージョン：1.01、新しいバージョン：1.02の場合、これを確認画面で表示してから上書きを行います。

同様にして、イベント・タイマーに設定されているウィンドウの幅：500px、高さ400pxとして、アップデートによって変更された（ユーザーが手動で変更したサイズではない）幅：700px、高さ500pxとします。
「旧　幅：500px、高さ400px」、「新　幅：700px、高さ500px」、「差　幅：200px、高さ：100px」
これらをまとめて確認画面で表示した上で、前述の手動によるサイズ変更画面に誘導するということです。
こういった比較表示が「知らせる」メッセージだけではなく、通常のイベント・タイマーの設定やトレイアイコンからも呼び出せると便利ではないでしょうか。

分かりにくい説明で申し訳ございません。

> 変更しなかった場合は、処理が無効になるのでサイズの変更はされなくなります。

「処理状態」ではなく、対象のウィンドウ処理の項目のみが無効になります (リストに登録している項目が表示されていますが、チェックが外れます) 。

>同様にして、イベント・タイマーに設定されているウィンドウの幅：500px、高さ400pxとして、アップデートによって変更された（ユーザーが手動で変更したサイズではない）幅：700px、高さ500pxとします。

便利そうですね。
判定処理などの部分で調整が必要になるなど、複数の問題があるので検討が必要になります。
バージョン確認とメッセージ表示はタイトル名などの確認とまとめて処理しているのですが、サイズなどの確認は別に (他の確認処理の後) 処理しています。
一つのウィンドウに複数の処理を登録できるようになっているので、確認処理を分ける必要があるからです。
新しいサイズのみの情報表示であれば負荷はないので気にすることなく実装できますが、設定しているサイズも表示する場合、処理の関係で負荷が増えてしまいます。
試しに実装して検証してみます。
負荷が高いと感じた場合は実装しない場合があります。
ご了承ください。

バージョンの確認方法に関してですが、「1」で設定していた場合はメジャーバージョンのみ、「1.2」で設定していた場合はマイナーバージョンまでの判定、で実装しました。

> 「処理状態」ではなく、対象のウィンドウ処理の項目のみが無効になります (リストに登録している項目が表示されていますが、チェックが外れます) 。

大変失礼しました。
再度挙動を確認したところ、知らせるメッセージから「いいえ」を選んだ場合は個別のチェックボックスが外れていました。


> 設定しているサイズも表示する場合、処理の関係で負荷が増えてしまいます。

負荷の問題で実装が難しい場合はメッセージを簡略化してもよいと思います。
重要なのはメジャーとマイナーを区別しない場合であっても、サイズのpx差を判定し、px差が無かった場合はアップデートによるサイズ変更は無しとしてこの機能をスキップできることです。
この方法の問題点はすでに述べた通り、ユーザーが手動でサイズ変更を行わないことを前提にしているということだと思います。

試しに実装して検証後に、負荷が増えすぎていると感じた場合は報告します。
実装と検証に時間がかかって遅くなる可能性があります。

お答えいただきありがとうございました。

試しに実装した結果、ほとんど負荷が増えずに実装することができました。(きれいなやり方ではないのですが...。)
変更や情報の追加をする可能性はありますが、これで実装予定です。

大規模な修正や変更作業を行っているので、公開までには時間がかかると思います。
イベントとタイマーの機能の統合、UIの変更、負荷の軽減、など様々です。

メジャーアップデートとマイナーアップデートを区別する以外の方法でサイズの変更を検知するのは難しいでしょうか？
FreeEcho様がおっしゃいました通り、メジャーアップデートでなくてもウィンドウサイズが変更されるケースはかなりあると思います。
直近の例で言えばWindows 11の更新でタスクマネージャーのUIが変更されています。

>メジャーアップデートとマイナーアップデートを区別する以外の方法でサイズの変更を検知するのは難しいでしょうか？

検知する方法は無い、もし方法があったとしても困難です。

お答えいただきありがとうございました。

方法がないかの調査は継続しています。
ただし、優先順位は低いです。