スキップしてメイン コンテンツに移動

投稿

bison/flex

Bison / Flexを導入してみる 開発環境 OSはWindows、IDEはVisual Studio (2022) で行います。 マイプログラミング言語が作れるようになるらしいです。使ってみたかっただけです。 Windows向けにポーティングされたWinFlexBisonを使う方法とWSL上でBison/Flexを動かす方法の2つを調べました。 WinFlexBison 公式サイト: https://github.com/lexxmark/winflexbison ライセンスはFlexがBSD, Bison GPLv3となっています。ただし、Bisonを使ったからと言って生成物にはGPLは波及しない(仕組み上、生成物にコピーが含まれるが特例扱いだった気がします)なので、その辺は大丈夫(なはず)です。 ページを見るとDownloadsリンクがあるので、そちらから安定板(win_flex_bison- version .zip)をダウンロードします。 プロジェクト作成 一連の流れについてはこちらのページが詳しいです。 設定だけでなく次のページ以降に実際の開発についても記述があるのでおすすめです。 FlexとBisonで計算機 概要としては メイン(開発する言語)のソリューションおよびプロジェクトを作成 FlexおよびBisonのファイルを配置するためのプロジェクトを作成 カスタムビルドルールを設定 といった感じです。 WSL2 + Bison / Flex WinFlexBisonはWindows上で動かすには最適でバイナリをプロジェクトに登録しておけばバージョンの問題とかも気にしなくて良くなるという利点があります。ただ、現在だとWSLでオリジナルのBison/Flexを動かせるのでそちらを使うという手もあります。 ・WSL(Ubuntu)をインストール     > wsl --install ・UbuntuにBison/Flexをインストール      いずれもパスワードの入力が必要。     > wsl sudo  apt-get update     > wsl sudo  apt-get install -y bison flex ...

KoeMill V.0.9.0.3 リリース

 KoeMillのV.0.9.0.3をリリース 主な変更内容 Largeモデルのダウンロード先を修正 モデルのダウンロードが低速だった問題を修正 ダウンロード先の修正 Largeモデルがダウンロードできなかったのを修正しました。 ダウンロード速度の改善 ダウンロード方法の変更とバッファサイズの見直しによりダウンロード速度が劇的に改善しました。 ダウンロードページ

KoeMill V.0.9.0.2 リリース

KoeMillのV.0.9.0.2をリリース 主な変更内容 バッチ処理(複数ファイルの文字起こし)を追加 文字起こし処理時の進捗ダイアログを追加 バッチ処理 複数のファイルを文字起こしするバッチ処理に対応しました。 コマンドバーのメニューから"Batch processing"で起動 ディレクトリを選択することでディレクトリ内のファイルが対象となる ファイルごとに文字起こしするかどうかを選択できる 文字起こし処理時の進捗ダイアログ 進捗状況を確認できるダイアログを追加しました。ダイアログ上から処理をキャンセルすることができるようになりました。 ダウンロードページ

Feetechシリアルサーボの資料整理

資料整理 Feetech公式に資料が揃っていれば良いし、そうあるべきなんだけど、そうでもないから情報をまとめておくよ。 公式サイト サポートページ にドキュメントが揃っていて欲しいけど、あるのはユーザガイド。連続回転(motor mode)など重要な記述はあるが、これだけじゃ足りない…。 ただ、ドキュメントについては整理してあり以下のことがわかる。 通信プロトコルのドキュメントがある サーボシリーズで異なるメモリテーブルのドキュメントがある (リンクを見かけた訳ではないので推測だけど公式じゃないかと思われる)SDKやデバッグソフトが配布してあるサイトは以下の通り SCServoSDK fddebug SDKとしてArduinoやLinux、C#など各環境に合わせたドライバが配布されているので比較的容易に動作させることができると思う。 資料としてはデバッグソフトに同梱する形でメモリテーブルが配布してあるので、デバッグソフトを使わない場合でもメモリ割付を確認したければダウンロードする必要がある。 Waveshare 公式配布では以下のことをネックに感じるかもしれない。 中国語がチョット… Protocol manual はどこ? もちろん、中国語に関してはDeepLに聞くなり、ChatGPTに聞くなりできるとは思う。ただ、Protocol manualは本当にどこにあるか分からない。ネットでもProtocol manual難民を見かけることがあるので、「ドキュメントは公式でまとめて配布してくれよ」と言いたい。 それでWaveshareの製品ページ、例えば SC09_Servo などに関連するドキュメントがまとめてある。ここで配布されているMemory tableは英語なのでキモチ分かりやすい(とはいえ、一次資料は中国語だと思うので参考資料になると思う)。 それと"Communication Protocol User Manual"は署名がないのではっきりしないが念願の"Protocol manual"だと思う。少なくともエンディアンの記述やプロトコルについては一致している。 Switch Science 全製品ではないけど比較が見やすくて良いなぁと思っています。 Feetechサーボ比較表 蛇足.ドライバ SDKで配布されている...

KoeMill V.0.9.0.1 リリース

KoeMillのV.0.9.0.1をリリース 主な変更内容 モデルデータダウンロード時のダイアログを追加 モデルデータのダウンロード先を修正 モデルデータのファイルが存在しないあるいは破損していた場合にクラッシュしていたのを修正 ダウンロードダイアログ モデルデータをダウンロードする際に進捗状況を確認できるダイアログを追加しました。合わせてダイアログ上から途中でダウンロードをキャンセルすることができるようになりました。 ダウンロードページ

KoeMill V.0.9.0.0でモデルデータのダウンロードに失敗する件について

ダウンロード時に401エラーが出る 原因 ダウンロードのリンク先が変わったのに対してKoeMillが対応できていない 対策(暫定) ウェブブラウザからモデルデータをダウンロードし、KoeMillフォルダに配置してください。 手順については以下のページを参考にしてください。 KoeMillで使用するモデルデータのダウンロード方法について

SimpleVoxのあとがき

本文はなくてもあとがき はじめに M5Stack(ESP32)向けに SimpleVox というライブラリを開発しました。折角の記念に実装に当たってのこぼれ話のようなものを書いておこうと思います。 SimpleVoxは音声認識、とりわけ孤立単語音声認識(Isolated word recognition)の機能を提供するライブラリです。本ライブラリはVAD(Voice Activity Detection)、音声からのMFCC(Mel-frequency cepstral coefficients)の計算、および2つのMFCC間の距離を計算するためのDTW(Dynamic Time Warping)などの基本的な機能を提供します。 実際のところ、より優れた方法やアルゴリズムは他にも存在しますが、M5Stack(ESP32)のようなリソース成約のあるデバイスでの音声処理ライブラリは充実しているとは言えず、本ライブラリは選択肢の一つになるかと思います。 参考までに以下に紹介のあるESP-SRでは学習済みのモデルを使って200以上のコマンドを識別できるそうです。 Unleashing the Power of OpenAI and ESP-BOX: A Guide to Fusing ChatGPT with Espressif SOCs 本ライブラリでは同様のことを実現するのは難しいですが、自分のためのいくつかのコマンドに対応することは比較的容易です。したがって、一方は精度良く規模の大きな識別が可能だがトレーニングコストが大きい、もう一方は精度はそこそこでいくつかの識別しか出来ないがトレーニングコストは少ないといったトレードオフの関係にあるかと思います。 VAD VADは音声が存在する区間を検出する技術で、音声区間を予め検出することで、ノイズの除去、リソースの節約などの利点があり、音声セグメントの境界を正確に検出することで、音声認識の精度を向上させることに繋がります。 シンプルな実装としては信号のパワーとZero-crossingを用いた手法があり、元々ライブラリでも同様の手法を採用していたのですが、Espressifが公開していたESP-SRのVADがなかなか良かったことがあり、置き換えた経緯があります。 とはいえ、シンプルな実装もまるでダメってわけではなくて、意外と...

DataGridの高さが自動では縮小しない

WinUI3のDataGrid(CommunityToolkit)の話 現象 セル中のTextBoxでAcceptReturnsなどを設定し複数行に対応出来る状態にする。その状態で複数行入力するとセルの高さが自動で拡大していく。ここまでは直感的な動作。 一方でその文字列を削除していっても セルの高さは自動で縮小したりはしない 。 直感的にはTextBox中の行が減るとTextBoxの表示域も減ると思うが、そうはなっていない。WPFやFormsはおそらく自動で縮小したと思うのでCommunityToolkitの実装上のチョンボだと思う。 検討 デバッガでセル中のTextBoxなどUI要素のサイズを確認してもAuto(double.NaN)のまま。したがって、セルの要素が広げているわけではなくてDataGridのRow側が広がったままになっているっぽい。 ただそうなるとDataGridの特定行のサイズは果たして変更できるのか、出来たとしてどうやって? ChatGPTに聞いた答えを動作するように修正したのが以下のアイデア。実際にはItemsSourceがリセットされる兼ね合いで選択セルが飛ぶので違和感が大きい。 private static void ResetRowHeight(this DataGrid grid) { var itemsSource = grid.ItemsSource; grid.ItemsSource = null; grid.ItemsSource = itemsSource; } ただ、考え方としては参考になるところがあって、要はDataGridに表示域の再計算を迫れば良い。 対策 発掘されたのが以下の投稿。 DataGrid Row Auto-Resize only grows row height but won't shrink (microsoft.com) 2008年のSilverliteの話らしいけど、Microsoft.Toolkit.Uwp.UI.Controls.DataGridでも有効な対策だった。まぁ、若干ちらつくところはありますが…、及第点でしょう。 private static void ResetRowHeight(this DataGrid grid) {...

KoeMill V.0.9.0.0 リリース

KoeMillのV.0.9.0.0をリリース KoeMillは、音声認識による文字起こしを行うソフトウェアです。音声認識モデルにはWhisperが採用されており動画や音声から自動的に高品質な文字起こしができるため、煩雑な手作業を省くことができます。 オフラインで動作するため、ネットワークの遅延などによる遅れやプライバシーに関する懸念もありません。また、GPUを利用することで高速な処理を実現します。 ダウンロードページ

OCRの行の間から見る段落検出について その4

補足 他のやり方 一応、他に思いつくOCRの情報を使った方法として フォントサイズを基に段落を検出 インデントおよび折り返し位置を基に段落を検出 フォントサイズは見出し等がフォントサイズが大きくなりがちなので、それは段落としてみなせるでしょうみたいなアイデア。段落ごとにフォントサイズが異なる場合も生きる気がする。 インデントと折り返し位置は、段落の先頭はインデントが挿入されるし、段落の末尾は右端まで行かずに折り返されるのでそられの情報から段落境界をを検出するアイデア。 行間の使い道 行間が極端に狭い場合は段落とみなしてよいと私は考えています。 感覚的にある程度行間が狭いと「さすがにこれは同一段落だろう」と思うようなところはあると思っていて、0だとかマイナスってのはそのさすがにに相当すると考えています。具体的にどのくらいまでとか考えるとややこしくなるとは思いますが…。 以下のページに画像の膨張処理で段落を検出する話があるんですが、感覚的には似たような話かなぁと思ってます。 How to detect paragraphs in a text document image for a non-consistent text structure in Python OpenCV 複数のスタイルに対応できたとして 下図みたいな文章があった場合、複数のスタイルに対応できれば 1. Aaq... 2. Aaq... 3. Aaq... ごとに段落境界を検出する。 ただ、これが箇条書きであれば不完全な識別だと言えるし、それぞれに境界が欲しくなる。 とは言え、それは本質的には文章から箇条書きを抜き出すような別タスクで、空間的な距離だけをもとに識別する方法の外の話になるだろう。 ぬるっぽさんちのPCOT PCOT の実装は掲示板を見るとそれとなく書いてあるので探してみると良いです。しきい値との兼ね合いが分からないんですが、どうやら行送りの最頻値もしくは最小値を使っているみたいです。 最小値?ってなるかも知れませんが使ってみると良い感じなんですよね。 基本的に文章段落は単一のスタイルに統一されている 箇条書きは文章より行間が広いことが多い って感じで結果的に文章の行送りが最小値になってることがままあるので、文章は同一段落になって箇条書きは分離みたいなことがありました。実践的な感じがしま...

OCRの行の間から見る段落検出について その3

隣り合う情報を使った手法 複数のスタイルに対応できないか 前回述べた方法は段落はすべて共通のスタイルであることを仮定している。しかしながら複数のスタイルが混在する場合が存在しないわけではないのでどうにか対応出来ないか…。 前回確認したデータからは以下のことがわかる。 段落境界で値の変動がある 同一段落内で"行送り"はほぼ変わらない 同一段落内で値がほぼ変わらないのは同一スタイルであるためである。したがって、複数スタイルが存在する場合にあっても同一段落内で値が変わらなければ、その変動から段落境界は見つけ出せそうという感触はある。 必須行数のはなし はい、OK。じゃあ、上から順に走査していって変動があったところを段落境界とすればいいね。 となれば良いがやってみると意外な形で失敗する。 段落境界の前後で行送りがほぼ等しいなど、段落境界をまたぐところで誤判定が生じることがある。 それというのも段落境界を行の空間的距離から推測するにあたって少なくとも3行は必要となる。1個だけだとそれが大きめの行送りかあるいは段落境界なのか比較できる対象がなく判定ができないためである。 順に捜査していく場合、基準となる行はもっともらしいものである必要があるのだが、段落境界毎にそれはリセットされる必要があり、どうにかしてもっともらしい基準を見つける方法が必要になる。 どうやって基準を見つけるか 対象をデータテキストに限った方法ではあるが、隣接行の行送りの値が近い場合にそれを基準とするというアイデアがある。要するに段落境界付近の値は使用せずに段落の中心から先頭・末尾に向かって走査していくような方法である。 ただし、依然として段落境界でもっともらしい基準として誤って採用されることがあるという問題は残っている。 どう実現するか 色々やってみてそれらしく動いたのは以下のような手順である。 もっともらしい基準値を見つける もっともらしい基準から段落境界に出くわすまで下に走査する もっともらしい基準から段落境界に出くわすまで上に走査する 統計量を基準値として段落検出する そう、最終的に統計量を使ってしまっているのである。全くもって遺憾。 それというのももっともらしい基準値を見つけられない場合などもあるため、最終的には何か理由をつけて判定する必要があるのである。 また、2と3の走査ではそれ...

OCRの行の間から見る段落検出について その2

統計量に基づく手法 行送りと行間 行送りと行間の定義については前回の通りとし、実際にどちらを基準とするか。 人間が目視で判断する場合、行と行の距離を追っていると言うよりは行と行の隙間(空白)の大きさを元に判断しているように思われる。したがって、直感的には"行間"が基準に適しているように思うが…。 以下はいずれもとあるゲーム画面の文章について"文字の高さ"、"行間"、"行送り"を記したもので、実際に段落の境界が存在する行を青くハイライトしている。 一見すると"行間"にしても"行送り"にしても段落境界で前後と値が大きく離れており、前後との差から十分に段落境界を判断できるように見える。一方でPCOT界隈では行間狭すぎ問題なる問題があるように行間は0はおろかマイナスの値すら取り得る。そのため、比率のようなものでしきい値を設定する場合には注意が必要である。 また、上の図では"行間"が0, 1, 4 | 9, 12, 18となっており、9以上は段落境界である。しかしながら、0と1が多い中での4は一見すると段落境界のようにも思える。実際には、たまたまディセンダがない行の影響を受けて結果的に4と"行間"が広くなっているだけであり、段落境界ではない。一方でこの影響は"行送り"には大きく出ていない点に着目する必要がある。理由は行送りはToptoTopで求めているためディセンダの影響を受けないためである。もちろんアセンダがない場合は行送りであっても影響を受けることになるが、行間に比べて行送りは値が大きいためその影響度合いは相対的に下がる。つまるところ、"行間"、"行送り"ともに基準となるポテンシャルはあるが"行間"はアセンダ・ディセンダの影響を受けやすく、また非常に小さな値(あるいは負)となる場合があるため"行送り"の方が扱いやすいと言えそうだ。 統計量 統計量と書くとなにやら大仰であるが、ここで取り扱うのは平均値、中央値、最頻値のことである。単にそれらの値をもとにしきい値を設定しそれ以上の値であれば段落境界が存在すると判断する。 ...

OCRの行の間から見る段落検出について その1

タスクと用語の整理 OCRを使って読み出した英文テキストについて、段落を検出する方法について検討します。同タスクを実現する方法はいくつか考えられますが、ここでは文字列間の空間的な距離を元に検出する方法について取り扱います。また、レイアウトはシンプルに縦方向にのみ存在するものとします(2段組などは考えない)。 まず用語の整理を行います。 空間的な距離 文字列における各行間の距離について行送りと行間が挙げられる。Wordだと行間は上記の行送りに相当するし、それぞれを逆に定義しているものも存在する。 ここでは 行送りと行間・文字送りと字間・文字サイズについて解説 などいくつかのサイトを参考にし、行と行の距離を行送り、行の隙間(上側の行の下部から下側の行の上部まで)を行間とする。 タイポグラフィ的な用語の整理 ベースライン(baseline):文字の下部に沿って引かれた仮想的な線 ミーンライン(mean line):x-height("xの高さ")の上部に沿って引かれた仮想的な線 アセンダ(ascender):文字におけるミーンラインより上側の部分 ディセンダ(descendr):文字におけるベースラインより下側の部分 ここで理想的な行送りと行間は以下で求められる。 行送り = ベースラインからベースラインまでの距離  行間 = 上側の行の最下端(ディセンダの部分)から下側の行の最上端(アセンダの部分)までの距離 OCRで取得可能な値 OCRでは認識した文字の矩形領域が取得できる。したがって、同一行のすべての文字の領域が持つ座標値の最小値、最大値から行全体の矩形領域が算出できる。 n行目の最上端をTop_n、最下端をBottom_nとしたとき、行送りと行間は以下のように算出する。 行送り ≒ |Top_n+1 - Top_n| 行間 ≒ |Top_n+1 - Bottom_n| 注意点は行送りにしても行間にしてもテキスト内容によって影響を受けること、行送りはベースラインが取得できないためTopで代替していること。 理想的にはベースラインを基に行送りを算出する必要があるが、OCRではベースラインは取得できないため算出可能なTopもしくはBottomを使う必要がある。一方で同一フォントサイズであってもアセンダ・ディセンダの有無によってTopおよびBottom...

CapCap V.0.9.2.7 リリース

CapCapのV.0.9.2.7をリリース 主な変更内容 HTTP POST設定でヘッダの設定に対応 HTTP POST設定でJSONのオブジェクトおよび配列に対応 HTTP POST設定を大項目ごとに折りたためる機能に対応 サンプルプリセット(ChatGPT API)を追加 プリセット複製時に複製先の変更が複製元に及んでいた不具合を修正 HTTP POST設定 新たにリクエストヘッダを設定できるようになりました。これによりAuthorizationによる認証などヘッダが必要なAPIにも対応できるようになりました。合わせて、これまで設定することが出来なかったJSON ObjectおよびArrayについても設定できるようになりました。 ChatGPT APIについて サンプルプリセットを追加しました。HTTP POSTのヘッダおよびJSON ArrayとObjectに対応したため、その対応例となります。 継続的に使おうとすると費用が発生することになるので、無料枠が残っている間に遊んでもらえると幸いです。 DLページ: Home

CapCap V.0.9.2.6 リリース

CapCapのV.0.9.2.6をリリース 主な変更内容 DPIスケーリングが100%以外の場合にキャプチャや字幕表示がうまくいかない不具合を修正 プリセット設定を大項目ごとに折りたためる機能に対応 フィルタ設定におけるイメージビューアの拡大・縮小表示に対応 DPIスケーリング 昨今の高解像度ディスプレイに合わせてシステムでスケーリングしている場合、キャプチャや字幕の表示がうまく行えていませんでした。 今回の修正でスケーリングが100%でない場合でも正しくキャプチャおよび字幕の表示が行えるようになりました。 設定項目の折りたたみ 項目横の(∨)または(∧)ボタンで項目の展開・折りたたみが出来るようになりました。 イメージビューアの拡大・縮小表示 マウススクロールでビューア上の表示を拡大・縮小できるようになりました。 ビューア上でドラッグすると拡大画像の表示を移動できます。 DLページ: Home

CapCap V0.9.2.5 リリース

CapCapのV0.9.2.5をリリース 主な変更内容 段落検出機能を追加 字幕モードの名称を変更(Readability -> Text, Layout -> Item) 段落検出 テキストの行同士の距離をもとに段落を検出することが出来るようになりました。 段落の検出および段落間への空行挿入が行なえます。 これまではテキストをひと繋がりの文章として認識していましたが、段落ごとに分離されることで可読性の向上が見込めます。 文章に対して段落が多い場合や段落が2行からなる場合などには精度が落ちる傾向にあります。また実験的機能の側面があるため問題点等あればご報告いただけると助かります。 DLページ: Home

CapCap V0.9.2.4 リリース

CapCapのV0.9.2.4をリリース 主な変更内容 サンプルプリセット(Google Apps Script, DeepL API)に対応 プリセット複製機能に対応 表示文字列がない場合字幕を透過するように変更 Clipboardモードのタイムアウトを変更 設定読み直し時のRepeatモードに関する不具合を修正 プリセット設定 プリセットを複製することが出来るようになりました。作成済みのプリセットを流用出来るため、これまでよりプリセットの作成が容易になります。 サンプルプリセットを表示可能になりました。上記プリセットの複製と組み合わせて使用することでマニュアルに記載の設定例について設定の手順が以前より大幅に簡略化されます。 表示文字列がない場合に字幕を透過 従来は表示文字列がない場合でも字幕の背景を表示していましたが、文字列がない場合は背景を透過するように変更しました。 透過中は字幕範囲にマウスオーバーすることで枠線がハイライト表示され、表示中と同じように字幕を操作することが出来ます。 従来は以下の通り、表示文字列がない場合も背景が表示されていました。 DLページ: Home

CapCap V0.9.2.3 リリース

CapCapのV0.9.2.3をリリース Home 主な変更内容 - バックログ対応 - 表示テキストの原文・訳文切り替えに対応 - 字幕のキャプチャモード切り替えに対応 - 字幕非表示機能に対応 - コピー機能を整理 概略 今回のアップデートはユーザビリティの向上がメインです。 直近の読み出し結果を確認できるバックログ機能や原文を確認するための表示切替機能、キー及びマウス操作の追加など細かいけれど出来ることが増えました。 例えば、字幕非表示はムービー中など自動更新してほしくない、あるいは表示してほしくない場面で役立つかと思います。

CapCap V0.9.2.1 リリース

  CapCapのV0.9.2.1をリリース Home 主な変更内容 - Clipboardモード(TexTra Clipboard連携)に対応 - ヘルプ表示に対応 Clipboardモード(TexTra Clipboard連携) トランスレータのモードを Clipboard に設定することでTexTra Clipboardと連携できるようになりました。 「TexTra Clipboard」はクリップボードにコピーしたテキストを翻訳をするアプリケーションです。「みんなの自動翻訳@TexTra」を利用して翻訳を行っており、国立研究開発法人情報通信研究機構(NICT)で開発されています。 高精度な自動翻訳が行えます。是非とも活用してください。 懸念としてはクリップボードを介して連携を行う都合上、複数の字幕で同時に翻訳を行うと翻訳に時間がかかる、場合によってはタイムアウトするといったことが考えられます。 ヘルプ表示 メニューからヘルプを選択するとヘルプファイルが表示されるようになりました。 従来からファイル自体は存在したのでブラウザで確認できましたが、ソフトウェアからも表示できるようになりました。

ウィンドウの非表示を知りたい

瞬間的にウィンドウを非表示化したい 個人的な結論 非表示にこだわらない、アクティブウィンドウが変わってもよい WindowStateを使ったウィンドウの最小化で対応 絶対非表示、アクティブウィンドウ変わってほしくない Visibilityを使った非表示化とマジックナンバー的wait --- どうすればウィンドウを非表示できるか 少し調べるとVisibilityプロパティをHiddenやCollapsedにすれば非表示出来ることは行き着くのだが、本当に非表示になったことを確認する方法が出てこない。 IsVisibleプロパティがそれっぽい。具体的には以下の記述がそれっぽい。 IsVisible true if the element is visible; otherwise, false. Visibility Setting this property affects the value of IsVisible, which in turn may raise the IsVisibleChanged event.  IsVisibleがそれっぽいと言ったな、あれは嘘だ 説明だけみるとそうに間違いないのだが、UIが絡むからかそんなことはない。 例えば、スクリーンキャプチャする瞬間だけ非表示みたいな処理をしたい場合、CopyFromScreenの実行をIsVisibleChangedが発生するまで実行を遅延すれば良いように思える。 Visibility = Visibility.Collpsed; …// ここでIsVisibleChangedの発生を待つ graphics.CopyFromScreen(…); … Visibility = Visibility.Visible; ところがどっこいやってみるとウィンドウは非表示になっておらず、ばっちりキャプチャされてしまう。デバッグモードで止めて確認して何度がっかりしたことか。 問題設定的には以下と同じである https://stackoverflow.com/questions/39068778/wpf-how-to-run-code-immediately-after-a-window-is-hidden 見えなきゃ良いんでしょ じゃあ無理じゃんとなるんだけど、一応方法がないわけではない。非表示は...