このファイルの名前を変更すると、'A_files' フォルダに属さなくなります。ファイルの名前を安全に変更するには、このファイルを開き、新しい名前で保存してから 'A_files' を削除します。このファイルの名前を変更しますか?」とメッセージが出る。このメッセージの目的はよくわからない。A_filesを削除するときに B.htmlと A.htmlの両方があれば A.htmlの方が一緒に削除されるし、A.htmlがリネームされて B.htmlになっていれば一緒に何も削除されないというそれだけのことだ。何が危険なのか。■A.htmlを A.htmに名前変更しようとしても同じメッセージが出るが、ファイルとディレクトリの関連が失われることはなかった(片方を削除すると両方がごみ箱に入った)。■A.htmlと A.htmというファイルが同時に存在するときに A_filesを削除すると、A.htmlと A.htmを加えた3つがごみ箱に入った。■A.htmlというファイルと A_filesというファイルのあいだには関連は生じないようだった。■すでに実験で明らかになってるけど、最初は Zone.Identifierと同じように代替ストリームに関連ファイル名が書き込まれてるのかもと思ったが、単純にファイル名の慣例に基づく判断だったみたい。エクスプローラーの判断か、エクスプローラーにアタッチされた外部プログラムの判断かはわからないけど。■悪しき自動化だと思う。数日前には動画に付けた匿名コメントが自分の Twitterアカウントにも流れていたということが話題になったし、さらに前には iPhoneで裸を自撮りした(ことのある)教師が部活動の様子を iPadで撮影させていたところ、女生徒がその画像を見るところとなり逮捕されるなどした。これが機械の裏切りでなくてなんだというのだ。機械というかソフトウェアか。プログラミングでできることならなんでもできますよ。でもお呼びじゃないんですよ。ただ、コントロールを明け渡してくれればそれでいい。
最終更新: 2017-10-03T19:34+0900
何も起こりません(起こったら困る)。見どころもありません。ただの日常です。
だいたい何を考えてるかというと、コーナーで向かいから視界を塞ぐような大型車が迫ってきたら怖いな、いきってセンターを割り込んだ車が突っ込んできたら怖いな、ハンドルを回すのを面倒くさがったドライバーがセンターを越えてきたら怖いな、そこが右コーナーで、ライダーの頭が対向車にぶつからないようにアウトにふくらんだときにタイヤが落ち葉や砂利を踏んだらこけそうで怖いな、そうならないために車体を立てても曲がれるだけの余裕をもったスピードで走れているだろうか、コーナーで一瞬先の目の前にエンコ(※初めて使ったけど通じるんだろうか)した車が現れても止まれる速さで走れているだろうか、そのとき後ろの車は反応できるだろうか、というようなことをずっと考えてる。
時にタイヤ1本分も余裕のない際際まで対向車を避けるのは、他人の責任で事故に遭うのが耐えられないから。壁際は安心できる。左右を挟まれた真ん中の車線なんて絶対に走らない。
車を運転するときは、(1)安全であると確認したエリア、(2)安全ではない(他者がいる)と確認したエリア、(3)どちらとも確認できていないエリア、の3つに視界を塗り分けるようにしてる。大事なのは3番で、ぼんやりしてると脳みそが勝手に未来図を外挿(※最近仕入れた単語。補間と対にして使いたい)してしまって、教習所が言うところのだろう運転になってしまうところを、意識してまだ確認できていないことを、岩が落ちていたり壁が建っていたり奈落が広がっていたりしても不思議ではないことを、絶えず確認する必要がある。
>net user 俺
によれば Event Log Readers/HelpLibraryUpdaters/Netmon Users/Performance Log Users/Performance Monitor Users/Remote Desktop Users/Users というローカルグループに属しているらしい。ローカルセキュリティポリシー>ユーザー権利の割り当てによれば名指しで システムパフォーマンスのプロファイル/メモリ内のページのロック/リモートコンピュータからの強制シャットダウンの3つが許可されている。その他にもシンボリックリンクの作成やらなにやらを Users に対して許可していたりする。何かの割り当てが引っかかったのだろうか。最近(つまり先月の Windows Updateに伴う再起動以後に)変更しただろうか。■とりあえず権利の割り当てと参加グループを変更してはログオフを繰り返して試行錯誤してたら UACに名前が出てこなくなった(最終的になんの権利も放棄していないのに!)。めでたしめでたし?For class and private DCs, GetDC leaves the previously assigned attributes unchanged. However, for common DCs, GetDC assigns default attributes to the DC each time it is retrieved. For example, the default font is System, which is a bitmap font. Because of this, the handle to a common DC returned by GetDC does not tell you what font, color, or brush was used when the window was drawn.」。ダイアログのウィンドウハンドルを使って得る DCが「
common DC」なのかって聞かれると自信がないけど。あるいはまだ一度も SelectFont(SelectObject)してなかっただけとか。■r3879はフォントに高さを聞いたがそれを知らない俺はリソースファイルがうまくやるやり方に従った。オーナードローコントロール以外はそれで文字が切れたりしてなかったから。カスタムDPIでもうまくやるかは知らない。■ちなみに MapDialogRect(※先のスクリーンショットに写しておきました)を使うのは3番目の(それで最後の)案で、その前には引数を4つ(left,top,right,bottom)も取らない GetDialogBaseUnitsを検討した。実際 MapDialogRectで使ってるのは bottomと topの2つだけだし、それが GetDialogBaseUnits関数は引数をひとつも取らないって言うんだから、これで間に合うならこれを使おうとするだろう。……でもひとつも? ダイアログのウィンドウハンドルもいらない? 実行コンテクストを参照してマジカルな方法で答えを返すとでも? 答えはここに>「GetDialogBaseUnits is a crock – The Old New Thing」 crockは「ナンセンス、でたらめ」という意味が何番目かに載ってる。■WM_MEASUREITEMに反応してオーナードローアイテムの高さを変える方法は邪道ではある(が、適切なデフォルトを設定しているだけだとポジティブに考えたい)。変更対象のファイルが個別のプロパティシートに対応したものではなく、基底クラスのもの(prop/CPropCommon.cpp, typeprop/CPropTypes.cpp)だということからそれが知れる。WM_MEASUREITEMは WM_INITDIALOGより前に呼ばれるから、基底クラスが派生クラスにディスパッチする仕組みが働かないんだよね(だから基底クラスのファイルに直に書いた)。これが同じ事情を説明してる>「OnMeasureItem will be called only if the control's class is created at run time, or it is created with the LBS_OWNERDRAWVARIABLE or CBS_OWNERDRAWVARIABLE style. If the control is created by the dialog editor, OnMeasureItem will not be called. This is because the WM_MEASUREITEM message is sent early in the creation process of the control. If you subclass by using DDX_Control, SubclassDlgItem, or SubclassWindow, the subclassing usually occurs after the creation process. Therefore, there is no way to handle the WM_MEASUREITEM message in the control's OnChildNotify function, which is the mechanism MFC uses to implement ON_WM_MEASUREITEM_REFLECT.」 邪道だろうがなんだろうが、ツールバータブの個別対応コードを削るだけでダイアログのフォントを正しく変更できたのだから嬉しい。「やってやったぜ!」■これはなんだろう>「Imp: ダイアログのフォント変更設定追加 · mocaskr/sakura@af39f17」 リソースからコンパイル済みのダイアログテンプレートを読み込んで、それからダイアログを作成するまでのあいだにフォント指定を書き換えるってこと? うへぇ、こんなんMS Pゴシックにも Meiryo UIにも満足できないこだわり派のユーザーも黙っちゃうよ。そうか、実行時に変更できるのか。■「履歴を読んでるだけで楽しい」とか書いていてもそれは楽しそうだ、というだけのことで、実際に読んではいなかったり。「列を指定してソート。たしか秀丸にあったことで知った機能」というのもそうだし、「ダイアログのフォントとしてMeiryo UIが指定可能」というのも、検索に引っかかって初めて気付くわけで、検索可能なオンラインのヘルプっていうのは広告塔なのだね。■ダイアログのフォント指定は言語設定と同じように特別な配慮が必要な設定だろうか。つまり、表示言語をうっかりクリンゴン語に変更してしまうとスタートレックを見たこともない自分は元の設定に戻すことさえできなくて設定画面の迷宮で途方に暮れてしまうわけだけど、ダイアログのフォント設定を間違えたり壊したりすると同じように元に戻せなくなりそうなので。※iniファイルを直接編集するという解決法は、可能であるというだけであって、利用者に求めていいことではない(俺だってやりたくない)。■実はフォント設定にからめてセキュリティフォントをからかってやろうとしたのだけど、自分の想像が及ぶ程度の素朴な仕組み(※salt付きの換字暗号)ではなかったのでやめた>「自称完璧なマイナンバー保護技術『セキュリティフォント』 その1 - Windows 2000 Blog」
absent operatorの挙動だが、(?~) は何にもマッチしないのが期待値なんだろうか?」■空パターンはすべての文字列に含まれている(※空文字列を含め何にでもマッチする)というのが普通なので、そういう文字列以外にマッチするパターン(※非包含オペレータが表すもの)は何にもマッチしないのだろうかってことだよね。文字の集合に対する
[]
(どの文字にもマッチしない)と [^]
(どの文字にもマッチする) とは反対なのが面白い。■文字集合を使った初心者のよくやる間違い [^ここに文字の集合ではなく列を書いてしまう]
や、お手軽だが不完全な代替 .*?
を使ったパターンに対して、正しく、簡単で、理論を逸脱しない答えが用意されるのが待ち遠しい。■日本語部分だけ読んだ>「正規表現における 非包含オペレータの提案」。■いや待てよ。非包含オペレータが扱う典型的なパターンはどういうものだろう。foo
だろうか .*foo.*
だろうか。俺は (?~)
について書いてるつもりで (?~.*)
について書いていたんだろうか。二つが同じだとすると部分一致ではなく完全一致であることを明示するために (?~^foo$)
みたいにアンカーを付けたくなるだろうから両者は区別されるんだろう。じゃあやっぱり勘違いしてた? s=uvw
みたいな文字で構成された式を「文字列がパターンを含む? どういうこと?」と読んで疑問のままにしてるんだけど、その辺を含めて PDFを読み直したい。