自前円グラフ、360～390度辺りの位置から630度の位置にStreamGeometryContext.ArcToする処理をMicrosoft Print to PDFに対して行うと期待通りの弧が描画されない問題を見つけてしまった。CubePDFだと問題なし。180度ずつに分割することで回避は出来そう。いやなんでそんなことしなくちゃいけないんだ。
29.09.2025 10:40
👍 1
🔁 0
💬 0
📌 0
自前円グラフ、360～390度辺りの位置から630度の位置にStreamGeometryContext.ArcToする処理をMicrosoft Print to PDFに対して行うと期待通りの弧が描画されない問題を見つけてしまった。CubePDFだと問題なし。180度ずつに分割することで回避は出来そう。いやなんでそんなことしなくちゃいけないんだ。
メモリかつかつの状態で使ってると、ふとした時に画面が固まってる問題が起きたので、結局自前で円グラフ描くはめになった。しんどかった。
PR-500KIが来た！勝った！ これでTX-ERROR List Create Errorに悩まされることはなくなるはず。
Pixel 6呪われすぎててつらい。Android 15まだ降ってきてなくてよかった。
WPFのDatePickerで月選択する処理を作っていたが、Stack Overflowでも解決できていない問題を解決した。ポップアップウィンドウ外をクリックしても閉じない問題を解決したぜ。
基本的にはDropDownButtonPreviewMouseUpと同じ感じで、DatePicker.csを解読して改良を加えた。2日くらいかかったので無料ではそれ以上は教えない。未来の俺が同じ問題に直面した時、「教えてくれ過去の俺ー！お金払うから！」ってなりそう。
stackoverflow.com/questions/17...
タイムアウトを30秒にしたらTX-ERROR List Create Errorは激減して快適になったが、今度はルータを再起動しないと繋がらないレベルになってきた。さすがにもう寿命だな。
.NET 9でジェネリック版のOrderedDictionaryが追加された模様。ようやくかよ…。
learn.microsoft.com/ja-jp/dotnet...
iniファイルをUTF-8化したくなって下記を参考に自作した。OrderedDictionaryは非ジェネリックのやつで頑張った。
qiita.com/yaju/items/4...
月額料金が少し上がるが、光クロスにすれば解決かと思いきや、XG-100NEしかなくて終わる。
いやさすがに10Gbps対応だし、NATテーブル増えてるやろ…。そうやろ…。頼むで…。
TX-ERROR List Create ErrorはNEC製のルータでよく起きるやつなのか…。HIかSEを引けていれば回避できていた可能性。
交換でNEC製が存在しないPR-500か600が来れば神。同じのが来たり400NEが来たら終わり。
とりあえずSPI設定でタイムアウトを300から100に減らした。
WinFormsのChartコントロール、UIスレッド以外でも生成できてびびる。他のコントロールも色々試してみたら、生成したスレッド内で使えるのか。
Chartコントロールをバックグラウンドで制御してDrawToBitmapでビットマップ化して印刷！
というのをWPFでそのうちやる予定。自前でグラフ描くの面倒だからね…。
こんなへんたいふしんしゃがどこにでもいたらやばすぎるｗ
誤解じゃなくて草。ごく普通のありふれた一般的などこにでもいる普通のろりこんを演じてるだけなのにおかしいなぁ。変だなぁ。
まるでXの俺はろりこんムーブばかりしてて真面目じゃないみたいじゃないか！ いやまあそうだが。
プログラムネタは文字数が長くなりがちなのでXよりブルスカの方が有利。
多重起動を抑制する時、いつもMutexでやってたけど、EventWaitHandleを使った方が既存プロセスをアクティブ化する時に簡単に内部から処理できるので楽だなと気付いた。
bbs.wankuma.com/index.cgi?mo...
Mutexでやったら、非表示状態のウィンドウを外部から表示させようとして詰んだ。Process.MainWindowHandleが0になる罠があったのでEnumWindowsを使ってハンドルを取得したが、正常に表示できなかった。SendMessageして内部から表示させるようにしないと多分だめ。そこまでするならEventWaitHandle使った方が楽。
Taskを直接触れるようにしようと思ったが、Taskをラップしたクラス作ってメソッド経由でTaskを触るようにした方がいいか。CancellationTokenSourceも一緒に管理したい。
Threadをラップしたクラスとあんまり変わらんな。スレッドプールを使うようになるのと、awaitで終了待ちできるようになるくらいか。
一時的な非同期処理だしTaskでやるかーと思ったらキャンセル処理で詰まり始めるやつ。async/awaitに対する理解も多分足りてない。
いや、最初の方は胸糞悪いアニメです。8歳の女の子が理不尽に村に殺されそうになって胸糞悪いです。
最弱テイマーはゴミ拾いの旅を始めました。、12話を観たあともう一度1話を観てしまう良いアニメだった。
ブルースカイ！
ImageコントロールとRenderTargetBitmapのサイズが同じになっていなかったのが原因だった。クソすぎるのは俺だった。
ScrollViewerでスクロールした時に線がぼやけることがあったけど、それもUseLayoutRounding=trueで解決。
俺はDataGridと同じ見た目の物をビットマップで作りたいだけなのに。
DrawingContext.DrawLineで1ピクセルの太さの直線を描くの難しすぎる。勝手にアンチエイリアスがかかって2ピクセルのぼやけた線になる。
0.5ずらしてもぼやけるところがある。WPFクソすぎる。
今期なろうアニメ多すぎわらた。異修羅以外は見てる。
yaraon-blog.com/archives/253...
ずっと別件やってて10営業日ぶりくらいに再開。
ImageのSourceにセットする前にRenderTargetBitmapをFreezeする必要があった。別スレッドで作ったリソースはFreezeしないと他のスレッドで使えない模様。そして一度Freezeすると書き換え不可能になって解除する方法はない。
安全だけど、毎回RenderTargetBitmapを作る必要があるのはメモリの使用量や断片化が気になる。.NETのGCがいい感じに片付けてくれるはずなので気にしなくていいとは思うが。
今期の面白いなろうアニメをほとんど押さえてて草。
DrawingVisualに描画コマンドを積んでいって、RenderTargetBitmapに描画、って感じでやればいけそうな気配。
learn.microsoft.com/ja-jp/dotnet...
あとはそれをUIスレッドでImageのSourceにセットするかOnRender時にDrawImageするか。
別スレッドでBitmapのGraphicsにゴリゴリ描いてUIスレッドでそのBitmapをPictureBoxに描画する、というのをWPFでやろうとしたらどうやったらいいのか分からなくて詰んだ。
Canvas？ OnRender？ DrawingContext？ WinFormsとWPF違いスギィ！
