フォームに追加すると、いくつかの要素がアプリケーション設定に自動的に追加される WinForms ユーザー コントロールがあります。(もちろん、ユーザーはこの動作をカスタマイズ/無効にできる必要があります。)
それは賢明ですか？これを行う「良い」方法は何ですか？
[編集]
コントロールは、ファイル メニューの既定の実装を提供します。消費者は、デザイナーでメニュー/ツールバー項目を接続し、いくつかの基本的なイベントを実装するだけで済みます。この一部は最近のファイル リストであり、デフォルトで記憶されます。
消費者がこれらの設定を自動的に追加するかどうかを完全に制御する必要があることに同意します。
これまでのところ、ファイル リストをパブリック文字列プロパティとして公開しており、消費者はコードを init に追加して、これをアプリケーション構成から、またはアプリケーション構成に保存できます。可能であれば、これをさらに単純化したいので、消費者は設定を保存したい場所に設定変数を提供するだけです (必要な場合)。
要求されない限り、コントロールが設定ファイルに何かを追加するべきではないと思います。
それでも、ユーザーがこれに「オプトイン」した場合は、コントロールにデザイナーサポートを追加する必要があると思います。ToolBoxItemを介して、または新しいコントロールが追加されたことをデザイナーに通知することにより、デザイナーは必要な構成情報を作成および/または更新する必要があります。
説明してくれてありがとう。IPersistControlSettingsインターフェイス、特にApplicationSettingsBaseの件名について説明する内容を確認することをお勧めします。このページから、.NET2.0で強く入力された設定に関する情報が表示されます。これにより、デフォルト設定をコントロールまたは他のライブラリコードに組み込むことができ、設定が変更された場合でも、ユーザーごとまたはアプリケーション全体で、変更がアプリケーションの構成ファイルに保持されます。
コントロールコンストラクターでは、（LicenseManager.UsageMode == LicenseUsageMode.Designtime）をチェックしてから、構成エントリなどをチェックできますが、これは悪い考えだと思います。
コントロールは、構成エントリが存在する場合はそれをサポートし、存在しない場合はデフォルトの動作をする可能性があります。それは開発者として私にはもっと受け入れられるように思えます
どちらの方法でもカスタム構成セクションを使用する必要があります
コントロールの一部としてカスタム構成セクションハンドラーを提供できるため、使用する必要がある場合は、このセクションを構成ファイルに接続するだけで済みます。
使い勝手の良いコントロールの消費者からどれだけの価値が得られるかによると思います。このコントロールを販売していますか？内部使用ですか？設計時のエクスペリエンスを作成するために必要な作業は、これが内部使用の場合、おそらく法外なものになります。