返信

> > Kuroさんも同じうっかりをしていましたか。 > > 私の場合、Mery の開発やデバッグ中に [ツール] > [オプション] を開く機会が多いので、つい隣の項目を誤ってクリックしてしまうことがありますね。 > > とはいえ、これはトラックボール マウスを導入したことや、練習のためポインタの移動速度を自分の限界より少し速めに設定している影響もあると思うので、慣れてくれば自然と解消されていくのではないかと感じています😅 > > > ただ、私みたいに [常に最上位] 機能を使用しないユーザーにとっては、 [常に最上位] 機能が [ウィンドウ] メニューの一番上というアクセスしやすい位置にあるのはどうなのかという気はしますが。 > > お気持ちはわかります。ご要望が多ければ、位置の見直しも検討してみたいと思います。 > > ただ、[常に最上位] を下に移動させると、今度は [上下に分割] が一番上に来てしまいますよね。 > > そうなると、誤クリックによる影響は、[常に最上位] よりも大きくなる可能性があります。 > > たとえば、上下に分割して作業している最中に誤って [上下に分割] をクリックすると、分割が解除されてしまいます。 > > その場合、分割されたウィンドウ内の選択範囲もすべて解除されてしまうため、編集作業への影響は [常に最上位] の誤クリックよりも大きくなることが考えられます。 > > なので、なぜ [常に最上位] を誤クリックしてしまうのか、また、[常に最上位] のみを誤クリックしてしまうのなら、なぜ、他のカテゴリの一番上のメニューは誤クリックが発生しないのか、根本的な原因を探ってみるのもよいかもしれませんね。 > > もちろん、理想を言えば、メニューがカスタマイズできるようになるのが一番ですが… > > 残念ながら、Mery の開発に使用している Delphi では、メニューを動的に生成する際のパフォーマンスがあまり良くありません。 > > そのため、アプリの起動時にメニューを動的に構築するような仕組みを導入すると、起動速度の低下に直結してしまいます。 > > もともと「Mery は起動が遅い」と言われることもあり、これ以上の遅延は避けたいという事情から、カスタマイズ可能なメニューの実装は現状では難しい状況です。 > > ということで、もし [常に最上位] を普段お使いでない場合は、こんなマクロはいかがでしょうか？ > > ``` > if ((editor.QueryStatusByID(2185) & 2) !== 0) { > editor.ExecuteCommandByID(2185); > } > ``` > > [常に最上位] がオンになっていたら、それを自動で解除するマクロです。 > > これを [イベント] の [フォーカスを失った時] に設定しておけば、誤ってオンにしてしまっても、別のウィンドウに切り替えたタイミングで自動的に解除されます。 > > (ちなみに、解除と同時に別のウィンドウを前面に持ってくるには、タイトル バー部分をクリックする必要があるようです)

マークダウンを有効にする