site logo
New Post
*OpenClose
 + 
#
thilmera project - forum
Question
New 重要なお知らせについて

Ryuvay 現在のchannel0の重要なお知らせのいちばん上のほうに「#Version: 0b181 Rev.2 DEV16」と書いてあるのは、なんのバージョンを示しているのでしょうか?現在のバージョンはDEV

05:51[0]Ryuvay
Issue
グラフ等が発光しゆっくり点滅する

Soma お世話になっております。 数日前から添付フォルダ内の画像のようにゆっくり発光しては元に戻る点滅を繰り返すようになってしまいました。 ハードウェアアクセラレーションを切ると改善されることは確認できまし

 Gakuto Matsumura - Developer おぉ、とりあえず解決した(?)ようでよかったです! シルメラだけの問題ではなく他でも異常、となると、何かのドライバか競合の問題だったのかもしれませんね。 修復コマンドは、少なくとも問題を引き起こし

 Soma ありがとうございます。 >シルメラだけの問題ではなく他でも異常 そうみたいです。グラボを交換した際にDDUで済ませていたのが問題だったのかもしれないです。 >経過を見てやはりシルメラで

14 20:15[46]Soma
Report
親プロセスの云々... 親プロセスのチェックに失敗しました(かも)

SleepyF VirtualBox上の仮想Windows XPの起動時に、時々(記憶では今回で2, 3回目)発生した現象について。 WinXP, Win7, Win10の複数環境でまだWinXPで発生した2, 3回

 Gakuto Matsumura - Developer 正直、XP32bitのSP2?だか以前のやつはまず動きもしなさそうですが、もしかしたらHyperVでは再現されないけど、VirtualBoxではネットワークの開始の方が遅いなとがあるかもしれません。

08 18:09[1]SleepyF
Report
設定画面の項目重複

廉祐 お疲れ様です。 thilmera設定画面にて、「起動前にオンラインを待つ」が二重に表示されているのを見つけました。 設定自体はどちらかで行えば更新されるため、通常使用には支障はありませんが報告いたし

 Gakuto Matsumura - Developer おお、本当だ! 報告ありがとうございます。 コードは修正しておいたので、次回以降で修正されます。

01 19:58[1]廉祐
Report
サービスからの起動

Ryuvay Windwos10pro 22H2 0b181 Rev.2 DEV12 サービスからの起動が昨日辺りから添付画像のダイアログが出て自動起動ができなくなりました。 新方式のタスクスケジューラ方式に切り

 Gakuto Matsumura - Developer 報告ありがとうございます。 ちょっとAMD Ryzen Masterの破壊的変更によりクラッシュし続けるやばそうな問題があるので、ch0にて更新していました。 タスクスケジューラ方式を作成した際に

 Ryuvay DEV13にて、サービスによる起動、タスクスケジューラでの自動起動ともに問題なく起動しました。 ご対応ありがとうございました。

03/25[3]Ryuvay
Issue
CPU温度が!AMD E2013 になっています

たけんこ Ryzen9 7845HX のノートPC のcpu温度が !AMD E2013 になっています。 AMD-Ryzen-Master をインストールし、「AMD Ryzen Masterを使用する」にし

 Gakuto Matsumura - Developer ありがとうございます。 こちらの内部的な修正面は直っているような感じですね。 今RyzenMasterはなんとも奇妙で変な状態になっていますね。 リリース側のv2.13.0.2908は古い型で、20

 たけんこ SDKは自分にはハードルが高そうなので、リリース版を待つことにします。 情報提供ありがとうございました。

03/24[8]たけんこ
Issue
「全画面時に非表示」設定にしても非表示にならないことがある

K 「アクティブな全画面時に非表示」設定をオンにした状態で,デスクトップ画面(WorkerW)と全画面ウィンドウを直接行き来(Win+D,Win+Ctrl+←→など)すると,デスクトップ画面に移っても表示

 Gakuto Matsumura - Developer 再現方法が分からないのでなんともですが、判定するフォアグラウンドの対象が変更された時に再判定するなどの変更を入れてみました。 こちらの環境では、仮想デスクトップの切り替えなどに完全に追従するのですが

 K このテスト版ではWin+Dも含めてリリース版で非表示にならなかったり表示されないままになっていた操作をしても正しく非表示になったり表示されたりすることが確認できました.ありがとうございます.

03/21[6]K
Issue
NVIDIA RTXで スリープ復帰後 ファン回転数などを取得できない

R.A NVIDIA RTX4070Tiにて、スリープ復帰後にファン回転数が0RPMになります。 100%確実にスリープ復帰後に再現される、と確証をもってお答えはできないのですが、少なくとも数時間間をお

 Gakuto Matsumura - Developer 対応遅れておりすみません。 実際のスリープにて実験などを行い、スリープからの電源復帰のコールバック後に、一部のハンドルの再収集を行うようにしてみました。 こちらで解決されるか確認をお願いします。

 R.A 対応に感謝します。 16日のバージョンでは、少なくとも12時間弱程度のスリープ後ファン速度を取得できていたことを確認しました。 実際に問題が解決したと確証がとれるか、引き続き試してみたく存じま

03/17[4]R.A
Report
[Closed] サウンドアナライザーの音階表示
03/07[5]retsam
Report
起動時の重要なお知らせが毎回表示される

屋久 左下の再表示しないにチェックを入れて閉じても、起動時の重要なお知らせが毎回表示されてしまいます。1~2か月前くらいまでは何ともありませんでした。 初回だけ強制表示で2回目以降は再表示しないのをデフォル

 屋久 thilmera7を終了してもう一度起動ところ、重要なお知らせは表示されませんでした。 その後PCをシャットダウンして起動し直したところ、重要なお知らせが表示されることはありませんでした。 一度手動で

 Gakuto Matsumura - Developer ありがとうございます。 それで直ったということは、やはりシャットダウンが正しく行われていないか、シャットダウン時に正しく設定ファイルを更新できていないですね。 要するに、終了時に保存すべきデータが

02/29[7]屋久
Report
Disk I/Oについて

くま 読み書きが0なのにドライブレターが表示される。 System:H67DE Processor:i7-2600 Windows10

 Gakuto Matsumura - Developer ありがとうございます。 こちらヘルプのQ&Aに記載しました。 過去にも類似する質問があったのですが、途中で応答がなくなったためヘルプに記載するのを失念していました。 回答と説明としては以下になります

02/28[1]くま
Question
[Closed] 下罫線を表示させるには
02/26[7]キャシー
Issue
設定の表示順序について

みどり 表示順序欄で調整できる「下部の余白」が正しく機能する項目とそうでない項目があります。 再現手順 1. thilmera7_0b181.zipをDLして新規フォルダに解凍してthilmera7-win

 みどり 早速の対応ありがとうございます。 普段利用しているフォルダにもテスト版を上書きしてみましたが、表示順や余白の位置も今までと同じ位置になっていて問題ありません。 ②は仰るとおり設定欄で一覧表示する順番

 Gakuto Matsumura - Developer ありがとうございます。 順序の表示順はともかく、余白に関して内容が一致していなかったのは明らかなバグなので、Rev.1として更新しておきました。 元々、構想としてはもっとグラフィカルに入れ替えでき

02/25[3]みどり
Issue
[Closed] フォーラムが正しく表示されない
02/25[2]K
Request
GeForceRTX Super Resolution Quality Levelの表示要望

retsam もし可能でしたらGPUの表示項目として、GeForceRTXの現在のSuper Resolution Quality Level(1~4)を表示可能に出来ないでしょうか。 検討いただけると幸いです

 retsam 最近のドライバでレベルの自動設定が追加され、動画再生中はNVIDIACP内でアクティブ/非アクティブと現在の適用レベルが表示されるので、可能性があるかと思い要望させていただきました。

 Gakuto Matsumura - Developer NVIDIAのコンパネの件は承知していますが、改めてNvAPIとnvmlのライブラリの最新の内容を、特定の語句ではなく全て確認しましたが、ニュアンスが近いものはディスプレイにおけるハイパーサンプリング

02/18[3]retsam
Report
[Closed] [0ch] 0b180Dr22REV16更新後、横幅が小さくなった
02/15[3]横レス
Report
[Closed] [0ch] ini_historyフォルダ内に xxxx.backup1900-01-00-000000.iniしかない
02/15[3]横レス
Report
[Closed] 「マウスオーバー非表示」をOFFにしてもしばらくthilmeraが表示されない
02/15[29]elphe
Report
[Closed] 起動時の重要なお知らせがメインディスプレイに表示されない
02/14[3]uhokun
Issue
[Closed] GPUのファンが表示されない
02/13[11]キャシー
*OpenClose
 + 
#
thilmera project - forum
Question 重要なお知らせについて
#1040
New Ryuvay - 2257@GPwZ222//tZ211wtPgmu2u0XJ/Zg0l Reply 2024/04/19 05:51
現在のchannel0の重要なお知らせのいちばん上のほうに「#Version: 0b181 Rev.2 DEV16」と書いてあるのは、なんのバージョンを示しているのでしょうか?現在のバージョンはDEV28ですし・・・
ほんの少し疑問に思っただけなのでたしたことではないですが・・・。
update
Reply

Issue グラフ等が発光しゆっくり点滅する
#1033
Soma - 2195@JPwZtlg2Pg2XmGwlwmgPX21Xtul Reply 2024/03/06 15:59
お世話になっております。

数日前から添付フォルダ内の画像のようにゆっくり発光しては元に戻る点滅を繰り返すようになってしまいました。
ハードウェアアクセラレーションを切ると改善されることは確認できました。

最近PCの調子が悪いのでおま環かもしれないのですが、確認のほどよろしくお願いします。

[appended] zip

Gakuto Matsumura - Developer Reply 03/06
報告ありがとうございます。

見た感じ、この現象はハードウェア描画における更新したエリア指定と、実際に更新するエリア指定が、一つでも食い違いがある描画が一度でも発生するとこうなる感じになります。

設定由来ならばこちらで再現できる可能性が高いのですが、しばらく見ていても再現はできませんでした。

どの程度の時間経過後、あるいは確率で発生しますか?
起動した瞬間から即確実に再現されるような感じでしょうか?

Gakuto Matsumura - Developer Reply 03/06
原因となりうる問題を一件修正していて、その項目が提出のiniファイルでオンになっているのを確認したので、念のため以下のテストにて改善されるか、もしくは変わらず発生するかを、合わせて確認お願いします。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240306-175943.zip

Soma - 2195@JPwZtlg2Pg20gXgfP0lZ1f2Pg/l Reply 03/07
対応いただきありがとうございます。

数日前と書いてしまいましたが、初めて発生したのは2週間ほど前でした。
発生するタイミングはPC起動時の自動起動した際ですね、頻度としては4~5回に一度とそこまで高頻度ではないですが、一度発生してしまうとアプリを再起動するだけでは直りませんでした。
何故かゲーム等を起動するといつの間にか改善されていたりします。

現状は頂いたテスト版で不具合は出ていませんが、頻度が頻度なので直ったのかどうかは分からない状況です。暫く使用してみて問題があればまたご連絡します。

ありがとうございました。

Soma - 2195@JPwZtlg2Pg2JfPlt/mtfGuw1XwX Reply 03/09
経過報告です。

テスト版でも同様の不具合が発生するようです。
こちらも同様にアプリケーションの再起動では直らず、ゲーム等を起動すると改善されました。

他に同様の報告がなければおま環恐れがあるので、その際はこの報告を無視して頂けると幸いです。

Gakuto Matsumura - Developer Reply 03/09
ありがとうございます。

再度詳細に確認したところ、範囲がウィンドウサイズをオーバーした際の補正後の数値が、1ドット分足りていないのを見つけました。

以下でもう一度確認をお願いします。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240309-194623.zip

Soma - 2195@JPwZtlg2Pg2JfPlt/mtfGuw1XwX Reply 03/09
ご対応ありがとうございます。

引き続き新しいテスト版を利用してみてまた問題があればご報告します。

Soma - 2195@JPwZtlg2Pg20G0Z/tw01GfXt0Xt Reply 03/10
今回も引き続き問題が発生することを確認しました。
恐縮ですが、ご対応をお願い致します。

Gakuto Matsumura - Developer Reply 03/10
うーん、念のための確認ですが、自動起動サービスを使用していて、再起動時にテスト版ではなくリリース版が起動している。とかの可能性はなさそうですか?

テスト版は末尾がDEV3となっています。

Gakuto Matsumura - Developer Reply 03/10
自動起動サービス登録済みの場合、リリース版の本体は一度サービス登録から削除。
その後にテスト版の方でサービスを再登録せずにOSを再起動した場合、起動されるのは元のリリース版となります。

ここはテストする側としても理解しづらいややこしい部分である事と、依然として問題発生しているのが、間違いなくDEV3のバージョンであったかを先に確認したいです。

Soma - 2195@JPwZtlg2Pg2G/f/tl1tgu02Gff0 Reply 03/14
返答が遅れました

それもやった上で設定を開いてバージョンの確認をしてDEV3であることは確認しています。が念のため一度アプリケーションを終了してテスト版を直接起動してみましたが、結果は変わらずでした。

Gakuto Matsumura - Developer Reply 03/14
確認ありがとうございます。
あと考えられるとしたら、描画するぎりぎりの所でウィンドウサイズが変更されたなどの可能性とかになりそうですが、ひとまずプログラム内で変更が差し込まれる可能性のある所を、パフォーマンス優先ではなく安全優先として排他処理内に移動しました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240314-143023.zip

このあたり、OSから差し込みで変更される可能性もあるのと、何かしらハードウェア側でエラーが出てる可能もあるので、これでも無理そうならばデバッグ用のログを各所に配置していってそれをテストしていく形になりそうです。

Soma - 2195@JPwZtlg2Pg2G/f/tl1tgu02Gff0 Reply 03/14
ありがとうございます。

引き続き検証を続けてみますが、やはり環境依存っぽい感じですかね....
また何かありましたら連絡致します。

Gakuto Matsumura - Developer Reply 03/14
確かにこちらで再現が難しいので原因が特定しづらいですが、確かに指示と内容が1ドットでも一致してない描画要求をするとそうなるのは論理上の問題なので、恐らく内部の問題かなと思います。

何かしらハードウェアが出すエラーが原因だったとしても、そのエラーハンドリングがうまくいってない感じのような気がするので、明らかに他にも描画が変になるウィンドウが乱立してない限りは直せるはずのものだと予想しています。

Soma - 2195@JPwZtlg2Pg222wGmutG/1ffwJJG Reply 03/18
DEV5にてまた同じ症状を確認しました。
今回は画面ロック解除時に発生しました。

もし環境によるものであるなら、NVIDIAの最近のグラフィックドライバを使用しているとレンダリングでちらつきが発生するという問題があるみたいなので、もしかしたらこの辺のバグなのかなと素人ながら考えています。

Gakuto Matsumura - Developer Reply 03/19
なるほど。
確実にこうすれば起こるというわけではない感じでしょうか?

ひとまず、詳細なログよりも先に、手元の環境下で、意図的にずっとエラーが発生したと仮定した動作を試してみると、一部でタイミングにより内部クラッシュが明確に発生する部分をみつけて、これを修正しました。

もしここに当たったのが原因であるならば、内部クラッシュ時に本来の処理がされずに範囲外に飛んで実際の内容と不一致の状態を起こすので、もしかしたら改善になるかもしれません。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240319-223155.zip

Soma - 2195@JPwZtlg2Pg2Xu2glttJw1mGm20 Reply 03/20
ありがとうございます。

そうですね、これをしたら確実に起こるという明確な原因は判明していない状況です。
付け加えると、以前のログイン時の自動起動という条件で発生していた問題はDEV5では発生していませんでした。

引き続き頂いた新バージョンで確認してみます。

Soma - 2195@JPwZtlg2Pg2u0GwGulG2PPJ/Zft Reply 03/21
DEV9にて自動起動時、画面ロック解除時の両方で問題が発生することを確認しました。
しかし今回は早い段階で点滅は収まり、アプリの再起動で白くなってしまった部分も表示されることを確認しました。
これは意図的な動作でしょうか?

Gakuto Matsumura - Developer Reply 03/21
> 今回は早い段階で点滅は収まり
これは正常な状態に早期に自動的に復帰した。ということでしょうか?
それとも点滅がなくなっただけで正しい表示ではない状態で固定されたということでしょうか?

アプリの再起動というのはシルメラのことだと思いますが、再起動しないと解決しなかったということでしょうか?

意図的かどうかの前に、どのような状態になっているのかがよくわからないです。

現在は、メインウィンドウが、ブロック毎に徐々に薄くなっていくようなタイプの現象についての修正を試みているので、それ以外の何かがあるならばそちらも具体的にどういったものなのかが分からないと対応が難しいです。

Soma - 2195@JPwZtlg2Pg2Jf202P121lu01/G2 Reply 03/22
>これは正常な状態に早期に自動的に復帰した。ということでしょうか?
>現在は、メインウィンドウが、ブロック毎に徐々に薄くなっていくような
数十秒ほどで点滅の症状だけ治まりました。しかしカレンダーとサウンドアナライザーのか所が白く発光し殆ど何も見えないという症状もありそこは改善されず、Thilmeraを再起動することで治まりました。

>アプリの再起動というのはシルメラのことだと思いますが、再起動しないと解決しなかったということでしょうか?
最終的な解決にはそうでした。

その後また点滅が発生したのですが、それ以来時間経過で改善されることはありませんでした。

説明が下手で申し訳ないです。他に情報が欠けているところがあれば遠慮なく言って下さると助かります。

Gakuto Matsumura - Developer Reply 03/24
なかなか解決に至らずすみません。

ch0にも出しましたが、以下のDEV13にて、そもそもの描画内容の作成開始時に更新エリアの数を必ず0に再指定するようにしてみました。

現在最新のch0=DEVと同一
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240324-174742.zip


問題となるのがどこかを考えていて、指定する更新エリアが重複。あるいは重なって複数あると問題が起こるかを試してみましたが、原因はそこでもなく…
何かしらのトラブルにより、意図しない処理の脱落などで不一致が発生するケースがあるのだと思いますが、難しい問題ですね。

ハードウェア描画にて点滅や薄くなったり白くなるのは、更新を指定してないエリアが実際には更新されていたり、その逆の場合に画面に結果をコミットすると発生する。という挙動になります。

なので、やるべき事は一致しなくなった場合にコミットしない。あるいはコミットできなかった場合にやりなおす。なのですが、この作成開始時に0指定も、理論上の全てを解決するわけではないです。
(ダメなケース:0クリアする前のコミット分がただの失敗で、エラーによるオブジェクト再生成はされておらず、前回のフレームで更新されているエリアが残っていた場合)

Gakuto Matsumura - Developer Reply 03/24
書いてて気づきましたが、今回の修正に加えて、開始時にそもそも不一致があった場合、更新エリアを放棄して全更新としてやれば、もしかしたら不一致なコミットの発生を消せるのでは…
と思いつきました。

もし改善されないようなら、次はそちらも試していきたいです。

Soma - 2195@JPwZtlg2Pg2f020tltXJu1lgwlf Reply 03/24
ありがとうございます。
とんでもないです。迅速に対応していただきいつも助かっています。

添付してくださったバージョンと、念のため元々使っていたバージョンを更新する形でDEV13を導入して両方で確認してみます。

また問題があればご連絡します。

Soma - 2195@JPwZtlg2Pg2wGfglmG/g2GGgGJJ Reply 03/28
今回も同じ条件で発生することを確認しました。

特にThilmeraが動いている状態で暫くロック画面で放置していると発生しやすいようです

Gakuto Matsumura - Developer Reply 03/31
ロックの検出をして、そのカバーなども検討はしてみましたが、それは何か起こった時に崩れるという根本を直した後だと思いなおして検証を続けました。

ソフトウェア描画の方で、外部要因により描画に必要なリソースが初期化された際、もしハードウェア描画だったら報告された状態に絶対なってしまうケースを、かなり稀で再現が難しいですが確認し、それぞれのウィンドウ毎に、描画内容の作成開始時のカウントが、リソース生成のカウントと一致しないケースでは部分更新を全て破棄して全体を更新する。というものにしました。

この状態で、グラフィックボードのドライバ(NVIDIA)を、ハードウェア描画にて起動しっぱなしでクリーンインストールして、画面点滅の後も正常にレイヤードで表示され続ける。という所までは確認しました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240331-002443.zip

こちらでの確認をお願いします。
DEV14

Soma - 2195@JPwZtlg2Pg2XlfwPgGwXJPGJgt2 Reply 03/31
ありがとうございます。

早速試してみたのですが、DEV13でPC起動時に件の不具合が既に起きている状態からDEV13を終了し、DEV14を起動するとその時点で早速発生してしまうことを確認しました。

通常通り自動起動を使用してDEV14を起動しても発生するかどうかも確認していますが、現状は発生していないです。

Gakuto Matsumura - Developer Reply 03/31
DEV14を起動した時、既に崩れた状態からスタートした。という事でしょうか?
それとも起動後にすぐなった感じでしょうか?

Gakuto Matsumura - Developer Reply 03/31
どちらにせよ、発生した時点でダメなのは確定しているので、割り込みにより再生成がコールされたがされていない、という状態のリカバーを更に増やしました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240331-164442.zip

もしこれでも発生するならば、リソース再生成ではなく、全く別の内部的ななにかの処理でこけている可能性のほうが高くなりそうな感じです。

Soma - 2195@JPwZtlg2Pg2glGgPfZff/0mg/Zu Reply 01 16:43
>DEV14を起動した時
既に崩れた状態からですね

DEV13を利用して以前の状態を再現して同じことが発生するかも含めて確認してみます

Soma - 2195@JPwZtlg2Pg2glGgPfZff/0mg/Zu Reply 01 16:49
>既に崩れた状態からですね
すみません、記憶違いでした。起動直後にです

Gakuto Matsumura - Developer Reply 01 17:06
うーん。
とりあえずフォントの問題かと思って検索して、フリーだったのでフォントも入れてみましたが、DEV13,14で提出のiniにて起動しても、やはり問題は再現できませんでした…

高さが前回と異なる場合は全体更新となり、前回のDEV15(20240331-164442)と、現ch0のDEV16では、更にリソースが再生成された場合も必ず全更新するようにしてあるのですが、これでも発生する場合、何かしら全く別の所でメモリが破損するなどが理由で、意図しない崩れ方をしている可能性も含めて検討しないとだめそうな気がします。

OSの修復コマンドを実行したらあっさり直る可能性もワンチャンあるかもしれません。

Soma - 2195@JPwZtlg2Pg2m01lgJf002mfZumw Reply 02 15:45
DEV15や16でも変わらず発生してしまいました。

>OSの修復コマンドを実行
自分もそう思って以前SFCコマンドとDISMコマンドを試してみたのですが効果はなかったです。

もしやと思い、常駐しているWallpaper Engineを止めてみたら全く不具合が起こらなくなりました。何か相性の問題がありそうです。

Gakuto Matsumura - Developer Reply 03 13:55
>常駐しているWallpaper Engineを止めてみたら全く不具合が起こらなくなりました

これは完全に想定外の理由でした。特大のヒントですね!

Wallpaper Engineとやらを調べてみたら、Steamアカウント作成、決済方法の入力、購入をしないとテストができないので、ちょっとハードル高い…

なんとなく恐らく外部から更新させられる場合に、多分このあたりにくるかもというのを一部対処してみました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240403-135329.zip

Soma - 2195@JPwZtlg2Pg2m/XfXuf0JmJ1g0G Reply 03 14:26
>購入をしないとテストができないので、ちょっとハードル高い…
そうですよね....こちらでテスト出来そうなことがあればやらせていただきます。

ファンボの方でCopperですが支援させていただきました。少ないですが運営資金に活用して頂ければ幸いです。

Soma - 2195@JPwZtlg2Pg2m/XfXuf0JmJ1g0G Reply 03 14:33
報告を書き忘れてました。

DEV16で表示が崩れている状態からDEV17を起動してみましたが、問題なく起動できました。
今のところは問題ないですが、引き続き使ってみて何かあればまたご連絡します。

Gakuto Matsumura - Developer Reply 03 21:26
ふぉぉぉ、ありがとうございます!

問題発生の原因(の未解決部分)が、外部から再描画がウィンドウへとコールされている部分なのは多分間違いないと思うので、17でも発生するならば、排他処理などを更に見直してみます。

Soma - 2195@JPwZtlg2Pg2gf0lPllZ1tgJPZ1X Reply 06 15:14
色々試してみたところ、スリープ解除時にまた発生してしまうことを確認しました。

Thilmeraを再起動するだけでは直らず、件のWallpaper Engineを停止した状態で起動すると元に戻りました。
ただ、その状態でWallpaper Engineを起動するとまた表示が崩れてしまうようです

Gakuto Matsumura - Developer Reply 06 15:54
明らかに外部から要求されるウィンドウの更新命令が正しく消せていないのが原因なので、根本的な部分である、ペイントの開始→即終了の部分を、そもそも無効エリアを消す。という内容に変えてみました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240406-155058.zip

Soma - 2195@JPwZtlg2Pg2010wP/w0ftGugu0X Reply 08 14:51
試してみましたが、変わらずでした。

あと今回のバージョンにて今まで問題なかった日時や天気など、私の設定におけるCPUの表示より上の部分がReading...と表示されるだけになってしまっています。

[appended] ini

Soma - 2195@JPwZtlg2Pg2f10tuXJ2m2u21mJ Reply 08 15:00
もう少し確認してみたところ、SMART情報も取得できないことがあるみたいです。
その状態で以前のバージョンをに切り替えてみるとCPUより上の表示もSMARTも取得できるので、PC本体側によるものではなさそうでした。

Gakuto Matsumura - Developer Reply 08 16:31
すみません、多くのソースに影響を及ぼす変更をした後にクリーンせずに慌ててビルドすると最近時々なる現象のようです。

ビルドしなおしました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240408-162839.zip

ただ、外部からの影響に関するものは多分変わってないので、これで直らないとすると、ウィンドウメッセージではなく、もっとローレベルで直接的なのかもしれません…

ちょっとDirectX(Direct2D関係の方で更新が行われたされたかどうかの確認方法ないか調べてみます)

Soma - 2195@JPwZtlg2Pg2f10tuXJ2m2u21mJ Reply 08 20:04
ありがとうございます。

やっぱり変化なしですね....

Gakuto Matsumura - Developer Reply 11 18:34
色々やってみたのですが、どうやっても再現できませんでした。
動画再生のウィンドウを後ろにおいて、かつ動画ウィンドウのサイズ変更や移動をしても、何をやっても崩れる状態にはならず…

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240411-183053.zip
とりあえず直近などで補正を入れている部分に簡易的なログ出力を追加しました。

割り込みとして気にしている部分なのですが、ログ出力を作ってみて分かったのは、現行の私の環境下では、そもそもウィンドウへの再描画のウィンドウメッセージそのものがきてなさそうなので、ここからの割り込みという可能性がそもそも怪しいかもしれません。

Gakuto Matsumura - Developer Reply 11 19:59
[補足]
前回からの変更として、一部の開始~終了の場所を移動。
ウィンドウメッセージで再描画の可能性がある部分にクリティカルセッションを使用したフラグとログ(今回のテスト版)の追加。

ログは "debug_log.DX11DA.txt" というファイルで出ます。

Soma - 2261@JPwZtlg2Pg20X2tP/11JZ/m///m Reply 12 22:35
すみません、最近他にも異常が出始めたので仕方なくWindowsを再インストールして初期化したのですが、それから全く再現出来なくなりました。修復コマンドでは修復できない何かしらの不具合だったみたいです....

Gakuto Matsumura - Developer Reply 13 18:55
おぉ、とりあえず解決した(?)ようでよかったです!

シルメラだけの問題ではなく他でも異常、となると、何かのドライバか競合の問題だったのかもしれませんね。

修復コマンドは、少なくとも問題を引き起こしているドライバや設定を消す事はしてくれないので、描画に対する割り込みなど、何かしら競合となるものがインストールされていたのかもしれません。

ただ、この修正の過程で、明らかにこちらでも確認できた点を途中で修正していたので、改めて整理した上でひとまずch0に出そうと思います。

経過を見てやはりシルメラでだけ問題がでる、という場合は再度検証していけたらと思いいます。

Soma - 2261@JPwZtlg2Pg2f2GJ/2g/tttgtP0f Reply 14 20:15
ありがとうございます。

>シルメラだけの問題ではなく他でも異常
そうみたいです。グラボを交換した際にDDUで済ませていたのが問題だったのかもしれないです。

>経過を見てやはりシルメラでだけ問題がでる
現状は問題なさそうですが、その際はまた報告します

ありがとうございました。
update
Reply

Report 親プロセスの云々... 親プロセスのチェックに失敗しました(かも)
#1039
SleepyF - 2260@e1dZYnLg Reply 2024/04/08 17:52
VirtualBox上の仮想Windows XPの起動時に、時々(記憶では今回で2, 3回目)発生した現象について。
WinXP, Win7, Win10の複数環境でまだWinXPで発生した2, 3回だけであり、再現性が低く、OSの起動プロセスの遅れか何かが影響するのかも知れませんが、スタートアップに登録してあるthilmera7が(メモせずうろ覚えですが)「親プロセスの云々、**で起動し直せ」※風なメッセージを出します。
※フォーラム過去ログ2021年, 2014年と同じく「親プロセスのチェックに失敗しました」だったかも知れません。

直後に、手動でスタートップに登録されたアイコン(thilmera7s.exe)をダブルクリックしたり、thilmera7フォルダにあるthilmera7.exe や thilmera7s.exeのダブルクリックすれば何事もなく起動します。

様子見で、thilmera.com/page-help-54 の「新ファイル構成 旧オフライン版/フル版 0b180以降のバーション」にある新ファイル thilmera7-win32.exe に変更してOSを再起動させた場合、メッセージなく正常起動します。気になって再度thilmera7s.exeにしてOSを起動し直してもメッセージなく正常起動します。

そういう意味で再現性が低いので、thilmera7-win32.exe でもしばらくしたらメッセージが出るのかもしれませんが、一応こんな現象が発生したという報告です。

Gakuto Matsumura - Developer Reply 08 18:09
正直、XP32bitのSP2?だか以前のやつはまず動きもしなさそうですが、もしかしたらHyperVでは再現されないけど、VirtualBoxではネットワークの開始の方が遅いなとがあるかもしれません。

たまにコードサイニング証明書の失効確認が入るので、それに失敗した場合、不正な起動。とうことになります。
update
Reply

Report 設定画面の項目重複
#1038
廉祐 - 2259@PPwZ21Pw2PuXPPw/u2XXPm112JgJ00mw Reply 2024/04/01 19:57
お疲れ様です。

thilmera設定画面にて、「起動前にオンラインを待つ」が二重に表示されているのを見つけました。
設定自体はどちらかで行えば更新されるため、通常使用には支障はありませんが報告いたします。
(バージョン:0b181 Rev.2 DEV16)

Gakuto Matsumura - Developer Reply 01 19:58
おお、本当だ!
報告ありがとうございます。

コードは修正しておいたので、次回以降で修正されます。
update
Reply

Report サービスからの起動
#1037
Ryuvay - 2257@GPwZ222//tZ211g1GZtt/1uwfufGl1 Reply 2024/03/24 10:52
Windwos10pro 22H2
0b181 Rev.2 DEV12
サービスからの起動が昨日辺りから添付画像のダイアログが出て自動起動ができなくなりました。
新方式のタスクスケジューラ方式に切り替えて使っています。

Ryuvay - 2257@GPwZ222//tZ211g1GZtt/1uwfufGl1 Reply 03/24
バージョン履歴をよく読んでなくてすみません。
この自動起動について調整をされたのですね・・・。
想定内であれば恐縮です。

Gakuto Matsumura - Developer Reply 03/24
報告ありがとうございます。

ちょっとAMD Ryzen Masterの破壊的変更によりクラッシュし続けるやばそうな問題があるので、ch0にて更新していました。

タスクスケジューラ方式を作成した際に、旧サービス稼働もタスクスケジューラ方式と判定され、かつタスクスケジューラ方式の場合はあるはずの内容が無い状態で変な判定になっていたようです。

DEV13にてこのあたり修正を試みてみました。

Ryuvay - 2257@GPwZ222//tZ2111wwluGtg222ulwZ1 Reply 03/25
DEV13にて、サービスによる起動、タスクスケジューラでの自動起動ともに問題なく起動しました。
ご対応ありがとうございました。
update
Reply

Issue CPU温度が!AMD E2013 になっています
#1036
たけんこ - 2256@GPwZ22PwlwPP02w0Z1ZPP2 Reply 2024/03/22 13:00
Ryzen9 7845HX のノートPC のcpu温度が !AMD E2013 になっています。
AMD-Ryzen-Master をインストールし、「AMD Ryzen Masterを使用する」にした場合、cpu温度の項目が非表示になります。「旧ドライバの使用を許可する(非推奨)」をONにすれば温度が表示されますが、非推奨なのであまり使い続けたくありません。
新しいCPUのせいかなと思いますが、対応可能でしたら宜しくお願い致します。CPUのレポートを添付します。


[appended] txt

たけんこ - 2256@GPwZ22PwlwPP02w0Z1ZPP2 Reply 03/22
追記 AMD Ryzen Master を起動すると「Unsupported Processor!」と返ってきました

[appended] txt

Gakuto Matsumura - Developer Reply 03/22
報告ありがとうございます。

添付されているtxtファイルはどちらもレポートの一部分のみですが、表示されている内容がこれで全文になりますか?

もし管理者権限でもこの内容が全文だとすると、レポート出力そのものに何かしら意図しないバグが発生しているかもしれません。

AMD Ryzen Master がこのプロセッサはサポートしてないと出てる場合、そこに関してはAMD Ryzen Master 側の修正待ちですね…

元栓の方がダメなので。

Ryzen Masterのバージョンはどうなっていますか?
Ryzen Masterのヘルプガイドというショートカットが見つかれば、それを開けばバージョンが何であるかの記載があります。

たけんこ - 2256@GPwZ22PwlwPP02w0Z1ZPP2 Reply 03/22
レポートのメニューから 「レポート:CPU情報」を選んで出力された内容の全てです。
Ryzen Master のバージョンは 2.13.0.2908 です。ヘルプガイドのショートカットはあるのですが、クリックしても何も起きないので、コンパネのプログラムと機能から取得しました

Gakuto Matsumura - Developer Reply 03/22
① レポートの問題の修正

レポートの方で全点検をしてみたところ、かなり限定的な文章の追加部分が、追加でなく上書きしてしまって、それより前が消えてしまうバグがありました。

② Ryzen Master v2.13への対応
結構クリティカルな問題が発生していました。
Ryzen Masterはバージョン変更でかなり破壊的な変更を行い、かつ公開されている内容の方が更新されない事が多いのですが、今回はv2.13のものに久しぶりに更新されていたので、そちらへの対応調整をしました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240322-231102.zip

もし、RyzenMaster本体の方が対応してない場合は引き続き見れないとは思いますが、こちら側の問題ならば表示されるようになっているはずです。


具体的な変更点

 ○ RyzenMaster v2.13
  ・【重要】v2.13以降がインストールされている環境で、変更の影響によりプログラム内部で参照エラーのクラッシュが発生し続けて動作しないトラブルを修正
  ・v2.13では「Sleep」に相当するデータは無くなったため、5%以下をSleepに該当すると判断するように仮指定
  ・v2.13ではEffective Clockの使用率にはライブラリが示すC0パーセンテージの値を使用するように変更
  ・ライブラリのロードに問題があった場合、エラーメッセージをCPU情報レポートに出力するように変更

たけんこ - 2256@GPwZ22PwlwPP02w0Z1ZPP2 Reply 03/23
対応版試してみました。結果は依然温度表示されないままでした
どうもRyzenMaster本体が対応していないようですので、AMDから新版が出るまで待つことにします
早速のテスト版ありがとうございました

たけんこ - 2256@GPwZ22PwlwPP02w0Z1ZPP2 Reply 03/23
CPU レポート を忘れていましたので報告します

[appended] txt

Gakuto Matsumura - Developer Reply 03/23
ありがとうございます。
こちらの内部的な修正面は直っているような感じですね。

今RyzenMasterはなんとも奇妙で変な状態になっていますね。
リリース側のv2.13.0.2908は古い型で、2024/03/15にローンチされたSDKのv2.13.0.2915は中身が大分変わっています。

どちらもドライバーはv22なので、単に付属するライブラリの内部的な問題な気がしますが、SDKの方は、頂いたini内にあったモデルIDは対応リストに入っているので、なんでこういう状況になっているのかよくわかりません。

現行のリリースビルドでは、SDKでは動作しないようにしてあったり、一般的に使うとなったら、Eulaに同意した上でSDKの方を入れる必要があるので、単純にシルメラの中で見るのが最終目的ならば、SDKの方はハードルが高そうですね。


一応SDKのリンクは貼ってはおきますが、これは入れたてら入れたで競合したりと環境がややこしいものになるので、相当PCに詳しくない限りはあまりお勧めはしません。
www.amd.com/ja/developer/ryzen-master-monitoring-sdk.html

たけんこ - 2256@GPwZ22PwlwPP02w0Z1ZPP2 Reply 03/24
SDKは自分にはハードルが高そうなので、リリース版を待つことにします。
情報提供ありがとうございました。
update
Reply

Issue 「全画面時に非表示」設定にしても非表示にならないことがある
#1035
K - 2222@Hy4II48W Reply 2024/03/21 14:02
「アクティブな全画面時に非表示」設定をオンにした状態で,デスクトップ画面(WorkerW)と全画面ウィンドウを直接行き来(Win+D,Win+Ctrl+←→など)すると,デスクトップ画面に移っても表示されなかったり,逆に全画面ウィンドウに移っても非表示にならなかったりします.
なおタスクバー領域を考慮する設定にした場合でも,通常の最大化ウィンドウではこの問題は発生しませんでした.

[appended] ini

Gakuto Matsumura - Developer Reply 03/21
報告ありがとうございます。

こちらでも試してみたところ、たしかに「Win+D」では消えますが、「Win+D」で切り替えられたデスクトップは、何も表示されない状態というOSの仕様なので、その状態で表示されないのは正しい(むしろそれを阻害する場合は恐らくOSのポリシー違反)です。

「Win+Ctrl+←→など」という方は試してみましたが何も起こらなかったので、全画面ウィンドウに移っても非表示にならないというのが確認できませんでした。

まずは、「Win+D」の後に表示はされない。これはOSの絶対的な仕様である事。
これを踏まえた上で、非表示にならないという手順の再現方法を教えて下さい。

K - 2222@Hy4II48W Reply 03/21
「Win+Ctrl+←or→」の方は,仮想デスクトップが2つ以上ある状態で行うと仮想デスクトップが切り替えられるというものです.
全画面ウィンドウがアクティブになっている仮想デスクトップと,デスクトップがアクティブになっている仮想デスクトップが隣り合っているとき「Win+Ctrl+←or→」で仮想デスクトップを切り替えると表示されたままになります.

Gakuto Matsumura - Developer Reply 03/21
詳細ありがとうございます。


頂いたiniにて全画面と「Win+D」を切り替えてみましたが、こちらの環境では正しく全画面は非表示。デスクトップは表示になりました。


上記の仮想デスクトップも時事通りの内容を確認してみましたが、こちらの環境では再現はできませんでした。
頂いたiniにて、デスクトップ1の全画面と、デスクトップ2の何もないデスクトップを切り替えて、全画面は非表示。デスクトップは表示になりました。

何かしら別の原因があるようですが、OSのバージョンやモニター環境などはどうなっていますか?

追加の確認になりますが、
>なおタスクバー領域を考慮する設定にした場合でも,通常の最大化ウィンドウではこの問題は発生しませんでした.
こちらは、タスクバー領域を考慮する設定がオンの場合は問題ない。という事でしょうか?

K - 2222@Hy4II48W Reply 03/21
OSのバージョンはWindows 11 23H2のビルド22631です.モニタ環境はシングルモニタです.

>>なおタスクバー領域を考慮する設定にした場合でも,通常の最大化ウィンドウではこの問題は発生しませんでした.
>こちらは、タスクバー領域を考慮する設定がオンの場合は問題ない。という事でしょうか?
これは同設定のオンオフに関わらず全画面ウィンドウのみで発生するという意味です.ややこしくてすみません.

Gakuto Matsumura - Developer Reply 03/21
再現方法が分からないのでなんともですが、判定するフォアグラウンドの対象が変更された時に再判定するなどの変更を入れてみました。

こちらの環境では、仮想デスクトップの切り替えなどに完全に追従するのですが、もし以下でも全く同様で改善しないならば、具体的に発生している元となる全画面が何を対象としているか(例えば何々ブラウザYouTubeの全画面であるとか)を教えてください。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240321-181057.zip

K - 2222@Hy4II48W Reply 03/21
このテスト版ではWin+Dも含めてリリース版で非表示にならなかったり表示されないままになっていた操作をしても正しく非表示になったり表示されたりすることが確認できました.ありがとうございます.
update
Reply

Issue NVIDIA RTXで スリープ復帰後 ファン回転数などを取得できない
#1034
R.A - 2255@STEfXenB Reply 2024/03/12 18:06
NVIDIA RTX4070Tiにて、スリープ復帰後にファン回転数が0RPMになります。

100%確実にスリープ復帰後に再現される、と確証をもってお答えはできないのですが、少なくとも数時間間をおいて復帰させるとファン回転数が0RPMのまま変化しません。
諸事情ありWin10をクリーンインストール、その際thilmera7も再インストールされたのですが改善はされませんでした。(クリーンインストール前も後も同じ問題が発生)
セミファンレス設定によりファンが回転していないというわけでもありません。GPU負荷を掛けファンの物理的な回転を目視確認しても0RPMのままになります。
thilmera7を再起動すると問題なく回転数が表示されます。
問題が発生した際のレポートとthilmera再起動後のレポートを見比べると、DXGIにいくつか取得できていない項目が見受けられます。(添付します) ただ、少なくともGPU温度はリアルタイムで表示できていました。

MSI Afterburnerによる回転数制御でアイドル時1200RPMまで回す設定をしておりますが、Afterburner未実行の環境でも再現されたため関連性は低いものと思われます。

OS:Windows10 Pro
使用GPU:玄人志向(GALAX) RTX4070Ti GG-RTX4070Ti-E12GB/OC/TP2
GeForceドライバ:551.23~551.61
(MSI Afterburnerによる回転数制御有)

レポート: 添付

[appended] zip

Gakuto Matsumura - Developer Reply 03/12
報告ありがとうございます。

正直、原因や情報の出どころのルートは環境や状況により様々なので、どこがどうなってるのかを確認するためにログ出力版ビルドにてスリープ前後の状態をとってほしいです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240312-184602.zip

DXGI, NVAPI, NVMLのどれかの対象ハンドル自体がリセット再生成されていて、内容が古いから情報とれなくなってるのだと思います。

R.A - 2255@STEfXenB Reply 03/13
ありがとうございます。
起動直後、数分のスリープ、半日程度のスリープ時のログを添付いたします。

[appended] zip

Gakuto Matsumura - Developer Reply 03/16
対応遅れておりすみません。

実際のスリープにて実験などを行い、スリープからの電源復帰のコールバック後に、一部のハンドルの再収集を行うようにしてみました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240316-001504.zip
こちらで解決されるか確認をお願いします。

R.A - 2255@STEfXenB Reply 03/17
対応に感謝します。
16日のバージョンでは、少なくとも12時間弱程度のスリープ後ファン速度を取得できていたことを確認しました。

実際に問題が解決したと確証がとれるか、引き続き試してみたく存じます。ありがとうございます。

(不要かもしれませんが、こちらは生成されたデバッグログです。)

[appended] txt
update
Reply

[Closed] Report サウンドアナライザーの音階表示
#1032
retsam - 2247@uPwZP1ZPwwGPP01XZ2Xm/JgJX0ZtJt Reply 2024/03/06 07:51
サウンドアナライザーでスペアナの上に、小さく音階名が表示されていますが、この音階名とスペアナの位置関係は合っていますでしょうか?
当方の環境だと、440Hzの正弦波をならしたときに、A5の位置にピークが立ちます。
音階上はA4のはずですが
880Hzの時はA6、1760Hzの時はA7の所にピークが立ち、1つずれている気がします。
なにか設定の関係によるずれでしょうか?

retsam - 2247@uPwZP1ZPwwGPP01XZ2Xm/JgJX0ZtJt Reply 03/06
スクリーンショットを添付します
パスなしです

[appended] zip

Gakuto Matsumura - Developer Reply 03/06
報告ありがとうございます。

内部の計算結果とそれに当てられる内容、及びHzの対応表を確認すると、たしかにscale=2での数字部分が一つ多いようでした。

また、調査段階でウィンドウの横幅を変更した時にスケールの比率が妙にずれたままになる問題が見つかりましたが、こちらはまだ未対応。

ひとまず先に、英語式音高の数値の調整と、ドイツ式音高の追加(+小文字表記)をしました。

ドイツ式音高の方は、譜面におけるどの位置が何なのかを楽典ひっぱりだし、耳できいて確認と調整をしましたが、英語式音高のほうはネットで適当に検索した表を見ているだけなので、正直感覚ではあってるのか判断つかない感じです。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240306-175943.zip

 ● サウンドアナライザーのスペクトラムスケール
  ・英語式音高の数字が一つずれていたのを調整
  ・ドイツ語式音高を追加
  ・A=440Hzの指定範囲を、432~444に拡大

retsam - 2247@uPwZP1ZPwwGPP01l21/tJXu/2lg1t2Z Reply 03/06
対応ありがとうございます。修正されているのが確認できました。
ちなみにこのスケール文字列ですが、スペアナの下側に表示させることは可能なのでしょうか?

Gakuto Matsumura - Developer Reply 03/06
スペクトラム側のスケール表示位置を下部にするオプションを追加しました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240306-212253.zip

retsam - 2247@uPwZP1ZPwwGPP010GwmuXgm1wGmggX Reply 03/07
ありがとうございます。下側に表示できました。
個人的には下にある方がしっくりきます。

CLOSED : The added content will be notified to the administrator as usual.

update
Reply

Report 起動時の重要なお知らせが毎回表示される
#1030
屋久 - 2252@1PwZZX1/P/2XPP/2gf21u102ZJJ/t/tJ Reply 2024/02/28 09:19
左下の再表示しないにチェックを入れて閉じても、起動時の重要なお知らせが毎回表示されてしまいます。1~2か月前くらいまでは何ともありませんでした。
初回だけ強制表示で2回目以降は再表示しないのをデフォルトの動作にしてもらえないでしょうか。

Gakuto Matsumura - Developer Reply 02/28
報告ありがとうございます。

この問題はこちらでは再現できず、再表示しないにチェックした場合、次回以降は自動的に表示されないという意図した状態になっていました。

ただ、毎回、というものが、最近のお知らせの内容が更新されて別の通知としてID変更した頻度の話ならば、それは2回目以降としたところで同じ回数が表示されるかと思います。

ひとまず、使用しているバージョンとOS。"thilmera7.ini"をここに添付して下さい。
設定ファイルをみて再現できるか確認してみます。

屋久 - 2252@1PwZZX1/P/2XPP/2gf21u102ZJJ/t/tJ Reply 02/28
レスありがとうございます。
当方環境は 0b181 Rev.2
Windows10 22H2 です。
毎回というのは毎日1回以上シャットダウンして毎日1回以上起動させている状況です。
iniファイル添付させていただきます。

[appended] ini

Gakuto Matsumura - Developer Reply 02/28
確認したところ、たしかに既読IDは最新ではありませんでした。

iniファイルを元に、win10にて再度表示しないチェックをいれた上で「閉じて起動」「OS再起動」「OSシャットダウン」を試してみましたが、起動後に再び表示される不具合は確認されませんでした。

前提として、配信IDが更新された場合は、「再度表示しないチェック」を入れない限りは表示されるという仕様なので、「再度表示しないチェック」を過去に一度でもチェックしていたら、それ以降は表示されなくなるという仕様ではないですが、それとは別に再表示されてしまいますか?

屋久 - 2252@1PwZZX1/P/2XPP/2gf21u102ZJJ/t/tJ Reply 02/28
OS起動後thilmera7も自動起動して起動時の重要なお知らせが表示される
→左下の今後表示しないにチェックを入れ右上の×をクリックで閉じる
これを毎日行っているという状態です。

Gakuto Matsumura - Developer Reply 02/28
どこが原因なのかがわかりませんが、少なくともそのフローは意図していないものですね…

win10にてサービスからの自動起動を設定して、上記内容をしてから再起動などを試してみましたが、正しく既読IDは更新記録され、起動時の再表示はでませんでした。

まず確認してほしいのは、送信されたiniを元に起動した後、「→左下の今後表示しないにチェックを入れ右上の×をクリックで閉じる」をして、タスクトレイアイコンなどからプログラムを閉じて、もう一度起動する。
この手順で表示されるかを確認して下さい。

もしこれでも出るのならば、設定ファイルが出力される前にプログラムがクラッシュしているような系統のトラブルが考えられます。

屋久 - 2252@1PwZZX1/P/2XPP/2GJGwt0/120X2Zm2G Reply 02/28
thilmera7を終了してもう一度起動ところ、重要なお知らせは表示されませんでした。
その後PCをシャットダウンして起動し直したところ、重要なお知らせが表示されることはありませんでした。
一度手動で終了したのがよかったのでしょうか。ともかく改善したようです。
手動で終了してみるという考えには及ばなかったので助かりました。
ありがとうございました。お手数おかけしてすみません。

Gakuto Matsumura - Developer Reply 02/29
ありがとうございます。

それで直ったということは、やはりシャットダウンが正しく行われていないか、シャットダウン時に正しく設定ファイルを更新できていないですね。

要するに、終了時に保存すべきデータが一切保存されていないということなので、最も表面化して分かりやすいのがたまたま重要なお知らせの既読IDであっただけで、シャットダウン時に次回継続するためのデータが更新されずに毎回消失して、OS起動の度に昔の設定に先祖返りしているようです。

シャットダウン時に何が起こっているのかは実際にログをとってみないとわからないですが、たとえば「コンピューターの管理」>「システムツール」>「Windowsログ」>「Application」に、シャットダウンしたあたりの時刻で、thilmeraのプログラムがエラーとなっている箇所はありますか?

もしそのエントリーがあれば、中身が何かが知りたいです。
無いならば、今度はOSの破損がないかの確認と、それでも発生するならば何かしらのログ出力…どうするかは考えますが、トラブルがシルメラの内部と外部のどちらで発生しているのか確認する必要がありそうです。
update
Reply

Report Disk I/Oについて
#1031
くま - 2253@PPwZl1PwwtllPPuP/2gulJf0tffwflG Reply 2024/02/28 10:06
読み書きが0なのにドライブレターが表示される。
System:H67DE Processor:i7-2600 Windows10

Gakuto Matsumura - Developer Reply 02/28
ありがとうございます。
こちらヘルプのQ&Aに記載しました。
過去にも類似する質問があったのですが、途中で応答がなくなったためヘルプに記載するのを失念していました。

回答と説明としては以下になります。

Q: DiskIOで、読み書きが両方0なのにドライブレターが表示される
A: DiskIOに表示されるドライブレターは、論理ドライブ全体が使用中であった時間がどの程度あったかのパーセンテージが最も多いものが表示されます。
ファイル等のデータの読み込みと書き込みに含まれない処理も含まれるため、読み込みと書き込みが共に0バイトと書かれていても発生します。

thilmera.com/page-help-37
update
Reply

[Closed] Question 下罫線を表示させるには
#1029
キャシー - 2245@uPwZ22Pt/wPPlGf02/m/wJwJ/wZPfl Reply 2024/02/26 09:38
thilmeraをアップデートしたところ、下罫線が表示されなくなりました(添付ファイル)。表示項目数を変更すると一時的に描画されるのですが、すぐに消えてしまいます。前回のアップデート時にも同様の症状が出たのですが、thilmeraのアンインストール、再インストールで改善しました。アンインストール、再インストール以外に回避方法があれば、教えてください。

[appended] zip

Gakuto Matsumura - Developer Reply 02/26
報告ありがとうございます。
どのバージョンからどのバージョンに更新したかによるのですが、原因を調べるために問題が発生している状態の設定ファイル"thilmera7.ini"が必要です。

これを元にこちらで再現ができれば、そうなっている原因を調べて対処する形。
再現できなければ、テスト番を出しつつ対処する形。

になります。

Gakuto Matsumura - Developer Reply 02/26
> 再現できなければ、テスト番を出しつつ対処する形。
再現できなければ、調整または状態のログを出すテスト版でリレーしながら調整していく形。

また、この症状はがアップデート時に必ずなるか。
アンインストールとありますが、現行ではアンインストールというものは存在しないので、どのような処置をしたかも合わせて知らせて頂けると助かります。

キャシー - 2245@uPwZ22Pt/wPPlGf02/m/wJwJ/wZPfl Reply 02/26
"thilmera7.ini"を送付します。また、アンインストールですが、UACスタートアップサービス削除後に、thilmera7をフォルダごと削除しました。その後、ZIPファイル化をダウンロードしてインストール、再設定を行いました。また、この症状は前回(起動時にアップデートの表示が出たので、それでアップデート)と本日(同様にアップデートの表示が出たのでそれを実行)、発生しています。その前のアップデートでは、GPUファン表示の件がありましたので、確認していません。それより前のアップデートは覚えていません。

[appended] zip

Gakuto Matsumura - Developer Reply 02/26
① 問題の修正テスト
なかなか複雑な問題ですが、以下の方針で修正してみました。

 枠線の表示が、部分更新のフレーム時に欠乱するケースへの対処。
  ・サイドマージン指定が1または0の場合、枠線の内側と外側は無い状態で固定
  ・部分的に更新されるエリアが上下の枠線に重なっている場合、エリアを線内に収まるようにクリップ補正

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240226-151702.zip
確認をお願いします。


② 再設置的な話
今回のケースでの再設置は、再設置で直ったのではなく、標準設定や、手動で元に近いように設定していった過程で、問題を引き起こしていた設定とは異なる状態になっているだけかと思います。
元の設定を再現するか、元の設定をコピーすれば、同じ環境ならば再設置しても必ず再現するタイプの問題になります。

このあたり、そもそもポータブルタイプで、インストールやアンインストールの概念がない現行ではなかなか難しいところですが、設定を全て初期化するとか、修復インストール(ローカルが壊れてるかもれしない場合にクラウドから再度上書きする)のようなものに需要があるという感じなのかな…

例えば今回における再設置は、"thilmera7.ini","thilmera7.ini.bak","thilmera7.ini.bak2"を消せば同等になります。

Gakuto Matsumura - Developer Reply 02/26

こちらリリースチャネルの方にて更新しておきました。

キャシー - 2245@uPwZ22Pt/wPPlGuJX2ZlmtZm/tuXJ0 Reply 02/26
"thilmera7.ini"、"thilmera7.ini.bak"、"thilmera7.ini.bak2"を削除後にthilmeraを起動したところ、下罫線は非表示のままでした。そこで、UACスタートアップサービス削除後に、thilmera7をフォルダごと削除、さらに、thilmera7.upd.exeを起動して、”Program Files (x86)”に"thilmera7”を展開して起動したところ、初期状態でも下罫線が表示されませんでした。ここで、手動で元の状態に近いところまで設定を戻しましたが、下罫線は表示されませんでした。thilmeraを一旦終了して、もう一度起動したところ、アップデートの表示が出て、アップデートを「いいえ」にしたところ、thilmeraが全く表示されず、コンピューターを再起動しました(アップデートの「いいえ」を選択した時にthilmeraが落ちたのか、何かの裏に隠れてしまったなどの調査をしないで、コンピューターを再起動しました)。コンピューターを再起動するとthilmeraが自動起動しアップデートの表示が出たので、今度は「はい」を選択したところ、thilmeraは表示され、下罫線も表示されました。さらに、本日送付した"thilmera7.ini"を"thilmera7”に戻して(上書きして)thilmeraを再起動したところ、下罫線は表示された状態のままでした。
 以上からアップデートで下罫線が表示されるようになったのは、リリースチャネルが更新されたことによるものだと思います。テスト版の評価はできませんでしたが、解決して頂きまことにありがとうございました。

Gakuto Matsumura - Developer Reply 02/26
詳細と確認ありがとうございます。

設定と再設置に関しては余計に混乱させる状態になってすみません。

冒頭にあった「アンインストール、再インストールで改善した」という、改善後と前に差があるとしたら、実行ファイルやリソースの方ではなく、設定ファイルの中身の問題の可能性が高い。という趣旨の話でした。
ただ、よく読んでみると「前回の似た症状の時は」だったので、今回の症状に関しては、そもそも再設置しても改善されたわけではなかった。ということだと思います。

再設置などが上級者向けで分かりにくいという問題は確かに間違いない事なので、再設置したら直るかどうかと、再設置の難解さは別問題として、それはそれで今後考えていきます。

CLOSED : The added content will be notified to the administrator as usual.

update
Reply

Issue 設定の表示順序について
#1027
みどり - 2251@uPwZl2PtPwPP2J0wttf0m0/XwuZwg Reply 2024/02/25 15:36
表示順序欄で調整できる「下部の余白」が正しく機能する項目とそうでない項目があります。

再現手順
1. thilmera7_0b181.zipをDLして新規フォルダに解凍してthilmera7-win64.exeを起動
2. 設定→表示順序を開く
3. 「メモリ」の優先度と余白の数値を変更する
 (これは問題なく動作してる)
4. 「ディスクI/O」の数値を変更する
 (優先度を増減させると表示位置は変わるが、余白を増やしても変化がない)
5. 「論理ドライブ表示」の数値を変更する
 (論理ドライブ表示は初期設定OFFなので優先度を増減しても何も変わらないが、余白を増やすと「ディスクI/O」の下に余白ができる)
6. 「論理ドライブ表示」の余白を増やした状態で「ディスクI/O」の優先度を増減してみる
 (実際は「論理ドライブ表示」の余白ではなくて「ディスクI/O」の余白だということが確認できる)

「ディスクI/O」や「論理ドライブ表示」以外にも下部の余白が正しく機能していない項目が複数あるので、全項目に対して確認していただきたいです。

この表示順序欄には実際に見えている項目だけを表示したほうが良いと思います。表示していない項目の順序を入れ替えたいとは思わないでしょうし。(もしくは実際に表示している項目だけを表示するか全項目を表示するかをON/OFFで切り替えられるようにするとか)

また、各項目の優先度を設定するのではなく、各項目をドラッグ&ドロップで入れ替えられるようになると直感的に分かりやすくなると思います。ドラッグ&ドロップできないとしても、優先度を変えてから設定欄を開き直すと各項目の表示順序が実際と同じ並びに入れ替わっていると良いなと思います。

さらに、各項目の余白は下部だけでなく上部も設定できるほうが便利だと思います。各項目が実際と同じ並び順で表示されているのであれば余白は下部だけでもいいと思うのですが、特定の項目の上に余白を作りたいときその上の項目を一覧から探さないといけないのが面倒だと感じました。

Gakuto Matsumura - Developer Reply 02/25
報告ありがとうございます。

余白、そんなのもあったなと忘れてましたが、確認したところ設定上の番号がそのまま設定先の番号になっていたらしく、順序の項目表示と異なる場所が設定先になってました。

① 余白指定の欄が実際の参照先とずれているバグ
余白の設定を、項目名と同一の参照先(スロット番号)に合わせたテストを作成しました。


> 優先度を変えてから設定欄を開き直す
こちらはメインウィンドウの話ではなく、設定欄の方で、現在の順序指定の順番で出てきてほしいということですよね。

試しにこれもテストにて作ってみました。
開いた時(設定ウィンドウ上の設定項目が生成された時)の優先度順(実際に処理される順番とほぼ同等)で並ぶようにしました。

以下テストにて確認して頂けると助かります。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240225-171540.zip



> 表示順序欄には実際に見えている項目だけを表示
それぞれの項目が実際に表示されているかされていないかは、設定内容ベースだと判断が難しく、特定の設定がオンかオフならば表示されるされないという単純なものでもないので、ちょっと実現方法を検討してみます。

恐らく、項目の対象となる分類が、最終的に実際のウィンドウに描画を行ったかどうかを一定期間記録するような方式になるかなと思いますが、対象外フレームではスキップされたりするので、実装ベースを確認しながら確認してみます。

あと、消してしまうと今度は表示切り替えしたのに欄がない!となるのも難しいですね。
なにせキーマップやホットキーでも表示の切り替えがあったり、ハードウェアの状況により消えたり出たりするので…


> 各項目の余白は下部だけでなく上部も設定できるほうが便利
考えてはみますが、現行でもかなり設定欄も実際の中身も複雑なものになっているので、増やす場合にUIの構造をどうするか考えないと、見た時点で「うわー」となる人が増加しそうです。
何かしら完全に作りなおす事も含めて検討してみます。

完全に余白設定の存在そのものを忘れてました…

みどり - 2251@uPwZl2PtPwPP2J0wttf0m0/XwuZwg Reply 02/25
早速の対応ありがとうございます。
普段利用しているフォルダにもテスト版を上書きしてみましたが、表示順や余白の位置も今までと同じ位置になっていて問題ありません。

②は仰るとおり設定欄で一覧表示する順番のことでこれも問題ないと思います。

③は実際に描画された項目だけが設定欄に一覧表示されるのが理想的だと思いますが、今まで要望がなかったのでしょうからそこまで(描画を監視して一定間隔で記録)しなくてもいいのかもしれません。
表示順序欄に全項目を一覧表示するか、それとも(実際に描画しているかは関係なく)各設定がオンの項目だけを一覧表示するかのチェックボックスorスイッチを追加して切り替えできるようにするだけでもいいと思います。

④は②の並び替えで必要性が減ったので実装しなくても問題ないと思います。

設定のUIに関しては見た目と利便性のどちらを重視するかとか好みの問題もあるので何とも言えませんが、個人的にはスライダーを多用しているのが独特だなぁと感じます。
メモリ設定の「K,M,G 単位変更」のように数値以外の選択はプルダウンメニュー(htmlでいえばselectタグ)みたいなので選べるようにしたほうが分かりやすいと思います。

Gakuto Matsumura - Developer Reply 02/25
ありがとうございます。

順序の表示順はともかく、余白に関して内容が一致していなかったのは明らかなバグなので、Rev.1として更新しておきました。

元々、構想としてはもっとグラフィカルに入れ替えできたほうがいいというのはあったのですが、設定ウィンドウのUI上でどう作っていくのかは、対象の項目が今表示されているかを含めて改めて考えてみますね。

プルダウンメニューはなかなか難しく、ごく一部で項目が多すぎるために、OS標準のメニューにて設定する項目とかもありますが、プルダウンやメニューはまだ作れていない部分なので、最終的にどれをプルダウンにするかはともかく、そちらもToDoに追記しておきます。
update
Reply

[Closed] Issue フォーラムが正しく表示されない
#1028
K - 2222@Hy4II48W Reply 2024/02/25 17:43
このフォーラムですが,右コラムにもフォーラム内容が表示されてしまい,新規投稿する場所も右コラムになってしまっているので修正をお願いしたいです.

Gakuto Matsumura - Developer Reply 02/25
おお…すみません。
昨日の夜に変更したサイドオーバーのタイムラインをTwitterからBlueskyのインラインにしたものが、フォーラムの場合に相対位置がずれて誤作動していたようです。

直した上で、フォーラムページでタイムラインが横に書かれている必要なさそうと思ったので、とりあえずフォーラムでのTLサイド表示は常時オフに変えました。

K - 2222@Hy4II48W Reply 02/25
正常に戻っているのを確認しました.ありがとうございます.

CLOSED : The added content will be notified to the administrator as usual.

update
Reply

Request GeForceRTX Super Resolution Quality Levelの表示要望
#1026
retsam - 2247@uPwZP1ZPwwGPP01tX10wlu1Xf2XwmZ2 Reply 2024/02/17 22:43
もし可能でしたらGPUの表示項目として、GeForceRTXの現在のSuper Resolution Quality Level(1~4)を表示可能に出来ないでしょうか。
検討いただけると幸いです

Gakuto Matsumura - Developer Reply 02/17
ありがとうございます。

一応、NVIDIAコンパネ上のRTXのSuper Resolutionが、アクティブとなる状態にできるようにはしてみましたが、軽く調べた限りで、このSuper Resolutionの情報を取るような明確な手段が見つかりませんでした。

ちょっと改めて調べてはみますが、現時点で取れるものなのかは不明です。
Intel Arcの方はまさにそれそのものっぽいのが見つかりました。

retsam - 2246@uPwZP1ZPwwGPP01ttPwt/lXuPwXPXJ/ Reply 02/18
最近のドライバでレベルの自動設定が追加され、動画再生中はNVIDIACP内でアクティブ/非アクティブと現在の適用レベルが表示されるので、可能性があるかと思い要望させていただきました。

Gakuto Matsumura - Developer Reply 02/18
NVIDIAのコンパネの件は承知していますが、改めてNvAPIとnvmlのライブラリの最新の内容を、特定の語句ではなく全て確認しましたが、ニュアンスが近いものはディスプレイにおけるハイパーサンプリングというものくらいでした。

これはSuper Resolutionではなく、NVIDIA Image Scalingというモニターにおける倍率指定の方のようです。

Super Resolutionの方は、GPUの情報を取得するライブラリとは全く異なる、DLSSなどの、ガッチガチに超解像度に関するエリアにあるらしいです。

こちらでは、SuperSampling、VideoSuperResolution、ImageSuperResolutionなどが定義名に含まれるものがあるので、多分このあたりだとは思うのですが、現状では正直、NVIDIAの標準的に存在するライブラリに、これの状態をくださいな、といったら数値が返ってくるような簡単なものではなさそうな印象です。

調べるにしても、いずれ対応するにしても、単に追加すればすぐできる類ではなさそうなので、こちらは将来的に対応できるか検討していく、という感じになりそうです。
update
Reply

[Closed] Report [0ch] 0b180Dr22REV16更新後、横幅が小さくなった
#1024
横レス - 2213@pAEf4Ihy Reply 2024/02/15 13:40
0chにて、DEV12→DEV16更新後、thilmeraメインウィンドウの表示位置及び横幅などが勝手にリセットされました。
(x,y,hが 0、wが50に変更された模様)
モニタ2枚(サイズ違い)の環境で、左:メイン、右:サブ、メインで右上固定で使用しています。
DEV16の ini (本コメントに添付)とDEV12 のini を添付します。
また、ini_history フォルダの中身がおかしなことになっているので、別途報告します。

[appended] ini

横レス - 2213@pAEf4Ihy Reply 02/15
DEV12での ini を添付します。


[appended] ini

Gakuto Matsumura - Developer Reply 02/15
すみません、ini_history不具合の状況下で、前と後のiniの保持とても助かります。

ただ、古い方のiniでロードしても、正しく幅は137となり、確認できませんでした。
新しいiniは、中身自体が0,0,50,0という、初期値+最低保証値となっていました。

念のため、#1025における以下にて、再度確認をお願いします。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240215-171928.zip

Gakuto Matsumura - Developer Reply 02/15
こちら、ミスによりテストと同一バージョンで配信してしまいましたが、ch0にて、このテスト版に加えて、可能性として心当たりのある部分の調整をしたものを更新しています。

CLOSED : The added content will be notified to the administrator as usual.

update
Reply

[Closed] Report [0ch] ini_historyフォルダ内に xxxx.backup1900-01-00-000000.iniしかない
#1025
横レス - 2213@pAEf4Ihy Reply 2024/02/15 13:57
#1023 の報告の際、ini差分を取るため ini_historyフォルダをみたところ、デフォルトの14日分が保存されているのを期待したら、以下のファイルしかありませんでした。
(DEV16へのアップデート直後に作られたバックアップの模様)

thilmera7.backup1900-01-00-000000.ini
thilmera7.upd.channel.backup1900-01-00-000000.ini
thilmera7key.backup1900-01-00-000000.ini
thilmera7uac.backup1900-01-00-000000.ini

なお、気付いたのがDEV16の更新時であり、いつからこの状態かは不明です。
(ini は #1023 と同じのため省略します。)

Gakuto Matsumura - Developer Reply 02/15
報告ありがとうございます。

こちら、たしかにそのようになっていました。
いつの時点からかの、設定をロードするタイミングを移動しなければならなかった修正の影響で、全体で共通とする時刻の取得がされる前の内容でファイル名が決定されていたようです。
メイン、サブのリリース、デバッグ全てその状態だったので、結構前からかと思います。

こちら以下にて修正しました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240215-171928.zip

横レス - 2213@pAEf4Ihy Reply 02/15
確認ありがとうございます。

テスト版にて、ini_historyフォルダに ini ファイルのバックアップが再起動時の時刻で生成されることが確認できました。

_
別件(サイズ等のリセット)については、しばらく様子を見ます。
取り急ぎ、ご連絡まで。

Gakuto Matsumura - Developer Reply 02/15
こちら、必ず再現されるというわけでもない印象だったでしょうか?

ひとまず、そうなりえる心当たりのある部分を修正したものを、ch0にて更新しておきました。

ちょっとこのテスト版と同じバージョンとして出してしまったので、このテスト版のままの場合は更新をお願いします。

CLOSED : The added content will be notified to the administrator as usual.

update
Reply

[Closed] Report 「マウスオーバー非表示」をOFFにしてもしばらくthilmeraが表示されない
#1021
elphe - 2235@1PwZwX1/PPZ/PPG2ZffGgulmmGPm/lt2 Reply 2024/02/11 19:15
#1020のテストビルドで行うと再現しやすいです
1. thilmeraのメインウィンドウを画面右端(タスクトレイの上)にもってくる。
2. 「縦幅最大」、「マウスオーバー非表示」をすべてONにする。
3. タスクトレイからthilmeraを右クリックし、そこからthilmeraをマウスオーバーで非表示にしながら「マウスオーバー非表示」をOFFにする。
4. thilmeraが現れない。マウスを離してもthilmeraは現れない。(不具合)
5. どこかをクリックするとか他のウィンドウを召喚するとかデスクトップに切り替えるなどするとthilmeraは現れる。(「ウィンドウ最前面」がOFFの場合は他のウィンドウの後ろに隠れることがある)

Gakuto Matsumura - Developer Reply 02/11
ありがとうございます。

確かに再現できたのと、それは想定してなかったので、とりあえずマウスオーバー非表示をオフへと切り替える時に通る場所で、マウスオーバー非表示に関するフラグをリセットして、ウィンドウを表示させるのと同等のコールも行うようにしました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240211-230453.zip

副作用でそうな気がしないでもないですが、設定変更時、かつオフへの切り替え以外は通らない所なので、多分いける…と思います。

変更内容:
 ● マウスオーバー非表示の設定を、非表示状態でオフに切り替えるとウィンドウが戻ってこない問題で、オフ時にウィンドウ表示をリセットして表示するように変更

elphe - 2235@1PwZwX1/PPZ/PPG2ZffGgulmmGPm/lt2 Reply 02/12
thilmeraが現れない不具合の解消は確認しましたが、少し奇妙な挙動がありました。
仕様かバグかわからないのでとりあえず報告しておきます。
1. 「ウィンドウ最前面」「ウィンドウ最背面」「マウスオーバー非表示」をOFFに、「アイコンクリックでアクティブにしない」をONにしておく
2. thilmeraのメインウィンドウに他のウィンドウを重ねるように配置し、thilmeraのメインウィンドウの一部または全部を隠すようにする
3. ここでタスクトレイのthilmeraを右クリックしても、thilmeraの隠された部分は隠れたままである
4. このままマウスカーソルをthilmeraのメインウィンドウ上(であった場所)で「マウスオーバー非表示」をONにし、そこからマウスカーソルを離すとthilmeraが前面に引きずり出される
5. 元々thilmeraを隠していたウィンドウをアクティブ化して再びthilmeraを隠しても、thilmera(があった場所)をマウスカーソルを近づけたあと離すと再びthilmeraが前面に引きずり出される
6. 再度thilmeraを隠しても、タスクトレイのthilmeraを右クリックするとメインウィンドウが前面に引きずり出される(3.と挙動が違う)

6.の症状は、4.でthilmeraをマウスオーバーしながらでなくても「マウスオーバー非表示」をONにすると発生します。

Gakuto Matsumura - Developer Reply 02/12
ありがとうございます。

以下にて変更の内容
・「アイコンクリックでアクティブにしない」の設定がある場合に、アクティブ化してしまうルートの調整(スクリーンショット関連でのハンドリングは現行のまま)
・「ウィンドウ位置リセット」「最小化」「元に戻す」などで、マウスオーバー非表示関連での一時フラグをリセット
・関連して見つけた、「アイコンクリックでアクティブにしない」設定で、「ウィンドウ位置リセット」をしても他のウィンドウの裏に隠れて見えない問題で、フォアグラウンド復帰を必ずコールするように変更

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240212-191803.zip

elphe - 2235@1PwZwX1/PPZ/PPG2u1GgXumXJ1lXwf0 Reply 02/12
とりあえず暫定的な報告をしておきます。書き忘れていましたが、OSはWindows10です。
1. thilmeraを画面右下(タスクトレイのすぐ上)に配置する
2. 他にも色々ソフトを常駐させてthilmeraのアイコンを「∧」みたいな表示のところに押し込む
3. 「マウスオーバー非表示」をONにする
4. thilmeraの設定ウィンドウを出しておく(5.と6.のせいで右クリックメニューからは「マウスオーバー非表示」をOFFにできなくなる可能性があるため)
5. タスクトレイアイコンを右クリックして右クリックメニューを出そうとすると、出ないことが多い
6. 右クリックメニューが出ても、thilmeraが表示されていた領域からマウスカーソルを離すと右クリックメニューが消えてしまう

おそらくこの挙動の大きな原因は「マウスオーバー非表示が終了すること」だと思われます。
実はこれまでのバージョンでも、マウスオーバーでthilmeraを非表示にしながらタスクトレイアイコンを右クリックすると多くの場合一瞬だけthilmeraが表示されたのち「マウスオーバー非表示」が適用されて非表示になっていました(極めて軽微な、許容すべき不具合と判断してこれまで報告していませんでした)。これが6.だけでなく5.の症状を引き起こしていると考えられます。

Gakuto Matsumura - Developer Reply 02/12
こちら、一応試してはみたのですが、どういう問題なのかよくわかりませんでした。

上記の問題再現にはもう少し情報がいるようです。
たとえば、「∧」みたいな表示に入れる入れないに関わらず、「アイコンクリックでアクティブにしない」の場合、アイコンの左クリック右クリックで、他のウィンドウの後ろにある場合に表に出てこないのは、今回の修正の影響によるものですが、これは意図的なもので、正しいです。

おそらく、現象の再現に必要な要素が、「∧」みたいな表示のところに入れるか入れないかで変わる、カーソルとメニューとメインウィンドウの位置関係の問題かと思いますが…

まず、「アイコンクリックでアクティブにしない」の場合に、他のウィンドウの後ろにいた場合に表にはでてこないようにした。という前提を踏まえて、再度この問題がどういう問題なのかと、どういう挙動が望ましいのかを教えてほしいです。

Gakuto Matsumura - Developer Reply 02/12
補足として、「ウィンドウをアクティブにしない」という条件を維持したまま、後ろにあるウィンドウを前に持ってくるのは難しいようです。

elphe - 2235@1PwZwX1/PPZ/PPG2u1GgXumXJ1lXwf0 Reply 02/12
すみません、こちらのスレッドでも言葉足らずでした。

つまり、「特定条件下で右クリックメニューが強制的に消されてしまい、右クリックメニューが使えない」という別の不具合のせいで今回の修正内容(の一部)を確認できなかった、ということです。
タスクトレイアイコンを右クリックしたあと、マウスクリックしてもないのに右クリックメニューを強制的に消されることがないのが望ましい挙動です。

しかし、どうやらそちらの環境では発生していないようですね……
とりあえずこちらの環境で問題が発生しているiniファイルを添付しておきます。

[appended] ini

Gakuto Matsumura - Developer Reply 02/12
ありがとうございます。

最新のiniと前記の内容を合わせて試すと再現に成功して、メニューを開いた状態でマウスオーバー非表示を通過させるとメニューが消える。という現象の修正を試みてみました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240212-234355.zip

elphe - 2235@1PwZwX1/PPZ/PPG2u1GgXumXJ1lXwf0 Reply 02/13
右クリックメニューが満足に使えるようになりました!
また、タスクトレイアイコン右クリックでthilmeraのメインウィンドウが全面に引きずり出されなくなったのを確認しました!

ただ、「マウスオーバー非表示」をONにした後マウスカーソルを動かすとthilmeraが前面に引きずり出される挙動は残ったままです。以下に手順を記します。
1. 「ウィンドウ最前面」「ウィンドウ最背面」「マウスオーバー非表示」をOFFに、「アイコンクリックでアクティブにしない」をONにしておく
2. thilmeraのメインウィンドウに他のウィンドウを重ねるように配置し、thilmeraのメインウィンドウの一部または全部を隠すようにする
3. タスクトレイアイコンの右クリックメニューから「マウスオーバー非表示」をONにする
4. 他のウィンドウをアクティブ化せず、thilmera(があった場所)にマウスカーソルを何度か出し入れすると、thilmeraが前面に引きずり出される
5. 元々thilmeraを隠していたウィンドウをアクティブ化して再びthilmeraを隠しても、thilmera(があった場所)にマウスカーソルを何度か出し入れすると、再びthilmeraが前面に引きずり出される
6. この状態で元々thilmeraを隠していたウィンドウをアクティブ化して再びthilmeraを隠そうとしても、そのウィンドウはアクティブ化されたままなのでそのウィンドウではthilmeraを隠せない
7. 他のウィンドウを召喚すれば隠せる
8. でもthilmera(があった場所)にマウスカーソルを何度か出し入れすると、またthilmeraが前面に引きずり出される
9. 最初thilmeraを隠していたウィンドウを再度アクティブ化するとthilmeraはそのウィンドウに隠されるが、もう一度thilmera(があった場所)にマウスカーソルを何度か出し入れすると、またthilmeraが前面に引きずり出される

Gakuto Matsumura - Developer Reply 02/13
最終の添付されたiniと、上記に従ってみましたが、再現できませんでした。

メインメニューからマウスオーバー非表示への切り替えを、ウィンドウ範囲内と範囲外の両方試してみて、何度か、とあったので何度も往復してみましたが、とくに前面にでることはありませんでした。

ウィンドウの切り替え対象としてテストを行ったのは、Thunderbirdというメーラーで、ワークエリア全面のノーマル配置です。

上記の比較対象となっている切り替え先のウィンドウは、対象が何であっても起こりますか?

もう少し情報が必要なようです。

elphe - 2235@1PwZwX1/PPZ/PPG2u1GgXumXJ1lXwf0 Reply 02/13
こちらが切り替えウィンドウとして試したのはFirefox, Thunderbird, VSCode, エクスプローラー(Windows10標準), 設定(Windows10標準)で、ウィンドウが最大化されているかを問わず発生します。往復の回数は最少で1往復、確認されたものの中で最多でも9往復でした。1~3往復が最も頻繁な印象で、7往復以上はかなり稀です。

あまり設定は変更していないつもりですが、最新のiniファイルを添付しておきますね。

[appended] ini

Gakuto Matsumura - Developer Reply 02/13
最新iniにて再度試して再現できました。

最新の問題の解決と、解決した場合は、関連して副作用の問題がないか確認をお願いします。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240213-111935.zip

Gakuto Matsumura - Developer Reply 02/13
あぁ、根本的な原因が新たに見つかり、他での修正要望により、一部環境にてスタートアップ時の実行で見える状態で開始されない問題への対処にかかってくるようです。

両立させられる手段があるか試してみます。

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 Reply 02/13
どうやら解決していないようです……
>1. 「ウィンドウ最前面」「ウィンドウ最背面」「マウスオーバー非表示」をOFFに、「アイコンクリックでアクティブにしない」をONにしておく
>2. thilmeraのメインウィンドウに他のウィンドウを重ねるように配置し、thilmeraのメインウィンドウの一部または全部を隠すようにする
>3. タスクトレイアイコンの右クリックメニューから「マウスオーバー非表示」をONにする
>4. 他のウィンドウをアクティブ化せず、thilmera(があった場所)にマウスカーソルを何度か出し入れすると、thilmeraが前面に引きずり出される
>5. 元々thilmeraを隠していたウィンドウをアクティブ化して再びthilmeraを隠しても、thilmera(があった場所)にマウスカーソルを何度か出し入れすると、再びthilmeraが前面に引きずり出される
>6. この状態で元々thilmeraを隠していたウィンドウをアクティブ化して再びthilmeraを隠そうとしても、そのウィンドウはアクティブ化されたままなのでそのウィンドウではthilmeraを隠せない
>7. 他のウィンドウを召喚すれば隠せる
>8. でもthilmera(があった場所)にマウスカーソルを何度か出し入れすると、またthilmeraが前面に引きずり出される
>9. 最初thilmeraを隠していたウィンドウを再度アクティブ化するとthilmeraはそのウィンドウに隠されるが、もう一度thilmera(があった場所)にマウスカーソルを何度か出し入れすると、またthilmeraが前面に引きずり出される
このうち変化したのは、手順4.と5.と8.と9.で「何度か」から「一度で必ず」になったこと、手順4.を経由してもしなくても手順5.や手順7.に移れるようになったことです。

また、「マウスオーバー非表示」がONの状態でタスクトレイアイコンを右クリックすると、その後他のウィンドウをクリックしても右クリックメニューが消えず、thilmeraのタスクトレイアイコンを右クリックしても右クリックメニューの表示位置は全く変わりません。右クリックメニューを消すにはメニューから一つを選択するしかなくなります。

[appended] ini

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 Reply 02/13
>あぁ、根本的な原因が新たに見つかり、他での修正要望により、一部環境にてスタートアップ時の実行で見える状態で開始されない問題への対処にかかってくるようです。

>両立させられる手段があるか試してみます。
すみません、このコメントが見えていませんでした。

Gakuto Matsumura - Developer Reply 02/13
懸念していた別の問題への修正に関しても調べてみましたが、どうもそれでもなく、さらに根本的な部分にあるようです。

ためしにマウスアクション系の非表示から復帰時のウィンドウのコール方法を変えてみましたが、今度はカーソル端設定、またはマウスオーバー非表示+カーソル端表示、全画面非表示で一切表にでてこなくなり、用途からすると明らかにおかしくなってしまいました。

マウスアクション系は、マウスオーバー非表示、カーソル端表示、全画面非表示のそれぞれの組み合わせ、かつそれぞれのトグルありなし。かつそれぞれの最前面、ノーマル、最背面に対して、各々の使い方をしているユーザーの互換性を考慮しないといけません。

0b180の修正開始から、これらの修正をしては別の人の修正がはいり、その修正が修正の必要性を起こす。というのを繰り返していて、どれもがそれぞれの人の環境でしか確認しづらい。というのが今の流れで、問題となっている点も、これらの修正の影響も多く含まれています。


なので、今回の最新の問題は不具合の修正ではなく、全く別の新たな要素として、「マウスオーバー非表示からの復帰を非アクティブで行う」という設定を追加して分岐するしかなさそうです。



>また、「マウスオーバー非表示」がONの状態でタスクトレイアイコンを右クリックすると、その後他のウィンドウをクリックしても右クリックメニューが消えず、thilmeraのタスクトレイアイコンを右クリックしても右クリックメニューの表示位置は全く変わりません。右クリックメニューを消すにはメニューから一つを選択するしかなくなります。

こちらは全く別の問題で、対象のウィンドウが非表示であるからですが、ここはOSの挙動との兼ね合いなので、これもどうすればよいのかは難しい所です。

そもそもウィンドウが非表示なのだから根本的解決はしようがないので、こちらの問題の対策方法として、マウスオーバー非表示をウィンドウを非表示にせず、モニター範囲外にとばしてそこで待機させる仕様。という案もありますが、これはやりだすとあまりにも根幹の変更すぎて、現在の修正フェーズではなく、新バージョンの作成+長期間テストな感じかなと思います。

Gakuto Matsumura - Developer Reply 02/13
ひとまず、設定による分岐を作成しました。
マウスオーバー非表示のオプションとして、「非アクティブで復帰する」を追加しました。

内容としては、これをオンにすると、マウスオーバー非表示などから復帰する際に、前面に出てしまうのをほぼ防ぐことができる。

今までのユーザーの使用と互換性がないので、デフォルトではオフ設定。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240213-133300.zip

以下既知の問題は、次回以降の新たな開発時での対処とします。
・「アイコンクリックでアクティブにしない」でのメニュー動作
 この設定がオンの場合、タスクトレイアイコンからメニューを開いて、メニュー以外をクリックしても、メニューは閉じられません。
 この挙動は、メニューの元となるウィンドウがアクティブではない事が理由で発生するため、今後予定されている、メニューUIの完全独自化にて対応できるか検討する予定です。

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 Reply 02/13
「非アクティブで復帰する」、うまく機能しています!
かなりお手数をおかけしましたが、対応ありがとうございます!

>・「アイコンクリックでアクティブにしない」でのメニュー動作
> この設定がオンの場合、タスクトレイアイコンからメニューを開いて、メニュー以外をクリックしても、メニューは閉じられません。
確かに1つ前のテストビルドでも「マウスオーバー非表示」の設定に関係なく発生し、「アイコンクリックでアクティブにしない」に関連して発生していました。私が何か勘違いしていたようです。訂正ありがとうございます。

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 Reply 02/13
そういえば、「最前面表示」「最背面表示」をOFF、「アイコンクリックでアクティブにしない」「マウスオーバー非表示」をONの状態でタスクトレイアイコンの右クリックメニューから「マウスオーバー非表示」をOFFにすると、別のウィンドウによってthilmeraが隠されていてもthilmeraが前面に出てくる挙動がありますが、これは仕様ですか?

私としては、他のウィンドウをクリックすればthilmeraは再び隠れるので不便していませんし、どうしても嫌なら「ウィンドウ最背面」で防げますし、むしろマウスオーバー非表示ではなくウィンドウで隠れている場合にもユーザーが混乱しないいい仕様だと思っていました。

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 Reply 02/13
すみません、追加の検証によると、上記の挙動はマウスオーバー非表示にしながらでのみ発生しました。

Gakuto Matsumura - Developer Reply 02/13
>「マウスオーバー非表示」をOFFにすると、別のウィンドウによってthilmeraが隠されていてもthilmeraが前面に出てくる挙動がありますが、これは仕様ですか?

こちら、ここの11日分によりり変更された以下の仕様ですが、そうではないということでしょうか?
これは冒頭の不具合報告により修正したものになります。

 ● マウスオーバー非表示の設定を、非表示状態でオフに切り替えるとウィンドウが戻ってこない問題で、オフ時にウィンドウ表示をリセットして表示するように変更

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 Reply 02/13
> ● マウスオーバー非表示の設定を、非表示状態でオフに切り替えるとウィンドウが戻ってこない問題で、オフ時にウィンドウ表示をリセットして表示するように変更
質問が分かりづらかったですね。この「ウィンドウ表示をリセットして表示する」というのは、thilmeraと他のウィンドウとの元々の前面/背面の関係を無視して最前面に表示するという意図を含むのかどうか、という質問だとお考えください。

例えば、元々thilmeraが他のどのウィンドウよりも前面に配置されていた状態で「マウスオーバー非表示」をOFFにした際にthilmeraが最前面に表示されるのは理解できます。

今問題にしているのは、thilmeraをThunderbirdの背面に配置した状態で「マウスオーバー非表示」をOFFにした際に、元々Thunderbirdに隠れていたthilmeraがThunderbirdの前面に表示され、thilmeraがThunderbirdの一部を隠すようになる挙動です。

前述の通りこれはいい仕様であるとも考えていますが、「マウスオーバー非表示」をOFFにしてもthilmeraと他のウィンドウとの前面/背面の関係が変わらないというのが直感的に期待される動作だとも思えますので質問させていただきました。

Gakuto Matsumura - Developer Reply 02/13
>この「ウィンドウ表示をリセットして表示する」というのは、thilmeraと他のウィンドウとの元々の前面/背面の関係を無視して最前面に表示するという意図を含む

意図した動作はこれの通りになります。

>「マウスオーバー非表示」をOFFにしてもthilmeraと他のウィンドウとの前面/背面の関係が変わらないというのが直感的に期待される動作

そもそも、マウスオーバー非表示は、使用中にオンオフするようなものではない。という前提で作成していますが、どのようなものを想定されていますか?

私の立場からすると、手動によりオフにしたのに、ウィンドウが見えない。戻ってこない。という事態になるほうがまずいと認識しています。

ただし、これの前提には、マウスオーバー非表示という属性の変更は、頻繁にするものではなく、メインメニューにこれがあるのは、復元方法がない(方法が難解)という意見が過去に多数あったからで、頻繁に行うためにメインメニューに入れているわけではないです。
復元しにくいという過去の意見がなければ、そもそもメインメニューには置くことが無かった項目になります。

Gakuto Matsumura - Developer Reply 02/13
メインメニューにおける「マウスオーバー非表示」は、緊急時の復旧用。という想定なので、もしマウスオーバー非表示にまつわる挙動の一部のオンオフをコントロールしたい。という場合は、それは別の機能として具体的にどういう動作にしたいかを、要件を元に検討していく必要があります。

つまり、マウスオーバー非表示のオンオフは、緊急時の強制リセットボタン。という立ち位置で、操作中にオンオフするならば、対象は最も根本にあたるその部分ではない。ということになります。

elphe - 2235@1PwZwX1/PPZ/PPG21f1m2f2mJ/0P1G2 Reply 02/14
意図された動作だったのですね。理解しました。

>>「マウスオーバー非表示」をOFFにしてもthilmeraと他のウィンドウとの前面/背面の関係が変わらないというのが直感的に期待される動作
>
>そもそも、マウスオーバー非表示は、使用中にオンオフするようなものではない。という前提で作成していますが、どのようなものを想定されていますか?
私が想定していたのは、「マウスオーバー非表示」「右下固定」がONで、うっかり「アイコンクリックでアクティブにしない」をON、「ウィンドウ最前面」をOFFにした状態で意図的にthilmeraを最前面に引きずり出す際に、マウスを右下領域から離さないと「ウィンドウ最前面」をONにしても表示されないと予見して一時的に「マウスオーバー非表示」をOFFにしたら、まだ「ウィンドウ最前面」をONにしてないのに最前面に表示されたとなると少し驚くだろうな、という程度でした。

>私の立場からすると、手動によりオフにしたのに、ウィンドウが見えない。戻ってこない。という事態になるほうがまずいと認識しています。
おっしゃるとおりで、もしそれが仕様、つまり開発者様の意図された挙動であるならば良い仕様だ、というつもりで質問しました。(この辺りも言葉足らずでしたね。すみませんでした。)

私の立場からはたとえ自然言語で記述されていても開発者様の意図を正確に汲み取ることはできず、thilmera自体も開発者様の意図に沿った挙動とそうでない挙動が混じっている現状です。(thilmeraに限らず、ソフトウェア全般に言えることですが)
たとえ良い挙動だとしても、それは開発者様の意図が反映されたからかどうかは(私にとっては)別の話です。挙動に害がなくても、開発者様の意図に沿わない挙動なのであれば報告の必要があると思い、どちらかわからなかったので質問という形を取りました。

>ただし、これの前提には、マウスオーバー非表示という属性の変更は、頻繁にするものではなく、メインメニューにこれがあるのは、復元方法がない(方法が難解)という意見が過去に多数あったからで、頻繁に行うためにメインメニューに入れているわけではないです。
>復元しにくいという過去の意見がなければ、そもそもメインメニューには置くことが無かった項目になります。
>メインメニューにおける「マウスオーバー非表示」は、緊急時の復旧用。という想定
そのような経緯があったのですね。丁寧な回答ありがとうございます。

Gakuto Matsumura - Developer Reply 02/14
詳細ありがとうございます。

ウィンドウには、「ウィンドウ最前面」「ウィンドウ最背面」「ノーマル」の3種類があり、今回の話の場合は、この「ノーマル」に該当します。
3種類は全く別枠という扱いなので、ノーマルの範囲内で前面にきたとしても、「ウィンドウ最前面」属性のウィンドウより前にくることはありません。

あくまで、ノーマル属性のウィンドウの中で、アクティブになる(手前にくる)という内容なので、ウィンドウ最前面にしていないのにウィンドウ最前面に切り替わってしまうというわけではないです。

>マウスを右下領域から離さないと「ウィンドウ最前面」をONにしても表示されない
「ウィンドウ最前面」の場合、他のウィンドウより後ろになって見えないという状態にはなならないので、ウィンドウ最前面にした場合、マウスオーバー非表示を解除しないと出てこないようなケースは考えにくいです。

質問や不具合報告や修正依頼で、最終的にソフトウェアの修正にならない場合でも、元となった疑問等は、ヘルプに記載する案内の内容に何が必要で、何が不足しているのかの参考になるので、とても助かります。

elphe - 2235@1PwZwX1/PPZ/PPG21lfflGPu2X/w1JwJ Reply 02/14
>あくまで、ノーマル属性のウィンドウの中で、アクティブになる(手前にくる)という内容なので、ウィンドウ最前面にしていないのにウィンドウ最前面に切り替わってしまうというわけではないです。
そこまで考慮していませんでした。ありがとうございます。

>>マウスを右下領域から離さないと「ウィンドウ最前面」をONにしても表示されない
>「ウィンドウ最前面」の場合、他のウィンドウより後ろになって見えないという状態にはなならないので、ウィンドウ最前面にした場合、マウスオーバー非表示を解除しないと出てこないようなケースは考えにくいです。
イメージとしては、
新規ユーザー「右クリックメニューから「ウィンドウ最前面」をONにした際にマウスカーソルがthilmeraにかかったままなので「マウスオーバー非表示」により表示されないままだろう。それはちょっと面倒なので、先に「マウスオーバー非表示」をOFFにしてから「ウィンドウ最前面」をONにしよう」

「マウスオーバー非表示」をOFFにしたタイミングでthilmeraが前に現れる

新規ユーザー、いささか動揺
という想定でした。
行動原理も「面倒」だったり結果も「少し驚くだけ」のかなり些細な話で、「ウィンドウが現れない」みたいな不具合の話でもなく、質問には答えるけどだいぶしょうもない話なので無視してよい、という意図で書いていました。色々紛らわしくてすみません。

Gakuto Matsumura - Developer Reply 02/14
それぞれ
・「ウィンドウ最前面」は、最前面属性への切り替え。
・ マウスオーバー非表示によるリセットは、各属性の範囲内でウィンドウをアクティブにする。

という、動作としては全く別の物なので、むしろ前の話の意図としては、他の後ろにあるウィンドウを前面に移動させる。という意図での「ウィンドウをアクティブにする」というメニュー項目がないのが一番の問題であるように思いました。

日本語の文面の意味としての「最前面」や「前面」という語句が、システム上の区分けの話なのか、見た目のウィンドウ位置が前か後ろなのか、のどちらの意味かによって、ユーザーが困惑するというのは確かにそうかと思います。

厳密な定義はちょっと記憶が曖昧ですが、元々は"TOPMOST"というWindows上の属性を、そのまんま日本語で書いたら最前面かなぁ。と書いたのが元なので、その時点から既に間違えているような気がしなくもない…です。

AIに投げてみると、「最前面に表示されるウィンドウ」あるいは「常に前に表示されるウィンドウ」と表現することが適切、と返ってきました。

ただ、設定の中には「常時」という、OSに備わっていないプロダクト固有の無理矢理な設定項目があるので余計ややこしいのですが、この項目があるがために、ウィンドウ最前面という設定そのものが、まるで毎回最前面にする機能。と誤認されるケースを生んでいる原因の一つのような気はします。

おそらく要点は、「ウィンドウをアクティブにする」というものが、「ウィンドウ最前面」とは別に、同時にメニュー内にはっきり存在している事だと思ったので、このあたりを整理し、ひとまずch0に次回更新予定のプレビューとして更新しました。

メインメニューに関係した変更内容は以下となります。

 ○ メインメニュー
  ・マウスオーバー非表示などの、緊急用の項目をサブツリーに移動
  ・「ウィンドウをアクティブにする」というシングルアクションを追加

elphe - 2235@1PwZwX1/PPZ/PPG2gGPg1gXtZtt2tuwZ Reply 02/15
>それぞれ
>・「ウィンドウ最前面」は、最前面属性への切り替え。
>・ マウスオーバー非表示によるリセットは、各属性の範囲内でウィンドウをアクティブにする。
>
>という、動作としては全く別の物なので、むしろ前の話の意図としては、他の後ろにあるウィンドウを前面に移動させる。という意図での「ウィンドウをアクティブにする」というメニュー項目がないのが一番の問題であるように思いました。

>おそらく要点は、「ウィンドウをアクティブにする」というものが、「ウィンドウ最前面」とは別に、同時にメニュー内にはっきり存在している事だと思ったので、このあたりを整理し、ひとまずch0に次回更新予定のプレビューとして更新しました。
良い機能ですね!まさか対応していただけると思っておらず、感激しました……!

CLOSED : The added content will be notified to the administrator as usual.

update
Reply

[Closed] Report 起動時の重要なお知らせがメインディスプレイに表示されない
#1023
uhokun - 2250@JPwZ200t0f2Z120fG/tuw/X20 Reply 2024/02/13 23:18
デュアルモニタでディスプレイ2をメインディスプレイにしているが、起動時の重要なお知らせ画面が必ずディスプレイ1側に表示される。
重要なお知らせ画面をメインディスプレイ側に移動後閉じて再起動しても再度ディスプレイ1側に表示されます。

添付画像左がディスプレイ1(サブ)、右が2(メイン)です。

Gakuto Matsumura - Developer Reply 02/14
ありがとうございます。

言われてみれば、たしかにその通りですね!

元よりメインモニター(プライマリ)かどうかではなく、モニターに由来する内容の先が特定されていない場合、必ず0番(0番は必ず存在するため)を固定して使用するという仕組みになっていました。

モニターの列挙と記録の内容を整理し、メインモニターのフラグを発見した場合はそのモニター。一切プライマリのフラグが通知されない場合を除き、OSにてメインモニターと指定されているモニターを標準的に利用する。という変更をしました。

以下にて確認して頂けると助かります。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240214-000441.zip

uhokun - 2250@JPwZ200t0f2XtP0Jg22tgX1/lZg Reply 02/14
早速のご対応ありがとうございます!

メインディスプレイに設定されている側に重要なお知らせ画面が表示されることが確認できました。

Gakuto Matsumura - Developer Reply 02/14
ありがとうございます。

ch0に、更新前のプレビュー版として、適用バージョンを出しておきました。

CLOSED : The added content will be notified to the administrator as usual.

update
Reply

[Closed] Issue GPUのファンが表示されない
#1016
キャシー - 2245@uPwZ22Pt/wPPlGP10XgZwmt1/flwlm Reply 2024/02/05 08:42
GPUのファン情報が表示されません。

Gakuto Matsumura - Developer Reply 02/05
報告ありがとうございます。

こちら、設定やOSのバージョン。GPUの種類は何であるか。そのライブラリやドライバの設置状態はどうなっているか。低負荷によりファンレス状態になっていないか。などが、どれに該当するのかの情報がまず必要です。

まずはレポートの「GPU情報」の中身のコピーと、"thilmera7.ini"をここに添付して下さい。

キャシー - 2245@uPwZ22Pt/wPPlG0fw0/2//0uuGJXP2 Reply 02/06
本日、PCを起動したら表示されました。
ファンレス状態のために非表示になったと予想します。
アップデート前までは表示されていたので、アップデートの影響と勘違いしてしまいました。
お騒がせしました。

Gakuto Matsumura - Developer Reply 02/06
状況がよくわからないですが、プログラム開始時に、セミファンレスにおける回転0を無効であるとは判断しないようにしているはずなのですが、何分、4つの大本のルート毎、かつそれぞれのOSやハードの新旧と、その中でも種類で別れるため、確認できていないルートがあるかもしれません。

とりあえず、恐らく効果はないであろう場所の条件を変えてはみました。
可能ならば、そもそもNVIDIAなのかRadeonなのかIntel HDなのかIntel Arcなのか、それだけでも教えていただけると幸いです。

キャシー - 2245@uPwZ22Pt/wPPlGJ1GXtuXw2JwJJmtm Reply 02/07
GPUはIntel Arcです。thilmera起動時にGPUのファンが回転していないと、thilmeraはGPUのファン項目を表示しません。thilmera起動後にGPUのファンが回転しても、thilmeraのGPUのファン項目は非表示のままです。
それから、レポートの「GPU情報」と"thilmera7.ini"を添付します。レポートの「GPU情報」は、ファン項目が表示されている場合とされていない場合の2種類を用意しました。なお、ファン項目がない「GPU情報」は、thilmera起動時、GPUのファンは回転していませんでしたが、レポート取得時には回転していました。

[appended] zip

Gakuto Matsumura - Developer Reply 02/07
具体的な内容ありがとうございます。

Intel Arcはまだ動作確認した環境は、希望者と後の私の2つ分のみ。となっています。

GPU情報を見た限り、今までにないパターン(表示されるものされないもの)になっているので、まずは以下にて、現行バージョンでログを出すモードのテストビルドを作成したので、こちらを実行して出力される、"debug_log.GPU.txt"を頂けると助かります。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240207-123355.zip

キャシー - 2245@uPwZ22Pt/wPPlGwuXf22Xw//ZmX//G Reply 02/07
テストビルドの実行準備はできましたが、GPUのファンはPC起動時以外、ほとんど停止しません。GPUファンの非表示を再現したときのログを送りたいので、しばらくお時間を頂きます。

キャシー - 2245@uPwZ22Pt/wPPlG00G2Z1uXG20g/fm Reply 02/09
"debug_log.GPU.txt"を送付いたします。なお、本日の状況は次のとおりです。
PC起動後の自動実行では、回転数「0RPM」が表示されました。
thilmeraを終了して、手動実行したら、今度は表示されませんでした。
もう一度、thilmeraを終了して、再実行したら、その間にファンの回転が始まり、thilmeraは回転数を表示しました。

[appended] zip

Gakuto Matsumura - Developer Reply 02/09
ありがとうございます。
ログを見る限り、項目のサポートフラグ(その項目のデータが存在するかの値)は、全期間を通して一律(そのハードウェアならば同一の結果)ではないのかもしれない、という前提で、初期化時の有効無効のログ出力の追加と、初期化時に有効ではない項目が後から有効とされている場合のログ出力と有効への切り替えを作ってみました。

以下でもう一度試してほしいです。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240209-155255.zip

キャシー - 2245@uPwZ22Pt/wPPlG0/0Zwmul2fGmG0ll Reply 02/10
新しいテストビルドのログを添付します。なお、本日の状況は次のとおりです。
PC起動後の自動実行では、回転数「0RPM」が表示されました。
thilmeraを終了して、手動実行したら、今度は表示されませんでした。
そのまま放置したところファンの回転が始まり、前回のビルドでは非表示のままでした回転数はが、今回のビルドでは表示されました。

[appended] zip

Gakuto Matsumura - Developer Reply 02/10
ありがとうございます。

こちらの問題、根本的な原因は、Intel Arc関連の公式ライブラリが、そもそも無いと返している所にありますね。

今回実用上のフォロー自体(ライブラリがあると返した時点から有効に改めてシフトする)はできたと思うので、ひとまずch0にて、この補正ありのバージョンに更新しました。

キャシー - 2245@uPwZ22Pt/wPPlGfw1GJlZuwZ/lP1m/ Reply 02/13
ご対応、ありがとうございました。

CLOSED : The added content will be notified to the administrator as usual.

update
Reply

*OpenClose
 + 
#
thilmera project - forum
Forum list
t7b - v14.0.1.0
Original - Board v3.4 Revision(http://revision.s22.xrea.com/)
© 2001-2024 Gakuto Matsumura:弦生ささと (thilmera7gmail.com) Privacy Policy