あれ？これつけたよね？
ほとんどサポート掲示板となっている自分のWebページの掲示板を見ていたら同期対象フォルダの参照ボタンがないぞという報告が来た。さすがにそれは間抜けな自分でもつけるだろうと思っていたらウインドウの大きさの関係で表示されていなかったというオチがついたのだが、前々からウインドウをリサイズするとボタンの位置関係がなんか微妙だったので直すことにした。
DockとかAnchorとか当てにならない
で、ボタンの位置関係はリサイズするごとに再配置しているのだがよく見る記事ではやれDockいじれ、Anchorを左右にと言うのがゴロゴロ出てくるのだが、TableLayoutPanel - GroupBox - FlowLayoutPanel 縦 - FlowLayoutPanel 横とくっつけているとどこで連結関係を見失うのかリサイズするとボタンは右に行くばかり。
結局Anchorは上と左だけ、Dockは知りませんで計算だけでリサイズすることでなんとかなった。
あと、問題になっていた右端の参照ボタンが見えなくなる問題はデザイン時の大きさより横のテキストボックスが小さくならないのでフォーム(ウインドウ)等のMinimumSizeを設定してこれ以上は小さくしないことで解決した。
この辺のレイアウトマネージャー、Javaでは20世紀から動いているのだが2005年の.NET Framework 2.0でついたにもかかわらずこのざま。何やってるんだよという感じである。
.NET Framework は2.0で今に続く形となった格好ではあるが、このレイアウトマネージャー関連とか、VB.NETの半端な先祖返りでさらなるVB.NETの複雑化を招いた事を考えると案外過大評価な部分もあるのかなと思った次第である。一方、この頃からC#は少しずつ小技が効く言語になり始めていたのだが。
タコなのはWindows Forms
しばらく前から高DPI対応に対するWindows Formsの対応のしょぼさとかWinUI3の配布の難しさとかを見てWPF版MulSyncを少しずつ作っているのだが、こっちでは変な計算をすることなくボタンがはみ出ないレイアウトを実現できている。
そう考えるとWindows Forms、高DPI対応といい、Javaのレイアウトマネージャーという手本が遙か前に出ているにもかかわらず計算が変とかということを考えるともう新規開発では使うべきではないと思うようになってきた。メンテナンス案件とシンプルなのを生かして使い捨て書き殴りないし、長く使わない物用というのが居場所なのかなと感じた次第である。
どこまで行くんだよ
ちなみに、MulSync、Mul(丸)にSだからとまんま都営新宿線アイコンにして、リリースごとに駅の順番のコードネームをつけているのだが(バージョンダイアログのバージョン番号の横をクリックすると表示されます)、作り出して12年前のバージョンで都営新宿線一往復を達成してしまった。2往復目というのもつまらないので都営新宿線実質笹塚が終点だろうということでついに京王新線に乱入してコードネーム初台を今回つけた。残り2駅。そのあとどうしよう。ベクターでは案外それなりの線いってるからやめるというのもないし(というかもとは自分で使う物だし)、さてさて。
