| 名前 | バージョン | 概容 |
|---|---|---|
| ソース | ||
| class_library | ソース用DLL格納フォルダ | |
| Shirase | ソースフォルダ | |
| アプリケーション | ||
| ASF_WPF.dll | Ver.1.0.0.0 | 補助クラスライブラリ |
| Kotozuke.deps.json | ||
| Kotozuke.dll | Ver.1.1.3.2 | |
| Kotozuke.exe | Ver.1.1.3.2 | 用件作成 実行ファイル |
| Kotozuke.runtimeconfig.json | ||
| Paper.dll | Ver.1.1.4.0 | 報勢家のクラスライブラリ |
| Shirase.deps.json | ||
| Shirase.dll | Ver.2.0.4.0 | |
| Shirase.dll.config | アプリケーション構成ファイル | |
| Shirase.exe | Ver.2.0.4.0 | 本体 実行ファイル |
| Shirase.runtimeconfig.json | ||
| ドキュメント | ||
| readme.txt | 説明文（本文） | |
日頃の繰り返される用事、突発的に割り込む用事、そんな忘れがちな作業を用件として登録し、PC起動時にその日の用件を告知してもらう、簡単リマインダです。
予め使用環境に、.NET Runtime 8.0.xを導入しておいてください。
ダウンロードした圧縮ファイルを適当な場所に解凍し、"Shirase.exe"を実行してください。『報勢家 の 侑利 と 満代』が起動します。
起動したら、ハンバーガーメニューを開いてをクリックすることをお勧めします。スタートアップにショートカットが登録され、OS起動と共に告知日に達している用件を一覧してくれます。
まず、ハンバーガーメニューのに、チェックが付いていたらクリックしてください。スタートアップからショートカットが削除されます。
『報勢家 の 侑利 と 満代』を終了し、インストールしたフォルダごと削除してください。これで、跡形なく綺麗サッパリ消え去ります。
『報勢家 の 侑利 と 満代』("Shirase.exe")を起動します。
起動すると、登録されている用件が一覧表示されます。
新しい用件を作成したいなら、ボタンをクリックします。
用件の内容を変更/削除したい場合は、各用件にあるボタンまたはボタンをクリックしてください。
ボタンまたはボタンをクリックすると『報勢家の言付け』が開きます。
各項目を設定します。
色は、お好みで選びます。
説明欄には、概要を説明する文章を記入します。URLまたはローカルファイルのパスもリンクとして設置できます。
用事欄には、「やらなければならない作業内容」を列記します。
行程計画欄では、起算日や繰り返しの方法を指定します。
ボタンまたはボタンで保存します。この時、行程計画を基に次回告知日が算定されます。
既存の用件を複製したいなら、用件一覧から目的の用件のボタンをクリックして、ボタンで保存してください。
各用件には用事が一覧されます。済んだ用事にチェックを付けていき、完遂すると次回の告知日が表示されます。チェックは、いつでも付け外しできます。
進捗状況の保存や次回告知への更新は、『報勢家 の 侑利 と 満代』の終了時に行われます。
年や月単位で日付計算を行った結果、月の日数が短く実在しない日にちになってしまう場合は、その月の最終日に前倒しされます。
例えば「起算日を1月31日として1ヵ月毎（起算日更新）」の場合、次を2月31日とできないので28日（閏年なら29日）、以降3月31日→4月30日→5月31日…と遷移します。
配布物にはソースも同梱しています。自由に改造してください。
ソースフォルダには、".vs", "bin", "obj"フォルダを含めていません。Visual Studioでソリューション(*.sln)を開いたら、とりあえずソリューションをリビルドしてください。デザイナが使えるようになります。
コードエディタにおいてWindow（Windowに配置されたコントロール含む）への参照箇所にエラーが出る場合があります。エラーのままでもビルドは通りますが、コードエディタの機能が著しく低下し不便です。
そんな時は、ソリューションの".vs"と各プロジェクトの"obj", "bin"フォルダを削除して、再度ソリューションのリビルドを行ってみてください。
特定のプロジェクトでのみの発症なら、当該プロジェクトの"obj", "bin"フォルダを削除して、プロジェクトのリビルドを試してください。
この病は大変しつこく、1回では治まらないかもしれません。治まるまで何度も繰り返してください。ただし、一旦落ち着いたとしても突発します。現状では完治は望めません。と言うのも、この対処法は作者の経験に基づくものなので、頓珍漢なことを書いているかもしれません。あしからず。（なんだかVSのバージョンアップを経る毎に悪化しているような気が…あれ？ Ver.17.10になって気づいたのだが、プロジェクトのプロパティとデザイナとコードを開いたら治るな？？ というか、この3つを揃えないとエラーになる？？？）
データ保存用フォルダが、インストールフォルダ下に作成されます。
"binder"フォルダは、初回起動時に作成され、登録した用件が保存されます。
"resume"フォルダは、初回終了時に作成され、終了時のウィンドウ配置が保存されます。ファイルを削除すれば、初期化できます。
スタートアップ フォルダに登録されたシュートカットは、手作業で削除しても構いません。
レジストリは使用していません。
日々は繰り返し。キッチリとした期限は無い、だからと言って放置もできない。そんな用事の繰り返しが日常と言うもの。何気ない繰り返し、何気ないから忘れてしまう。
そう、作者の生活は時・分・秒など争わない。時間に追われないからこそ時間に迫られる。故に、何度も何度も、用事が済むまで、リマインドして欲しいのだ。
それなのに、そんなユル～くて厳格なスケジューラ・リマインダが見当たらない。見回せば標準アプリ『カレンダー』や『Microsoft To Do』が手招いている。されど、彼らは作者の要求を満たしてはくれない（アプリが不能か、作者が無能か）。
「日常のルーチンをポカする奴など居やしない」「時刻指定無しに何時リマインドするのか」そう言いたいのだろうか？ 確かに、PCの電源を切る習慣が無い人には、本作など箪笥の肥やしにしかならないだろう。だが、作者は電源を切る人なのだ。
本作には、前身となるアプリ『お知らせ君』が存在する（後継と言えど互換性は一切ありません）。制作は VB2005 で .NET Framework 2.0 の WinForms …見るからに古びている（WPFも新しくないが）。動線設計も不味い。いい加減作り直したい。
当初案では、ジャンプリストやアクション通知を活用して、画面を占有するウィンドウからの脱却を図っていた。アクション通知の管轄はWinRT APIらしく、手に余りそうで早々にお流れに（まぁ、OS起動時に通知がポンポン噴き出すのも考え物か）。
今作でも先代を踏襲して文字装飾するつもりでいた。ところが、WPFはフォントや色のコモンダイアログを提供してくれない。無いものはしょうがない、手前で整備する。文字装飾はリッチテキストで実現する。肝心のコントロールは、WinFormsと同名のRichTextBoxがWPFにも存在している。名前が同じなら当然の如く同等品だ・・・と思っていた。いざ触って知る事実、全くの別物であると。慌てて対応策を思案するも、すればするほど文字を飾り立てる意義自体を見失い、機能は整理され、自前ダイアログ達も御祓箱に。（路頭に迷う哀れな自前ダイアログ達を拾ってくれたのが、拙作『穴黒』だったわけだ。努力の結晶なだけに活きる場ができて報われた。）
自作アプリの焼き直しと言えば軽作業に聞こえるが、幾年も幾度も迷走する破目に陥るとは。紆余曲折を経てウィンドウを持ったUIに落ち着いたが、アプリ構成の刷新も相まって、簡素に、淡白に、素直に、生まれ変われせられた気がする。
事が起きるのはいつも突然である。マイクロソフトのVB開発終息宣言やVB関連ドキュメント消失（後に回復、単に引っ越し途中だった模様）、VB(WPF)チュートリアル系サイトの閉鎖やVB伝道師によるC#講座開講。
VB愛好家の心臓をキュッとさせる変事が重なる。危機感を覚える作者。脳裏を過る「乗り換え」の文字。
C言語との別れは約30年前。MSX-BASICとの恋路を驀進する作者にとって、C言語は「面白みの無い奴」でしかなく敬遠してきた。C#はそんなC系言語の眷属、すんなり歩み寄れるはずもなく…（VBやっているとC#サンプルのつきまといは不可避だが）。
以下は、言語野が素寒貧な作者の個人的感想（戯言）である。「文法に一貫性が無い」「過度に記号的かつ暗号的で読み難く書き難い」のは相変わらずで、入り乱れる括弧“{～}”括弧“(～)”括弧“[～]”とか、ブロックが“{{}{{}}}”で終始の対応が不明瞭とか、“==”とか“&&”とか“||”とか、行の終わりに“;”が必要とか、True≠-1のせいか論理否定とビット反転が分裂しているとか、同じ目的に複数の文法が存在する（プロパティ定義やSwitch文で戸惑う）とか、アレとかコレとかソレとか、、、極まるC#の混迷ぶりを再認識した。翻って、様式を崩すことなく新要素を受け入れているVBの度量の広さ自然体さ素性の良さに感心してしまった。界面は密着すれど混じり合わない、作者とC#はさながら水と油だ。（こんなだからVBを一方的に罵倒するC#信者とは交われません。向こうもお断りでしょうが。───古来からのGOTO悪玉論も腑に落ちひん。マシン語かってJUMP命令あるやんか。ある地点からある地点へ飛ぶのは、原理的に不可欠なんちゃうの？ だからCには関数があって、breakとかreturnがあるんとちゃうの？ そもそもCにもC#にもgotoあるし…。）
そんなC#…だけど、時代は変わった。
VSのコード補完機能が心強い。書いているコードの先を提案してくれるし、アカヌケないプロセスもシュシュっと書き換えてくれる。ヘボなif文やSwitch文、アホな比較式を書こうともシャシャっだ（VBより実装が進んでいて羨ましい）。
Copilotもまた心丈夫だ。とりあえず聞けば、何かしら答えてくれる、コード付きで。覚えられない書式指定文字列や正規表現もズバリだ。まるで夢のよう（道具であり続けてくれるなら）。そんなAIをもってしても、ネット上の情報が過疎なWPF版RichTextBoxには無力だったが。それでも、検索結果が精錬されること、ネタ元を辿れることはとても意味深い。
逆に捉えれば「C#とは、ロクなコードを書けない言語である」証左とも言える。（いや、作者がショボいだけさ、あぁVBに未来を…どうせなら、いっそのこと、.NETがPythonに乗り換えてくれたらサッパリする？）
奔走のダイアログ整備、当惑のアクションセンター、模索のWPF版RichTextBox、渋々のC#、未練のVB、今回の制作は四方八方に遠回りを強いられた。そのおかげか仕様の贅肉は落ち、加えて開発環境の充実した支援、さらにはAIの助言、おまけに有志によるC#初級講座まで享受できてた。C#との新たな船出には、世紀の好機に恵まれたのかもしれない。
毎度、お世話になっております。大変有難く存じます。