次の方法で共有


Visual Studio のアプリケーション パターン

ウィンドウの対話式操作

Visual Studio で使用される 2 つの主なウィンドウの種類は、ドキュメント エディターとツール ウィンドウです。 大きいモードレス ダイアログがまれに使用されることがあります。 これらはすべてシェルではモードレスですが、パターンが基本的に異なります。 このセクションでは、ドキュメント ウィンドウ、ツール ウィンドウ、モードレス ダイアログの違いについて説明します。 モーダル ダイアログのパターンについては、「ダイアログ」で説明します。

ウィンドウの使用パターンの比較

ドキュメント ウィンドウは、ほとんど常にドキュメント ウェル内に表示されます。 これにより、補助的なツール ウィンドウをまわりに配置するための "センター ステージ" がドキュメント エディターに与えられます。

ツール ウィンドウは、多くの場合、IDE の端に対して折りたたまれた個別の小さなウィンドウとして表示されます。 これは、表示、非表示、または自動非表示にすることができます。 ただし、ウィンドウのウィンドウ/ドッキング プロパティをオフにして、ツール ウィンドウがドキュメント ウェル内に表示されることがあります。 これにより、より大きな領域が得られますが、一般的な設計上の決定事項でもあります。つまり、Visual Studio に統合する場合は、機能でツール ウィンドウとドキュメント ウィンドウのどちらが表示されるようにするかを決定する必要があります。

Visual Studio では、モードレス ダイアログはお勧めしません。 ほとんどのモードレス ダイアログは、定義上、移動ツール ウィンドウであり、そのように実装する必要があります。 シェルの横にドッキングされる通常のツール ウィンドウのサイズが非常に限られている場合は、モードレス ダイアログが許可されます。 また、ユーザーがダイアログをセカンダリ モニターに移動する可能性がある場合にも許可されます。

必要なコンテナーの種類については、慎重に検討してください。 次の表に、UI デザインの一般的な使用パターンに関する考慮事項を示します。

ドキュメント ウィンドウ ツール ウィンドウ モードレス ダイアログ
Position 常にドキュメント ウェル内に配置され、IDE の端のあたりにはドッキングされません。 メインのシェルとは別に浮動できるように、"切り離す" ことができます。 通常、IDE の端のまわりにタブでドッキングされますが、移動ウィンドウ、自動非表示 (固定解除) にしたり、ドキュメント ウェル内にドッキングするようにしたりしてカスタマイズできます。 IDE とは別個の大きな移動ウィンドウ。
コミット モデル 遅延コミット

ドキュメントにデータを保存するには、[ファイル] > [保存][名前を付けて保存]、または [すべてを保存] コマンドを発行する必要があります。 ドキュメント ウィンドウには、その中のデータが "ダーティ" になり、その後、保存コマンドの 1 つにコミットされるという概念があります。 ドキュメント ウィンドウを閉じると、すべての内容がディスクに保存されるか、失われます。
即時コミット

保存モデルはありません。 ファイルの編集を支援するインスペクター ツール ウィンドウの場合は、ファイルがアクティブなエディターまたはデザイナーで開かれていて、エディターまたはデザイナーに保存がある必要があります。
遅延または即時コミット

多くの場合、大きいモードレス ダイアログでは、変更をコミットするアクションが必要であり、ダイアログ セッション内で行われた変更をロールバックする "キャンセル" 操作が許可されます。 これにより、ツール ウィンドウは常に即時コミット モデルであるという点で、モードレス ダイアログとツール ウィンドウが区別されます。
表示 開く/作成 (ファイル) および閉じる

ドキュメント ウィンドウを開くには、既存のドキュメントを開くか、テンプレートを使用して新しいドキュメントを作成します。 "<特定のエディター> を開く" コマンドはありません。
非表示と表示

単一インスタンスのツール ウィンドウは、非表示にしたり表示したりすることができます。 ツール ウィンドウ内の内容と状態は、表示または非表示のいずれでも保持されます。 複数インスタンスのツール ウィンドウは、非表示にするだけでなく、閉じることもできます。 複数インスタンスのツール ウィンドウが閉じられた場合、ツール ウィンドウ内の内容と状態は破棄されます。
コマンドから起動

ダイアログは、タスクベースのコマンドから起動されます。
インスタンス 複数インスタンス

複数のエディターを同時に開いて異なるファイルを編集することができますが、エディターによっては、同じファイルを複数のエディターで開くこともできます ([ウィンドウ] > [新しいウィンドウ] コマンドを使用)。

1 つのエディターで 1 つまたは複数のファイルを同時に編集できます (プロジェクト デザイナー)。
1 つまたは複数のインスタンス

コンテンツは、コンテキストを反映する (プロパティ ブラウザーと同様) か、他のウィンドウ (タスク一覧、ソリューション エクスプローラー) にフォーカスまたはコンテキストをプッシュするように変更されます。

単一インスタンスと複数インスタンスの両方のツール ウィンドウは、やむを得ない理由がない限り、アクティブなドキュメント ウィンドウに関連付けられている必要があります。
単一インスタンス
使用例 テキスト エディター (コード エディターなど)

デザイン サーフェイス (フォーム デザイナーやモデリング サーフェイスなど)

ダイアログと同様のコントロール レイアウト (マニフェスト デザイナーなど)
ソリューション エクスプローラーでは、ソリューション内に含まれるソリューションとプロジェクトが提供されます

サーバー エクスプローラーでは、ユーザーがウィンドウで開くことを選択したサーバーとデータ接続の階層ビューが提供されます。 データベース階層からオブジェクトを開くと (クエリなど)、ドキュメント ウィンドウが開き、ユーザーがクエリを編集できるようになります。

プロパティ ブラウザーには、ドキュメント ウィンドウまたは別のツール ウィンドウで選択されたオブジェクトのプロパティが表示されます。 プロパティは、階層的なグリッド ビューまたはダイアログに似た複雑なコントロールで表示され、ユーザーはそれらのプロパティの値を設定できます。

ツール ウィンドウ

ツール ウィンドウによって、ドキュメント ウィンドウで行われるユーザーの作業がサポートされます。 これらは、Visual Studio で提供され、操作できる基本的なルート オブジェクトを表す階層を表示するために使用できます。

IDE に新しいツール ウィンドウを作成することを検討する場合、作成者は次のようにする必要があります。

  • タスクに適した既存のツール ウィンドウを使用し、同様の機能を持つ新しいものを作成しないようにします。 新しいツール ウィンドウは、同様のウィンドウに統合できない大幅に異なる "ツール" または機能が提供される場合に作成するか、既存のウィンドウをピボット ハブに変換することによってのみ作成する必要があります。

  • 必要に応じて、ツール ウィンドウの上部に標準のコマンド バーを使用します。

  • コントロールの表示とキーボード ナビゲーションが、他のツール ウィンドウに既に存在するパターンと一貫性を持つようにします。

  • 他のツール ウィンドウでのコントロールの表示と一貫性を持つようにします。

  • 可能な場合は、ドキュメント固有のツール ウィンドウを自動表示にして、親ドキュメントがアクティブになったときにのみ表示されるようにします。

  • キーボードでウィンドウ コンテンツをナビゲートできるようにします (方向キーをサポートします)。

ツール ウィンドウの状態

Visual Studio のツール ウィンドウにはさまざまな状態があります。その中には、ユーザーによってアクティブにされるもの (自動非表示機能など) があります。 自動表示などの他の状態では、ツール ウィンドウを正しいコンテキストで表示し、不要な場合は非表示にすることができます。 ツール ウィンドウの状態は全部で 5 つあります。

  • ドッキング/固定のツール ウィンドウは、ドキュメント領域の 4 辺のいずれかに連結することができます。 画鋲アイコンがツール ウィンドウのタイトル バーに表示されます。 ツール ウィンドウは、シェルやその他のツール ウィンドウの端に沿って水平方向または垂直方向にドッキングでき、タブでリンクすることもできます。

  • 自動非表示のツール ウィンドウは固定解除されます。 ウィンドウは、表示から見えなくなり、ドキュメント領域の端にタブ (ツール ウィンドウの名前とアイコンを持つ) が残ります。 ツール ウィンドウは、ユーザーがタブの上にマウスを置いたときに現れます。

  • 自動表示のツール ウィンドウは、別の部分の UI (エディターなど) が起動されるか、フォーカスが当たると自動的に表示されます。

  • 移動ツール ウィンドウは IDE の外側を浮動します。 これはマルチモニター構成で便利です。

  • タブ付きドキュメントのツール ウィンドウは、ドキュメント ウェル内にドッキングできます。 これは、フレームの端にドッキングする場合よりも広い領域を必要とする大きいツール ウィンドウ (オブジェクト ブラウザーなど) で便利です。

Tool window states in Visual Studio
Visual Studio でのツール ウィンドウの状態

単一インスタンスと複数インスタンス

ツール ウィンドウは、単一インスタンスまたは複数インスタンスです。 一部の単一インスタンスのツール ウィンドウは、アクティブなドキュメント ウィンドウに関連付けることができますが、複数インスタンスのツール ウィンドウは関連付けることができません。 複数インスタンスのツール ウィンドウでは、ウィンドウの新しいインスタンスを作成することによって、[ウィンドウ] > [新しいウィンドウ] コマンドに応答します。 次の図は、ウィンドウのインスタンスがアクティブなときに、[新しいウィンドウ] コマンドが有効になっているツール ウィンドウを示しています。

Tool window enabling 'New Window' command when an instance of the window is active
ウィンドウのインスタンスがアクティブなときに、[新しいウィンドウ] コマンドが有効になっているツール ウィンドウ

単一インスタンスのツール ウィンドウは非表示にしたり表示したりすることができますが、複数インスタンスのツール ウィンドウは非表示にするだけではなく、閉じることができます。 すべてのツール ウィンドウは、ドッキング、タブ リンク、移動ウィンドウにしたり、マルチドキュメント インターフェイス (MDI) の子ウィンドウ (ドキュメント ウィンドウに似ています) として設定したりすることができます。 すべてのツール ウィンドウでは、[ウィンドウ] メニューの適切なウィンドウ管理コマンドに応答する必要があります。

Window management commands in the Visual Studio Window menu
Visual Studio の [ウィンドウ] メニューのウィンドウ管理コマンド

ドキュメント固有のツール ウィンドウ

一部のツール ウィンドウは、指定された種類のドキュメントに基づいて変更されるように設計されています。 これらのウィンドウは、IDE のアクティブなドキュメント ウィンドウに適用できる機能が反映されるように、継続的に更新されます。

選択したエディターが反映されるように内容が変更されるツール ウィンドウの例としては、ツールボックスとドキュメント アウトラインがあります。 ウィンドウにコンテキストが提供されないエディターにフォーカスがある場合、これらのウィンドウにはウォーターマークが表示されます。

一部のツール ウィンドウには、ユーザーが操作できるナビゲーション可能な項目のリストが表示されます。 この種類のウィンドウでは、ウィンドウがアクティブでない場合でも、リスト内の現在の項目に対して常にフィードバックされる必要があります。 リストでは、ウィンドウで現在選択されている項目を変更することで、GoToNextLocation および GoToPrevLocation コマンドに応答する必要があります

ナビゲーション可能なリストのツール ウィンドウの例としては、ソリューション エクスプローラーと [検索結果] ウィンドウがあります。

ツール ウィンドウの種類

一般的なツール ウィンドウとその機能

階層ツール ウィンドウ

ツール ウィンドウ 機能
ソリューション エクスプローラー プロジェクト、各種ファイル、ソリューション項目に含まれるドキュメントのリストが表示される階層ツリー。 プロジェクト内の項目の表示は、プロジェクトの種類 (参照ベース、ディレクトリベース、混合モードの種類など) を所有するパッケージによって定義されます。
クラス ビュー ファイル自体に依存しない、ドキュメントの作業セット内のクラスとさまざまな要素の階層ツリー。
[サーバー エクスプローラー] ソリューション内のすべてのサーバーおよびデータ接続が表示される階層ツリー。
ドキュメント アウトライン アクティブなドキュメントの階層構造。

グリッド ツール ウィンドウ

ツール ウィンドウ 機能
プロパティ 選択したオブジェクトのプロパティのリストと、それらのプロパティを編集するための値ピッカーが表示されるグリッド。
タスク一覧 ユーザーがタスクとコメントを作成/編集/削除できるグリッド。

コンテンツ ツール ウィンドウ

ツール ウィンドウ 機能
Help ユーザーにヘルプを取得するためのさまざまな方法 ("カテゴリから検索" ビデオから MSDN フォーラムまで) へのアクセスを可能にするウィンドウ。
ダイナミック ヘルプを表示する 現在の選択に該当するヘルプ トピックへのリンクが表示されるツール ウィンドウ。
オブジェクト ブラウザー 左ペインに階層オブジェクト コンポーネントのリスト、右側の列にオブジェクトのプロパティとメソッドを持つ 2 列のフレームセット。

ダイアログ ツール ウィンドウ

ツール ウィンドウ 機能
[検索] ソリューション内のさまざまなファイルの検索または検索と置換をユーザーが行うことができるダイアログ。
高度な検索 ソリューション内のさまざまなファイルの検索または検索と置換をユーザーが行うことができるダイアログ。

その他のツール ウィンドウ

ツール ウィンドウ 機能
ツールボックス デザイン サーフェイスにドロップされる要素を格納するために使用されるツール ウィンドウ。これにより、すべてのデザイナーに一貫性のあるドラッグ ソースが提供されます。

デバッガー ツール ウィンドウ

ツール ウィンドウ 機能
Autos
即時
出力 出力ウィンドウは、宣言するテキスト イベントまたは状態がある場合に使用できます。
[メモリ]
ブレークポイント
実行中
ドキュメント​
呼び出し履歴
ローカル
ウォッチ
逆アセンブリ
レジスター
スレッド

ドキュメント エディターの規則

ドキュメントの対話式操作

"ドキュメント ウェル" は、IDE 内の最大の領域であり、補足的なツール ウィンドウに支援されて、通常、ユーザーがタスクを完了するために注意を向けている場所です。 ドキュメント エディターは、ユーザーが Visual Studio 内で開いたり保存したりする作業の基本単位を表します。 これらは、ソリューション エクスプローラーまたはその他のアクティブな階層ウィンドウに、選択が強く結び付けられています。 ユーザーが、これらの階層ウィンドウのいずれかをポイントでき、ドキュメントが含まれている場所と、Visual Studio パッケージによって提供されるソリューション、プロジェクト、または別のルート オブジェクトとの関係を認識できる必要があります。

ドキュメントの編集には、一貫したユーザー エクスペリエンスが必要です。 ユーザーがウィンドウの管理やコマンドの検索ではなく自分のタスクに集中できるようにするには、そのドキュメントの種類を編集するためのユーザーのタスクに最適なドキュメント ビューの戦略を選択します。

ドキュメント ウェルの一般的な対話式操作

  • [新しいファイル][ファイルを開く] の一般的なエクスペリエンスで、一貫性のある対話式操作モデルが維持されます。

  • ドキュメント ウィンドウを開くと、関連するウィンドウとメニューの関連機能が更新されます。

  • メニュー コマンドは、[編集][書式設定][表示] メニューなどの一般的なメニューに適切に統合されます。 大量の特化されたコマンドを使用できる場合は、新しいメニューを作成できます。 この新しいメニューは、ドキュメントにフォーカスがある場合にのみ表示されます。

  • 埋め込みツール バーは、エディターの上部に配置できます。 これは、エディターの外部に別のツール バーを配置する場合に適しています。

  • ソリューション エクスプローラーまたは同様のアクティブな階層ウィンドウで、常に選択が維持されます。

  • ソリューション エクスプローラーでドキュメントをダブルクリックすると、[開く]と同じアクションが実行されます。

  • 1 つのドキュメントの種類に対して複数のエディターを使用できる場合、ユーザーが指定されたドキュメントの種類の既定のアクションをオーバーライドまたはリセットできる必要があります。このためには、ファイルを右クリックしてショートカット メニューの [ファイルを開くアプリケーションの選択] を選択することによって [ファイルを開くアプリケーションの選択] ダイアログ ボックスを使用します。

  • ドキュメント ウェルにウィザードを作成しないでください。

特定のドキュメントの種類でのユーザーの想定

ドキュメント エディターにはいくつかの異なる基本的な種類があり、それぞれに同じ種類の他のものと一貫性のある一連の対話式操作があります。

  • テキストベースのエディター: コード エディター、ログ ファイル

  • デザイン サーフェイス: WPF フォーム デザイナー、Windows フォーム

  • ダイアログスタイルのエディター: マニフェスト デザイナー、プロジェクト プロパティ

  • モデル デザイナー: ワークフロー デザイナー、CodeMap、アーキテクチャ図、進行状況

ドキュメント ウェルを使用するエディター以外の種類もいくつかあります。 ドキュメント自体は編集されませんが、ドキュメント ウィンドウの標準的な対話式操作に従う必要があります。

  • レポート: IntelliTrace レポート、Hyper-V レポート、プロファイラー レポート

  • ダッシュボード: 診断ハブ

テキストベースのエディター

  • ドキュメントはプレビュー タブ モデルに含まれており、ドキュメントを開くことなくプレビューできます。

  • ドキュメントの構造は、ドキュメント アウトラインなどのコンパニオン ツール ウィンドウ内に表示できます。

  • IntelliSense (該当する場合) は、他のコード エディターと一貫性を持って動作します。

  • ポップアップまたは補助 UI は、CodeLens など、既存の同様の UI に似たスタイルとパターンに従います。

  • ドキュメントの状態に関するメッセージは、ドキュメントの上部の情報バー コントロールまたはステータス バーに表示されます。

  • ユーザーは、[ツール] > [オプション] ページを使用して、共有の [フォントおよび色] ページまたはエディター固有の [フォントおよび色] ページで、フォントおよび色の外観をカスタマイズできる必要があります。

デザイン サーフェイス

  • 空のデザイナーでは、開始方法を示すウォーターマークがサーフェイスに表示されます。

  • ビュー切り替えメカニズムでは、既存のパターンに従って (ダブルクリックしてコード エディターを開く、ドキュメント ウィンドウ内のタブなど)、両方のペインを対話式操作できます。

  • 非常に特殊なツール ウィンドウが必要である場合を除き、デザイン サーフェイスへの要素の追加は、ツールボックスを使用して行う必要があります。

  • サーフェイス上の項目は、一貫した選択モデルに従います。

  • 埋め込みのツール バーには、ドキュメント固有のコマンドだけが含まれており、[保存] などの一般的なコマンドは含まれません。

ダイアログスタイルのエディター

  • コントロールのレイアウトは、通常のダイアログ レイアウトの規則に従う必要があります。

  • エディター内のタブは、ドキュメントのタブの外観と一致しないようにする必要があります。これらは、許可されている 2 つの内部タブのスタイルのいずれかと一致している必要があります。

  • ユーザーが、キーボードのみを使用してコントロールを操作できる必要があります (エディターをアクティブにして、Tab キーを押してコントロール間を移動するか、標準のニーモニックを使用することにより)。

  • デザイナーでは、共通の保存モデルを使用する必要があります。 全体的な [保存] またはコミット ボタンをサーフェイスに配置しないでください。ただし、他のボタンは適切な場合があります。

モデル デザイナー

  • 空のデザイナーでは、開始方法を示すウォーターマークがサーフェイスに表示されます。

  • デザイン サーフェイスへの要素の追加は、ツールボックスを使用して行う必要があります。

  • サーフェイス上の項目は、一貫した選択モデルに従います。

  • 埋め込みのツール バーには、ドキュメント固有のコマンドだけが含まれており、[保存] などの一般的なコマンドは含まれません。

  • サーフェイスに凡例を表示できます (明示的または透かしで)。

  • ユーザーは、[ツール] > [オプション] ページを使用して、共有の [フォントおよび色] ページまたはエディター固有の [フォントおよび色] ページで、フォントおよび色の外観をカスタマイズできる必要があります。

レポート

  • 通常、レポートは情報専用であり、保存モデルに加わっていません。 ただし、他の関連情報へのリンクや展開と折りたたみが行われるセクションなどの対話式操作が含まれることがあります。

  • サーフェイス上のほとんどのコマンドは、ボタンではなくハイパーリンクにする必要があります。

  • レイアウトには、ヘッダーを含め、標準的なレポート レイアウトのガイドラインに従う必要があります。

ダッシュボード

  • ダッシュボードは、それ自体に対話式操作モデルはありませんが、他のさまざまなツールを提供する手段として機能します。

  • これらは保存モデルに加わっていません。

  • ユーザーが、キーボードのみを使用してコントロールを操作できる必要があります (エディターをアクティブにして、Tab キーを押してコントロール間を移動するか、標準のニーモニックを使用することにより)。

ダイアログ

はじめに

通常、Visual Studio のダイアログでは、ユーザーの作業の個別の 1 単位がサポートされ、その後、破棄されます。

ダイアログが必要であると判断した場合は、次の 3 つの選択肢があります (優先度の順)。

  1. 機能を Visual Studio の共有ダイアログの 1 つに統合します。

  2. 既存の同様のダイアログのパターンを使用して、独自のダイアログを作成します。

  3. 対話式操作とレイアウトのガイドラインに従って、新しいダイアログを作成します。

このセクションでは、Visual Studio のワークフロー内で適切なダイアログ パターンを選択する方法と、ダイアログの設計のための一般的な規則について説明します。

テーマ

Visual Studio のダイアログでは、次の 2 つの基本的なスタイルのいずれかに従います。

標準 (テーマなし)

ダイアログの大部分は標準ユーティリティ ダイアログであり、テーマを適用しないようにする必要があります。 一般的なコントロールを再テンプレート化したり、定型的な "モダンな" ボタンまたはコントロールを作成したりしないでください。 コントロールとクロムの外観は、ダイアログ ボックスの標準の Windows デスクトップ対話式操作ガイドラインに従います。

テーマあり

特別な "特徴的な" ダイアログには、テーマを適用することができます。 テーマが適用されているダイアログは、異なる外観を持ち、スタイルに関連付けられている特殊な対話式操作のパターンもあります。 次の要件が満たされている場合にのみ、ダイアログにテーマを適用します。

  • ダイアログは、頻繁に表示および使用されるか、多くのユーザーによって使用される一般的なエクスペリエンスである ([新しいプロジェクト] ダイアログ ボックスなど)。

  • ダイアログに、代表的な製品ブランド要素が含まれている ([アカウント設定] ダイアログなど)。

  • ダイアログが、テーマが適用されている他のダイアログを含むより大きなフローの不可欠な部分として表示される ([接続済みサービスの追加] ダイアログなど)。

  • ダイアログは、製品バージョンを販売促進または差別化するための戦略的な役割を果たす、エクスペリエンスの重要な部分である。

テーマが適用されているダイアログを作成する場合は、適切な環境の色を使用して、正しいレイアウトと対話式操作のパターンに従います。 (「Visual Studio のレイアウト」を参照してください。)

ダイアログのデザイン

適切に設計されたダイアログでは、次の要素が考慮されています。

  • サポートされるユーザー タスク

  • ダイアログのテキストのスタイル、言語、用語

  • コントロールの選択と UI の規則

  • ビジュアル レイアウトの指定とコントロールの配置

  • キーボード アクセス

コンテンツの編成

次の基本的な種類のダイアログの違いを考慮してください。

  • 単純なダイアログ では、1 つのモーダル ウィンドウにコントロールが表示されます。 この表示には、フィールド ピッカーやアイコン バーなど、複雑なコントロール パターンのバリエーションが含まれる場合があります。

  • 階層化ダイアログは、1 つの UI が複数のコントロールのグループで構成されている場合に、画面の領域を最大限に活用するために使用されます。 ダイアログのグループは、タブ コントロール、ナビゲーション リスト コントロール、またはボタンによって "階層化" され、ユーザーが任意の時点で表示するグループを選択できるようにします。

  • ウィザードは、タスクを完了させるための論理的な一連のステップを通じてユーザーを導く場合に便利です。 連続するパネルで一連の選択肢が提供され、前のパネルでの選択に応じて異なるワークフロー ("分岐") となることがあります。

単純なダイアログ

単純なダイアログでは、1 つのモーダル ウィンドウにコントロールが表示されます。 この表示には、フィールド ピッカーなど、複雑なコントロール パターンのバリエーションが含まれる場合があります。 単純なダイアログの場合は、標準の一般的なレイアウトに加えて、複雑なコントロールのグループに必要な特定のレイアウトに従います。

>Create Strong Name Key is an example of a simple dialog in Visual Studio.
厳密な名前キーの作成は、Visual Studio の単純なダイアログの例です。

階層化ダイアログ

階層化ダイアログには、タブ、ダッシュボード、埋め込みツリーが含まれます。 1 つの UI に複数のコントロールのグループが提供される場合に、領域を最大限に活用するために使用されます。 表示するグループをユーザーがいつでも選択できるように、グループが階層化されます。

最も単純なケースでは、グループを切り替えるメカニズムはタブ コントロールです。 使用できるいくつかの代替方法があります。 最適なスタイルを選択する方法については、「優先順位と階層化」を参照してください。

[ツール] > [オプション] ダイアログは、埋め込みツリーを使用した階層化ダイアログの例です。

Tools > Options is an example of a layered dialog in Visual Studio.
[ツール] > [オプション] は、Visual Studio の階層化ダイアログの例です。

ウィザード

ウィザードは、タスクを完了させるための論理的な一連の手順通じてユーザーを導く場合に便利です。 連続したパネルで一連の選択肢が提供され、ユーザーは、次に進む前に各ステップを実行する必要があります。 十分な既定値を使用できるようになると、[完了] ボタンが有効になります。

モーダル ウィザードは、次のようなタスクに使用されます。

  • 分岐が含まれていて、ユーザーの選択に応じて異なるパスが提供される

  • ステップ間に依存関係があり、後続のステップは前のステップのユーザー入力に依存する

  • UI を使用して、提供される選択肢と各ステップの考えられる結果を説明する必要があるくらいに複雑である

  • トランザクションであり、変更がコミットされる前に、一連のステップが完全に完了している必要がある

一般的な規則

ダイアログの最適な設計と機能を実現するには、ダイアログのサイズ、位置、標準、コントロールの構成と配置、UI テキスト、タイトル バー、コントロール ボタン、アクセス キーに関する以下の規則に従います。

レイアウト固有のガイドラインについては、「Visual Studio のレイアウト」を参照してください。

サイズ

ダイアログは最低 1024 x 768 の画面解像度で表示できる必要があり、初期状態のダイアログ サイズが 900 x 700 ピクセルを超えないようにする必要があります。 ダイアログはサイズ変更可能にすることができますが、必須ではありません。

サイズ変更可能なダイアログには、次の 2 つの推奨事項があります。

  1. クリッピングなしでコントロール セットが最適化され、ローカライズによるやむを得ない増加に合わせて調整されるように、ダイアログの最小サイズを定義します。

  2. ユーザーがスケーリングしたサイズが、次のセッションでも維持されるようにします。 たとえば、ユーザーがダイアログを 150% にスケーリングした場合、そのダイアログのそれ以降の起動でも 150% で表示します。

配置

ダイアログは、最初の起動時に IDE 内の中央に表示される必要があります。 サイズ変更可能ではないダイアログの最後の位置は維持する必要がないため、それ以降の起動時に中央に表示されます。

サイズ変更可能なダイアログの場合は、それ以降の起動でサイズが維持される必要があります。 サイズ変更が可能なモーダル ダイアログでは、位置を維持する必要はありません。 IDE 内でそれらを中央に表示すると、ユーザーの表示構成が変更されたときに、予期しない位置または使用できない位置にダイアログが表示される可能性がなくなります。

位置を変更できるモードレス ダイアログの場合、ダイアログはより大きいワークフローの不可欠な部分として頻繁に使用される可能性があるため、それ以降の起動時にユーザーの位置が維持される必要があります。

ダイアログで他のダイアログが生成される必要がある場合は、一番上のダイアログを親の右と下にカスケードして、新しい場所にナビゲートされたことがユーザーに明白になるようにする必要があります。

モダリティ

モーダルであるとは、続行する前にユーザーがダイアログを完了またはキャンセルする必要があることを意味します。 モーダル ダイアログでは、ユーザーが環境の他の部分を操作することがブロックされるため、機能のタスク フローでは、それらをできるだけ控えめに使用する必要があります。 モーダル操作が必要な場合、Visual Studio には、機能を統合できる多数の共有ダイアログが用意されています。 新しいダイアログを作成する必要がある場合は、同様の機能を持つ既存のダイアログの対話式操作のパターンに従います。

ユーザーが新しいコードを記述しているときに、一度に 2 つのアクティビティ ([検索][置換] など) を実行する必要がある場合は、ユーザーが簡単に切り替えることができるように、ダイアログをモードレスにする必要があります。 通常、Visual Studio では、リンクされたタスクをサポートするこの種類のエディターにツール ウィンドウを使用します。

コントロールの構成

Visual Studio で同じことを実現する既存のコントロールの構成と一貫性を持つようにします。

タイトル バー

  • タイトル バーのテキストには、それを起動したコマンドの名前が反映される必要があります。

  • ダイアログのタイトル バーにはアイコンを使用しないでください。 システムで必要な場合は、Visual Studio のロゴを使用します。

  • ダイアログには、最小化ボタンと最大化ボタンを含めないようにする必要があります。

  • タイトル バーの [ヘルプ] ボタンは非推奨となりました。 新しいダイアログに追加しないでください。 概念上タスクに関連するヘルプ トピック (存在する場合) が起動される必要があります。

    Guideline specifications for title bars in Visual Studio dialogs
    Visual Studio ダイアログのタイトル バーのガイドライン仕様

コントロール ボタン

一般に、[OK][キャンセル][ヘルプ] ボタンは、ダイアログの右下隅に水平に配置する必要があります。 コントロール ボタンと視覚的な混乱をもたらす他のボタンがダイアログの下部にある場合は、代替の垂直方向の積み重ねが許可されます。

Acceptable configurations for control buttons in Visual Studio dialogs
Visual Studio ダイアログのコントロール ボタンの許容される構成

ダイアログには、既定のコントロール ボタンが含まれている必要があります。 既定として使用する最適なコマンドを決定するには、次のオプションから選択します (優先順に記載されています)。

  • 既定として最も安全でセキュアなコマンドを選択します。 これは、データ損失を防ぎ、意図しないシステム アクセスを避けられる可能性の最も高いコマンドを選択することを意味します。

  • データの損失とセキュリティが要因ではない場合は、利便性に基づいて既定のコマンドを選択します。 最も可能性の高いコマンドを既定として含めると、ダイアログで頻度の高いタスクまたは繰り返し実行されるタスクがサポートされる場合に、ユーザーのワークフローが改善されます。

既定のコマンドに永続的に破壊するようなアクションを選択することは避けてください。 そのようなコマンドがある場合は、代わりに、より安全なコマンドを既定として選択します。

アクセス キー

[OK][キャンセル]、または [ヘルプ] の各ボタンにアクセス キーを使用しないでください。 これらのボタンは、既定でショートカット キーにマップされます。

ボタンの名前 キーボード ショートカット
OK Enter
Cancel Esc
Help F1

画像

ダイアログでは、画像は控えめに使用します。 領域が使い尽くされるだけなので、ダイアログに大きいアイコンを使用しないでください。 画像は、警告アイコンや状態アニメーションなど、ユーザーにメッセージを伝えるための重要な部分である場合にのみ使用してください。

優先順位付けと階層化

UI の優先度

特定の UI 要素を最前部に配置し、より高度な動作とオプション (わかりにくいコマンドを含む) をダイアログに配置することが必要になる場合があります。 一般的に使用される機能を領域を確保して最前部に配置します。また、ダイアログが表示されるときに、既定でテキスト ラベルを付けて UI に表示されるようにします。

UI の階層化

ダイアログが必要であると判断したが、ユーザーに提供する関連機能が簡単なダイアログには表示できない場合は、UI を階層化する必要があります。 Visual Studio で使用される最も一般的な階層化方法は、タブとホールウェイまたはダッシュボードです。 場合によっては、展開と折りたたみを行うことができる領域が適切なことがあります。 通常、アダプティブ UI は Visual Studio ではお勧めしません。

タブに似たコントロールを使用して UI を階層化するさまざまな方法には、利点と欠点があります。 以下の一覧を確認して、状況に適した階層化手法を選択するようにしてください。

タブ移動
切り替えメカニズム 長所と適切な使用方法 短所と不適切な使用方法
タブ コントロール ダイアログ ページを関連するセットに論理的にグループ化します

ダイアログ内の 5 ページ未満 (またはダイアログの 1 行に適合するタブの数) の関連するコントロールで役立ちます

タブのラベルは、短くする必要があります (コンテンツを簡単に識別できる 1 つまたは 2 つの単語)

共通のシステム ダイアログ スタイル

例: [エクスプローラー] > [項目のプロパティ]
わかりやすい短いラベルを作成するのが難しい場合があります

通常は、1 つのダイアログで 5 つ以上のタブにスケーリングしません

1 つの行にタブが多すぎる場合は適切ではありません (代替の階層化技法を使用します)

拡張可能ではありません
サイド バーのナビゲーション タブよりも多くのカテゴリに対応できる単純な切り替えデバイス

カテゴリのフラット リスト (階層なし)

拡張可能

例: [カスタマイズ] > [コマンドの追加]
グループが 3 つ未満の場合は、水平方向の領域が適切に使用されません

タスクにはドロップダウンがより適している可能性があります
ツリー コントロール 無制限のカテゴリに対応できます

カテゴリをグループ化または階層化 (あるいはその両方) できます

拡張可能

例: [ツール] > [オプション]
入れ子になった階層が多いと、過度な水平方向のスクロールが必要になる場合があります

Visual Studio のツリー ビューが過剰になります
ウィザード タスクベースの連続したステップを通じてユーザーをガイドすることで、タスクを完了するために役立ちます。ウィザードはハイレベルのタスクを表し、個々のパネルはタスク全体を達成するために必要なサブタスクを表します

ユーザーが複数のエディターとツール ウィンドウを使用してタスクを完了する必要がある場合など、タスクが UI の境界を越えている場合に役に立ちます

タスクに分岐が必要な場合に便利です

タスクのステップ間に依存関係がある場合に便利です

1 つの意思決定フォークを持つ複数の同様のタスクを 1 つのダイアログに表示することによって、同じようなダイアログの数を減らすことができる場合に便利です
連続したワークフローを必要としないタスクには適していません

ウィザードのステップが多すぎると、ユーザーがうんざりしたり混乱したりする可能性があります

ウィザードの画面の領域は本質的に制限されています
ホールウェイまたはダッシュボード

ホールウェイとダッシュボードは、他のダイアログやウィンドウへの起動ポイントとして機能するダイアログまたはパネルです。 適切に設計された "ホールウェイ" では、最も一般的なオプション、コマンド、設定のみがすぐに表示されるため、ユーザーは一般的なタスクを簡単に実行できます。 実世界の廊下と同様に、その背後にある部屋にアクセスするためのドアウェイが提供されます。ここでは、あまり一般的ではない UI が、メインのホールウェイからアクセスできる関連機能の個別の "部屋" (多くの場合は他のダイアログ) に集められています。

一方、あまり一般的ではない機能を別の場所にリファクタリングするのではなく、使用可能なすべての機能を単一のコレクションで提供する UI は、単純にダッシュボードです。

Hallway concept for exposing additional UI in Outlook
Outlook で追加の UI を表示するためのホールウェイの概念

アダプティブ UI

使用状況またはユーザーの自己報告エクスペリエンスに基づいて UI を表示または非表示にすることは、必要な UI を表示しながら他の部分を非表示にするもう 1 つの方法です。 これは、Visual Studio ではお勧めしません。UI を表示または非表示にするタイミングを決定するアルゴリズムは注意が必要であり、一部のケースでは規則が常に誤りとなるからです。

プロジェクト

ソリューション エクスプローラー内のプロジェクト

ほとんどのプロジェクトは、参照ベース、ディレクトリベース、または混合として分類されます。 3 種類のプロジェクトはすべて、ソリューション エクスプローラーで同時にサポートされます。 プロジェクトで作業する際のユーザー エクスペリエンスのルートは、このウィンドウ内となります。 各種のプロジェクト ノードは参照、ディレクトリ、または混合モードの種類のプロジェクトですが、プロジェクト固有のユーザー パターンに分岐する前に、出発点として適用する必要がある共通の対話式操作のパターンがあります。

プロジェクトでは常に次のようである必要があります。

  • プロジェクトのコンテンツを整理するためのプロジェクト フォルダーを追加する機能がサポートされます

  • プロジェクトの永続化のための一貫したモデルが維持されます

プロジェクトでは、次の場合に一貫性のある対話式操作モデルが維持される必要もあります。

  • プロジェクトの項目の削除

  • ドキュメントの保存

  • プロジェクト プロパティの編集

  • 代替ビューでのプロジェクトの編集

  • ドラッグ アンド ドロップ操作

ドラッグ アンド ドロップの対話式操作モデル

通常、プロジェクトは、参照ベース (ストレージ内のプロジェクト項目への参照のみを保持できる)、ディレクトリベース (プロジェクトの階層内に物理的に格納されているプロジェクト項目のみを保持できる)、または混合 (参照または物理項目を保持できる) としてそれ自体が分類されます。 IDE では、ソリューション エクスプローラー内に 3 種類のプロジェクトすべてを同時に収容できます。

ドラッグ アンド ドロップの観点では、ソリューション エクスプローラー内のプロジェクトの種類ごとに次の特性が適用される必要があります。

  • 参照ベースのプロジェクト: 重要な点は、プロジェクトでストレージ内の項目への参照がドラッグされることです。 参照ベースのプロジェクトが移動操作のソースとして機能する場合は、プロジェクトから項目への参照のみが削除される必要があります。 項目をハード ドライブから実際に削除しないでください。 参照ベースのプロジェクトが移動 (またはコピー) 操作のターゲットとして機能する場合は、項目のプライベート コピーを作成せずに、元のソース項目への参照が追加される必要があります。

  • ディレクトリベースのプロジェクト: ドラッグ アンド ドロップの観点では、プロジェクトで参照ではなく物理的な項目がドラッグされます。 ディレクトリベースのプロジェクトが移動操作のソースとして機能する場合は、プロジェクトから項目が削除されるとともに、ハード ドライブから物理項目が削除される必要があります。 ディレクトリベースのプロジェクトが移動 (またはコピー) 操作のターゲットとして機能する場合は、ターゲットの場所にソース項目のコピーが作成される必要があります。

  • 混合ターゲット プロジェクト: ドラッグ アンド ドロップの観点では、この種類のプロジェクトの動作は、ドラッグされている項目の性質 (ストレージ内の項目への参照または項目自体) に基づいています。 参照と物理項目の正しい動作は、前述のとおりです。

ソリューション エクスプローラーにプロジェクトの種類が 1 つしかない場合は、ドラッグ アンド ドロップ操作が簡単になります。 各プロジェクト システムには独自のドラッグ アンド ドロップ動作を定義する機能があるため、(Windows エクスプローラーのドラッグ アンド ドロップ動作に基づく) 特定のガイドラインに従って、予測可能なユーザー エクスペリエンスにする必要があります。

  • ソリューション エクスプローラーでの変更されていないドラッグ操作 (Ctrl キーと Shift キーがどちらも押されていない場合) は、移動操作になる必要があります。

  • Shift + ドラッグ操作も、移動操作になる必要があります。

  • Ctrl + ドラッグ操作は、コピー操作になる必要があります。

  • 参照ベースと混合のプロジェクト システムでは、ソース項目へのリンク (または参照) を追加するという概念がサポートされています。 これらのプロジェクトがドラッグ アンド ドロップ操作のターゲットである場合 (Ctrl + Shift キーが押されている場合) は、項目への参照がプロジェクトに追加される必要があります

参照ベース、ディレクトリベース、混合の各プロジェクトの組み合わせでは、すべてのドラッグ アンド ドロップ操作が適切であるわけではありません。 特に、ソースのディレクトリベースのプロジェクトでは移動の完了時にソース項目が削除される必要があるため、ディレクトリベースのソース プロジェクトと参照ベースのターゲット プロジェクトの間の移動操作が可能であるように装うことは問題になります。 その後、ターゲットの参照ベースのプロジェクトでは、削除された項目への参照が保持されることになります。

また、ターゲットの参照ベースのプロジェクトではソース項目の独立したコピーを作成しない必要があるため、これらの種類のプロジェクト間でコピー操作が可能であるように装うことも誤解を招きます。 同様に、ディレクトリベースのプロジェクトでは参照を保持できないため、ディレクトリベースのターゲット プロジェクトに Ctrl + Shift でドラッグすることは許可しないようにする必要があります。 ドラッグ アンド ドロップ操作がサポートされていない場合、IDE では、ドロップが禁止され、ユーザーにドロップ不可カーソルが表示される必要があります (以下のポインターの表を参照してください)。

ドラッグ アンド ドロップ動作を適切に実装するには、ドラッグのソース プロジェクトによって、その性質がターゲット プロジェクトに伝えられる必要があります。 (たとえば、参照ベースとディレクトリベースのどちらであるか)。この情報は、ソースによって提供されるクリップボード形式によって示されます。 プロジェクトが参照ベースとディレクトリベースのどちらであるかに応じて、ドラッグ (またはクリップボードのコピー操作) のソースとして、プロジェクトによって CF_VSREFPROJECTITEMS または CF_VSSTGPROJECTITEMS のいずれかが提供される必要があります。 これらの形式はどちらも、同じデータ コンテンツを持っています。これは、ファイル名ではなく文字列のリストが、(必要に応じて IVsSolution::GetProjrefOfItem または ::GetProjrefOfProject から返される) Projref 文字列の 2 つの NULL で区切られたリストであることを除いて、Windows の CF_HDROP 形式に似ています。

ドロップ (またはクリップボードの貼り付け操作) のターゲットとして、プロジェクトでは CF_VSREFPROJECTITEMSCF_VSSTGPROJECTITEMS の両方が受け入れられる必要があります。ただし、ドラッグ アンド ドロップ操作の厳密な処理は、ターゲット プロジェクトとソース プロジェクトの性質によって異なります。 ソース プロジェクトでは、CF_VSREFPROJECTITEMS または CF_VSSTGPROJECTITEMS のどちらを提供するかによって、その性質を宣言します。 ドロップのターゲットでは独自の性質が理解されるため、移動、コピー、またはリンクのいずれを実行するかを決定するために十分な情報が得られます。 また、ユーザーは、Ctrl キー、Shift キー、または Ctrl キーと Shift キーの両方を押すことによって、実行されるドラッグ アンド ドロップ操作を変更します。 ドロップのターゲットでは、DragEnter および DragOver メソッドで事前に実行される操作を正しく指定することが重要です。 ソリューション エクスプローラーによって、ソース プロジェクトとターゲット プロジェクトが同じプロジェクトであるかどうかが自動的に認識されます。

Visual Studio のインスタンス間 (devenv.exe のインスタンス間など) でのプロジェクト項目のドラッグは、特にサポートされていません。 また、ソリューション エクスプローラーではこれが直接無効にされます。

ユーザーは、項目を選択してターゲットの場所にドラッグし、項目がドロップされる前に次のマウス ポインターのどれが表示されるかを確認することにより、ドラッグ アンド ドロップ操作の効果を常に判断できる必要があります。

Mouse pointer コマンド 説明
Mouse ドロップなし 項目は指定された場所にドロップできません。
Mouse コピー 項目はターゲットの場所にコピーされます。
Mouse 移動 項目はターゲットの場所に移動されます。
Mouse 参照の追加 選択した項目への参照が、ターゲットの場所に追加されます。

参照ベースのプロジェクト

次の表には、参照ベースのターゲット プロジェクトに対して押された修飾キーとソース項目の性質に基づいて実行される必要がある、ドラッグ アンド ドロップ (および切り取り/コピー/貼り付け) 操作が要約されています。

変更者 カテゴリ ソース項目: 参照/リンク ソース項目: 物理項目またはファイル システム (CF_HDROP)
修飾子なし アクション 移動 リンク
修飾子なし 移行先 元の項目への参照が追加されます 元の項目への参照が追加されます
修飾子なし ソース 元の項目への参照が削除されます 元の項目が保持されます
修飾子なし 結果 DROPEFFECT_MOVE::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります DROPEFFECT_LINK::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります
Shift + ドラッグ アクション 移動 ドロップなし
Shift + ドラッグ 移行先 元の項目への参照が追加されます ドロップなし
Shift + ドラッグ ソース 元の項目への参照が削除されます ドロップなし
Shift + ドラッグ 結果 DROPEFFECT_MOVE::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります ドロップなし
Ctrl + ドラッグ アクション コピー ドロップなし
Ctrl + ドラッグ 移行先 元の項目への参照が追加されます ドロップなし
Ctrl + ドラッグ ソース 元の項目への参照が保持されます ドロップなし
Ctrl + ドラッグ 結果 DROPEFFECT_COPY::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります ドロップなし
Ctrl + Shift + ドラッグ アクション リンク リンク
Ctrl + Shift + ドラッグ 移行先 元の項目への参照が追加されます 元の項目への参照が追加されます
Ctrl + Shift + ドラッグ ソース 元の項目への参照が保持されます 元の項目が保持されます
Ctrl + Shift + ドラッグ 結果 DROPEFFECT_LINK::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります DROPEFFECT_LINK::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります
Ctrl + Shift + ドラッグ Note エクスプローラーのショートカットのドラッグ アンド ドロップの動作と同じです。
切り取り/貼り付け アクション 移動 リンク
切り取り/貼り付け 移行先 元の項目への参照が追加されます 元の項目への参照が追加されます
切り取り/貼り付け ソース 元の項目への参照が保持されます 元の項目が保持されます
切り取り/貼り付け 結果 項目はストレージ内の元の場所に残ります 項目はストレージ内の元の場所に残ります
コピー/貼り付け アクション コピー リンク
コピー/貼り付け ソース 元の項目への参照が追加されます 元の項目への参照が追加されます
コピー/貼り付け 結果 元の項目への参照が保持されます 元の項目が保持されます
コピー/貼り付け アクション 項目はストレージ内の元の場所に残ります 項目はストレージ内の元の場所に残ります

ディレクトリベースのプロジェクト

次の表には、ディレクトリベースのターゲット プロジェクトに対して押された修飾キーとソース項目の性質に基づいて実行される必要がある、ドラッグ アンド ドロップ (および切り取り/コピー/貼り付け) 操作が要約されています。

変更者 カテゴリ ソース項目: 参照/リンク ソース項目: 物理項目またはファイル システム (CF_HDROP)
修飾子なし アクション 移動 移動
修飾子なし 移行先 項目がターゲットの場所にコピーされます 項目がターゲットの場所にコピーされます
修飾子なし ソース 元の項目への参照が削除されます 元の項目への参照が削除されます
Shift + ドラッグ アクション 移動 移動
Shift + ドラッグ 移行先 項目がターゲットの場所にコピーされます 項目がターゲットの場所にコピーされます
Shift + ドラッグ ソース 元の項目への参照が削除されます 元の場所から項目が削除されます
Shift + ドラッグ 結果 DROPEFFECT_MOVE::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります DROPEFFECT_MOVE::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります
Ctrl + ドラッグ アクション コピー コピー
Ctrl + ドラッグ 移行先 項目がターゲットの場所にコピーされます 項目がターゲットの場所にコピーされます
Ctrl + ドラッグ ソース 元の項目への参照が保持されます 元の項目への参照が保持されます
Ctrl + ドラッグ 結果 DROPEFFECT_COPY::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります DROPEFFECT_COPY::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります
Ctrl + Shift + ドラッグ ドロップなし ドロップなし
切り取り/貼り付け アクション 移動 移動
切り取り/貼り付け 移行先 項目がターゲットの場所にコピーされます 項目がターゲットの場所にコピーされます
切り取り/貼り付け ソース 元の項目への参照が削除されます 元の場所から項目が削除されます
切り取り/貼り付け 結果 項目はストレージ内の元の場所に残ります ストレージ内の元の場所から項目が削除されます
コピー/貼り付け アクション コピー コピー
コピー/貼り付け 移行先 元の項目への参照が追加されます 項目がターゲットの場所にコピーされます
コピー/貼り付け ソース 元の項目が保持されます 元の項目が保持されます
コピー/貼り付け 結果 項目はストレージ内の元の場所に残ります 項目はストレージ内の元の場所に残ります

混合ターゲット プロジェクト

次の表には、混合ターゲット プロジェクトに対して押された修飾キーとソース項目の性質に基づいて実行される必要がある、ドラッグ アンド ドロップ (および切り取り/コピー/貼り付け) 操作が要約されています。

変更者 カテゴリ ソース項目: 参照/リンク ソース項目: 物理項目またはファイル システム (CF_HDROP)
修飾子なし アクション 移動 移動
修飾子なし 移行先 元の項目への参照が追加されます 項目がターゲットの場所にコピーされます
修飾子なし ソース 元の項目への参照が削除されます 元の項目への参照が削除されます
修飾子なし 結果 DROPEFFECT_ MOVE::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります DROPEFFECT_ MOVE::Drop からアクションとして返され、ストレージ内の元の場所から項目が削除されます
Shift + ドラッグ アクション 移動 移動
Shift + ドラッグ 移行先 元の項目への参照が追加されます 項目がターゲットの場所にコピーされます
Shift + ドラッグ ソース 元の項目への参照が削除されます 元の場所から項目が削除されます
Shift + ドラッグ 結果 DROPEFFECT_ MOVE::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります DROPEFFECT_ MOVE::Drop からアクションとして返され、ストレージ内の元の場所から項目が削除されます
Ctrl + ドラッグ アクション コピー コピー
Ctrl + ドラッグ 移行先 元の項目への参照が追加されます 項目がターゲットの場所にコピーされます
Ctrl + ドラッグ ソース 元の項目への参照が保持されます 元の項目が保持されます
Ctrl + ドラッグ 結果 DROPEFFECT_ COPY::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります DROPEFFECT_ COPY::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります
Ctrl + Shift + ドラッグ アクション リンク リンク
Ctrl + Shift + ドラッグ 移行先 元の項目への参照が追加されます 元のソース項目への参照が追加されます
Ctrl + Shift + ドラッグ ソース 元の項目への参照が保持されます 元の項目が保持されます
Ctrl + Shift + ドラッグ 結果 DROPEFFECT_ LINK::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります DROPEFFECT_ LINK::Drop からアクションとして返され、項目はストレージ内の元の場所に残ります
切り取り/貼り付け アクション 移動 移動
切り取り/貼り付け 移行先 項目がターゲットの場所にコピーされます 項目がターゲットの場所にコピーされます
切り取り/貼り付け ソース 元の項目への参照が削除されます 元の場所から項目が削除されます
切り取り/貼り付け 結果 項目はストレージ内の元の場所に残ります ストレージ内の元の場所から項目が削除されます
コピー/貼り付け アクション コピー コピー
コピー/貼り付け 移行先 元の項目への参照が追加されます 項目がターゲットの場所にコピーされます
コピー/貼り付け ソース 元の項目が保持されます 元の項目が保持されます
コピー/貼り付け 結果 項目はストレージ内の元の場所に残ります 項目はストレージ内の元の場所に残ります

ソリューション エクスプローラーにドラッグを実装するときは、次の詳細について考慮する必要があります。

  • 複数選択のシナリオのための設計。

  • ファイル名 (完全なパス) はターゲット プロジェクト全体で一意である必要があります。それ以外の場合は、ドロップを許可しないでください。

  • フォルダー名は、削除されるレベルで一意である必要があります (大文字と小文字は区別されません)。

  • ドラッグ時にファイルを開いていたか閉じていたかによって、動作の違いがあります (上記のシナリオでは説明されていません)。

  • 最上位レベルのファイルの動作は、フォルダー内のファイルと若干異なります。

他に注意が必要な問題は、デザイナーまたはエディターで開いている項目に対する移動操作を処理する方法です。 想定される動作は次のとおりです (これはすべてのプロジェクトの種類に適用されます)。

  1. 開いているエディター/デザイナーに保存されていない変更がない場合は、エディター/デザイナーのウィンドウがメッセージなしで閉じられます。

  2. 開いているエディター/デザイナーに保存されていない変更がある場合、ドラッグのソースではドロップが発生するまで待機し、ウィンドウを閉じる前に次のようなプロンプトで、開いているドキュメントのコミットされていない変更を保存するようにユーザーに要請します。

    ==========================================================
         One or more open documents have unsaved changes.
    Do you want to save uncommitted changes before proceeding?
                      [Yes]  [No]  [Cancel]
    ==========================================================
    

これにより、ターゲットでコピーが作成される前に、ユーザーが進行中の作業を保存できます。 この処理を可能にする新しいメソッド IVsHierarchyDropDataSource2::OnBeforeDropNotify が追加されました。

その後、ターゲットでは、ストレージ内と同じ状態の項目がコピーされます (ユーザーが [いいえ] を選択した場合、エディターの保存されていない変更は含まれません)。 ターゲットでコピーが完了すると (IVsHierarchyDropDataSource::Drop で)、ソースで移動操作の削除部分を完了できるようになります (IVsHierarchyDropDataSource::OnDropNotify で)。

保存されていない変更があるエディターは、開いたままにしておく必要があります。 保存されていない変更があるドキュメントの場合、これは移動操作のコピー部分は実行されますが、削除部分は中止されることを意味します。 ユーザーが [いいえ] を選択した場合の複数選択のシナリオでは、保存されていない変更のあるドキュメントを閉じたり削除したりしない必要がありますが、保存されていない変更のないドキュメントは閉じて削除する必要があります。