エディタの方をまた作り直し中。C#の復習にもなるし。
前のはなんでもフォームで独立させるという感じになってしまい、
使ってるときにツールボタンを押したけどフォーカスがそのフォームに移ってただけで切り替わらないとかで、
結構イライラしたのでレイアウトを変えた。
タイルセレクタは使用するタブページのみ右に固定表示にしてみた。

今年中に仕上げたいなー(><)
NumericUpDownてマウスホイールでも数値を増減できるということを初めて知った。

> ツールボタンを押したけどフォーカスがそのフォームに移ってただけ

あるあるですねｗ

メニューやツールバーは「Controlではない」ということに（何故かわざわざ）なっているがために，
他の（ボタン等の）Control類とは色々と挙動が異なるってのが非常に使いづらいんですよね．

こいつら，「僕らControlじゃないんで，他のControlからフォーカスを奪わないんすよｗｗｗ」とかほざく．
そこでまたブチギレですよ．
「ControlのValidation系イベントで入力チェック書いても意味ない」という正気とは思えない仕組み．

>>メニューやツールバーは「Controlではない」
( ﾟДﾟ)なるほど
他のツールのイベントはフォーム間でスムーズに切り替わってる・・・その違いに気付いてませんでした(笑)
ツールストリップの反応の悪さはそういう仕様だからなんですね。

>>「ControlのValidation系イベントで入力チェック書いても意味ない」という正気とは思えない仕組み．
いつか使う日のために覚えておきます(｀･ω･´)
ツールストリップのテキストを扱うとなると、ブラウザのアドレス入力とかしか思いつけないですが(;^ω^)

> 「ControlのValidation系イベントで入力チェック書いても意味ない」

これはあれっすよ，
例えばフォーム内に，何らかの処理パラメタを指定するためのTextBoxがあって，
そこへの入力はパラメタの意味的に 1～4 に限定したいとかいう場合，
TextBoxのValidatingイベントでチェックして範囲外とかてきとーな文字列をつっぱねるコード書けば普通はそれで済む：
　Validatingに通らなければ，TextBoxから別のControlにフォーカス移動できないので
　「TextBoxに"800"とか入れた状態で処理開始ボタンを押す」みたいな操作を抑止できる．

問題は，Validatingイベントが発生するのが「TextBoxがフォーカスを失う直前」みたいなタイミングってこと．
ツールストリップボタンとかメニュー項目はValidatingを発生させずに余裕で押せちゃう．
（つまり，Validatingの仕組みでは，入力が不正な状態で処理ＧＯしちゃうことを防げない）

身近で例えるなら、C#のデザイナのプロパティの項目を移動するときにValidatingが起きてるということで良いんですかね。
それがツール、メニューだと機能しなくて不便と・・・( ..)φメモメモ