Patrones de aplicación para Visual Studio

Window interactions

Los dos tipos de ventana principales que se usan en Visual Studio son editores de documentos y ventanas de herramientas. Raras, pero posibles, son cuadros de diálogo de modelos grandes. Aunque todos estos son modelos en el shell, sus patrones son fundamentalmente diferentes. En esta sección se trata la diferencia entre las ventanas de documento, las ventanas de herramientas y los cuadros de diálogo modeless. Modal dialog patterns are covered in Dialogs.

Comparación de patrones de uso de ventanas

Document windows are almost always displayed within the document well. Esto proporciona al editor de documentos una "fase central" para organizar ventanas de herramientas complementarias alrededor.

A tool window is most often displayed as a separate, smaller window collapsed against the edge of the IDE. Esto puede ser visible, oculto o oculto automáticamente. However, sometimes tool windows are presented within the document well, by unchecking the Window/Docking property on the window. Esto da como resultado más bienes raíces, pero también una decisión de diseño común: al intentar integrar en Visual Studio, debe decidir si la característica debe mostrar una ventana de herramientas o una ventana de documento.

Modeless dialogs are discouraged in Visual Studio. La mayoría de los diálogos de modelos son, por definición, ventanas de herramientas flotantes y deben implementarse de esa manera. Los cuadros de diálogo modeless se permiten en los casos en los que el tamaño de una ventana de herramientas normal acoplada al lado del shell sería demasiado limitado. También se permiten en los casos en los que es probable que el usuario mueva el cuadro de diálogo a un monitor secundario.

Piense detenidamente en qué tipo de contenedor necesita. Las consideraciones de patrón de uso comunes para el diseño de la interfaz de usuario se encuentran en la tabla siguiente.

	Document window	Tool window	Modeless dialog
Position	Siempre se coloca dentro del área del documento y no se acopla alrededor de los bordes del IDE. Se puede "extraer" para que flota por separado del shell principal.	Por lo general, acoplado con tabulación alrededor de los bordes del IDE, pero se puede personalizar para que esté flotante, oculto automáticamente (desanclar) o acoplado dentro del área del documento.	Ventana flotante grande independiente del IDE.
Commit model	Delayed commit Para guardar los datos en un documento, el usuario debe emitir el comando Guardar >archivo, Guardar como o Guardar todo. Una ventana de documento tiene el concepto de los datos dentro de que se "sucia" y, a continuación, se confirma en uno de los comandos save. Al cerrar una ventana de documento, todo el contenido se guarda en el disco o se pierde.	Immediate commit No hay ningún modelo de guardado. En el caso de las ventanas de herramientas del inspector que ayudan a editar un archivo, el archivo debe estar abierto en el editor o diseñador activo y el editor o diseñador posee el guardado.	Confirmación diferida o inmediata A menudo, un cuadro de diálogo de modelos grandes requiere una acción para confirmar cambios y permite una operación "Cancelar", que revierte los cambios realizados en la sesión de diálogo. Esto diferencia un cuadro de diálogo modela de una ventana de herramientas de esa ventana de herramientas siempre tiene un modelo de confirmación inmediata.
Visibility	Abrir o crear (archivo) y Cerrar Al abrir una ventana de documento, se abre un documento existente o se usa una plantilla para crear un nuevo documento. No hay ningún comando "Abrir <editor> específico".	Ocultar y mostrar Las ventanas de herramientas de instancia única se pueden ocultar o mostrar. El contenido y los estados de la ventana de herramientas persisten en la vista u oculta. Las ventanas de herramientas de varias instancias se pueden cerrar, así como ocultarlas. Cuando se cierra una ventana de herramientas de varias instancias, se descarta el contenido y el estado de la ventana de herramientas.	Se inicia desde un comando Los diálogos se inician desde un comando basado en tareas.
Instances	Multi-instance Se pueden abrir varios editores al mismo tiempo y editar archivos diferentes, mientras que algunos editores también permiten que el mismo archivo esté abierto en más de un editor (con el comando Ventana nueva ventana>). Un único editor puede editar uno o varios archivos al mismo tiempo (Diseñador de proyectos).	Instancia única o múltiple El contenido cambia para reflejar el contexto (como en el Explorador de propiedades) o insertar el foco o el contexto en otras ventanas (Lista de tareas, Explorador de soluciones). Tanto las ventanas de herramientas de instancia única como las de varias instancias deben asociarse a la ventana del documento activo, a menos que haya una razón convincente para no hacerlo.	Single-instance
Examples	Text editors, like the code editor Design surfaces, like a form designer or a modeling surface Diseños de control similares a los cuadros de diálogo, como el Diseñador de manifiestos	The Solution Explorer provides a solution and projects contained within the solution The Server Explorer provides a hierarchical view of servers and data connections that the user chooses to open in the window. Al abrir un objeto desde la jerarquía de bases de datos, como una consulta, se abre una ventana de documento y se permite al usuario editar la consulta. The Property Browser displays properties for the object selected either in a document window or another tool window. Las propiedades se presentan en una vista de cuadrícula jerárquica o en controles complejos de tipo diálogo y permiten al usuario establecer los valores de esas propiedades.

Tool windows

Las ventanas de herramientas admiten el trabajo del usuario que se produce en las ventanas del documento. Se pueden usar para mostrar una jerarquía que representa un objeto raíz fundamental que Visual Studio proporciona y puede manipular.

Al considerar una nueva ventana de herramientas en el IDE, los autores deben:

• Use las ventanas de herramientas existentes adecuadas para tareas y no cree otras nuevas con una funcionalidad similar. Las nuevas ventanas de herramientas solo deben crearse si ofrecen una funcionalidad o "herramienta" significativamente diferente que no se puede integrar en una ventana similar o convirtiendo una ventana existente en un centro de pivoting.

• Use una barra de comandos estándar, si es necesario, en la parte superior de la ventana de herramientas.

• Sea coherente con los patrones que ya están presentes en otras ventanas de herramientas para la presentación de control y la navegación mediante teclado.

• Sea coherente con la presentación de control en otras ventanas de herramientas.

• Haga que las ventanas de herramientas específicas del documento sean visibles automáticamente cuando sea posible, de modo que solo aparezcan cuando se active el documento primario.

• Asegúrese de que el teclado pueda navegar por el contenido de la ventana (admita teclas de dirección).

Estados de la ventana de herramientas

Las ventanas de herramientas de Visual Studio tienen diferentes estados, algunos de los cuales están activados por el usuario (como la característica de ocultación automática). Otros estados, como visibles automáticamente, permiten que las ventanas de herramientas aparezcan en el contexto correcto y oculten cuando no sea necesario. Hay cinco estados de ventana de herramientas en total.

• Docked/pinned tool windows can be attached to any of the four sides of the document area. El icono de marcadores aparece en la barra de título de la ventana de herramientas. La ventana de herramientas se puede acoplar horizontal o verticalmente a lo largo del borde del shell y otras ventanas de herramientas, y también puede estar vinculada a pestañas.

• Auto-hidden tool windows are unpinned. La ventana puede deslizarse fuera de la vista, dejando una pestaña (con el nombre de la ventana de herramientas y su icono) en el borde del área del documento. La ventana de herramientas se desliza cuando un usuario mantiene el puntero sobre la pestaña.

• Auto-visible tool windows automatically appear when another piece of UI, like an editor, is launched or gains focus.

• Floating tool windows hover outside the IDE. Esto es útil para las configuraciones de varios monitores.

• Tabbed document tool windows can be docked within the document well. Esto es útil para ventanas de herramientas grandes, como el Examinador de objetos, que necesitan más bienes raíces que acoplarse a los bordes del marco permite.

Estados de ventana de herramientas en Visual Studio

Instancia única e instancia múltiple

Las ventanas de herramientas son de instancia única o de varias instancias. Es posible que algunas ventanas de herramientas de instancia única estén asociadas a la ventana del documento activo, mientras que es posible que las ventanas de herramientas de varias instancias no. Las ventanas de herramientas de varias instancias responden al comando Ventana nueva ventana > mediante la creación de una nueva instancia de la ventana. En la imagen siguiente se muestra una ventana de herramientas que habilita el comando Nueva ventana cuando una instancia de la ventana está activa:

Ventana de herramientas que habilita el comando "Nueva ventana" cuando una instancia de la ventana está activa

Las ventanas de herramientas de instancia única se pueden ocultar o mostrar, mientras que las ventanas de herramientas de varias instancias se pueden cerrar, así como ocultarse. Todas las ventanas de herramientas se pueden acoplar, vincular con pestañas, flotantes o establecerse como una ventana secundaria de interfaz de Multiple-Document (MDI) (similar a una ventana de documento). Todas las ventanas de herramientas deben responder a los comandos de administración de ventanas adecuados en el menú Ventana:

Comandos de administración de ventanas en el menú Ventana de Visual Studio

Ventanas de herramientas específicas del documento

Algunas ventanas de herramientas están diseñadas para cambiar en función de un tipo determinado de documento. Estas ventanas se actualizan continuamente para reflejar la funcionalidad aplicable a la ventana del documento activo en el IDE.

Ejemplos de ventanas de herramientas cuyo contenido cambia para reflejar el editor seleccionado son el Cuadro de herramientas y el Esquema del documento. Estas ventanas muestran una marca de agua cuando un editor tiene el foco que no ofrece contexto a la ventana.

Ventanas de herramientas de lista navegables

Algunas ventanas de herramientas muestran una lista de elementos navegables con los que el usuario puede interactuar. En este tipo de ventana, siempre debe haber comentarios para el elemento actual de la lista, incluso si la ventana está inactiva. The list should respond to the GoToNextLocation and GoToPrevLocation commands by also changing the currently selected item in the window

Algunos ejemplos de ventanas de herramientas de lista navegables son el Explorador de soluciones y la ventana Resultados de búsqueda.

Tipos de ventana de herramientas

Ventanas de herramientas comunes y sus funciones

Ventanas de herramientas jerárquicas

Tool window	Function
Solution Explorer	Árbol jerárquico que muestra una lista de documentos contenidos en proyectos, archivos varios y elementos de solución. La presentación de los elementos de los proyectos se define mediante el paquete que posee el tipo de proyecto (por ejemplo, tipos basados en referencia, basados en directorios o en modo mixto).
Class View	Árbol jerárquico de las clases y varios elementos del conjunto de trabajo de documentos, independientemente de los propios archivos.
Server Explorer	Árbol jerárquico que muestra todos los servidores y conexiones de datos de la solución.
Document Outline	Estructura jerárquica del documento activo.

Ventanas de herramientas de cuadrícula

Tool window	Function
Properties	Cuadrícula que muestra una lista de propiedades para el objeto seleccionado, junto con selectores de valores para editar esas propiedades.
Task List	Cuadrícula que permite al usuario crear, editar o eliminar tareas y comentarios.

Ventanas de herramientas de contenido

Tool window	Function
Help	Una ventana que permite a los usuarios acceder a varios métodos de ayuda, desde vídeos de "¿Cómo puedo?" a foros de MSDN.
Dynamic Help	Ventana de herramientas que muestra vínculos a temas de ayuda aplicables a la selección actual.
Object Browser	Conjunto de marcos de dos columnas con una lista de componentes de objeto jerárquicos en el panel izquierdo y las propiedades y métodos del objeto en la columna derecha.

Ventanas de herramientas de diálogo

Tool window	Function
Find	Cuadro de diálogo que permite al usuario buscar o buscar y reemplazar en varios archivos de la solución.
Advanced Find	Cuadro de diálogo que permite al usuario buscar o buscar y reemplazar en varios archivos de la solución.

Otras ventanas de herramientas

Tool window	Function
Toolbox	Ventana de herramientas usada para almacenar elementos que se colocarán en superficies de diseño, lo que proporciona un origen de arrastre coherente para todos los diseñadores.

Ventanas de herramientas del depurador

Tool window	Function
Autos
Immediate
Output	La ventana de salida se puede usar siempre que tenga eventos de texto o estado para declarar.
Memory
Breakpoints
Running
Documents
Call Stack
Locals
Watches
Disassembly
Registers
Threads

Convenciones del editor de documentos

Document interactions

El "documento bien" es el espacio más grande dentro del IDE y es donde el usuario generalmente ha centrado su atención para completar sus tareas, asistido por ventanas de herramientas complementarias. Los editores de documentos representan las unidades de trabajo fundamentales que el usuario abre y guarda en Visual Studio. Conservan una gran sensación de selección vinculada al Explorador de soluciones u otras ventanas de jerarquía activa. El usuario debe poder apuntar a una de esas ventanas de jerarquía y saber dónde se encuentra el documento y su relación con la solución, el proyecto u otro objeto raíz proporcionado por un paquete de Visual Studio.

La edición de documentos requiere una experiencia de usuario coherente. Para permitir al usuario centrarse en la tarea en lugar de en la administración de ventanas y buscar comandos, seleccione una estrategia de vista de documento que mejor se adapte a las tareas del usuario para editar ese tipo de documento.

Interacciones comunes para el área del documento

• Maintain a consistent interaction model in the common New File and Open File experiences.

• Actualice la funcionalidad relacionada en ventanas y menús relacionados cuando se abra la ventana del documento.

• Menu commands are appropriately integrated into common menus like Edit, Format, and View menus. Si hay disponible una cantidad considerable de comandos especializados, se puede crear un nuevo menú. Este nuevo menú solo debe estar visible cuando el documento tenga el foco.

• Se puede colocar una barra de herramientas incrustada en la parte superior del editor. Es preferible tener una barra de herramientas independiente que aparezca fuera del editor.

• Mantenga siempre una selección en el Explorador de soluciones o en una ventana de jerarquía activa similar.

• Double-clicking a document in the Solution Explorer should perform the same action as Open.

• If more than one editor can be used on a document type, the user should be able to override or reset the default action on a given document type using the Open With dialog box by right-clicking on the file and selecting Open With from the shortcut menu.

• No cree un asistente en un documento bien.

Expectativas del usuario para tipos de documentos específicos

Hay varios tipos básicos diferentes de editores de documentos y cada uno tiene un conjunto de interacciones que son coherentes con otros del mismo tipo.

• Text-based editor: code editor, log files

• Design surface: WPF forms designer, Windows forms

• Dialog-style editor: Manifest Designer, project properties

• Model designer: workflow designer, codemap, architecture diagram, progression

También hay varios tipos que no son editores que usan el área del documento. Aunque no editan los documentos por sí mismos, deben seguir las interacciones estándar para las ventanas de documentos.

• Reports: IntelliTrace report, Hyper-V report, profiler report

• Dashboard: Diagnostics Hub

Text-based editors

• El documento participa en el modelo de pestañas de vista previa, lo que permite obtener una vista previa del documento sin abrirlo.

• La estructura del documento se puede representar dentro de una ventana de herramientas complementaria, como un esquema del documento.

• IntelliSense (si procede) se comportará de forma coherente con otros editores de código.

• Los elementos emergentes o la interfaz de usuario de asistencia siguen estilos y patrones similares para la interfaz de usuario similar existente, como CodeLens.

• Los mensajes relacionados con el estado del documento se mostrarán en un control de barra de información en la parte superior del documento o en la barra de estado.

• El usuario debe poder personalizar la apariencia de las fuentes y los colores mediante una página Opciones de herramientas>, ya sea la página Fuentes y colores compartidas o una específica del editor.

Design surfaces

• Un diseñador vacío debe tener una marca de agua en la superficie que indica cómo empezar.

• Los mecanismos de cambio de vista seguirán los patrones existentes, como hacer doble clic para abrir un editor de código o pestañas dentro de la ventana del documento, lo que permite la interacción con ambos paneles.

• La adición de elementos a la superficie de diseño debe realizarse a través del Cuadro de herramientas, a menos que se requiera una ventana de herramientas muy específica.

• Los elementos de la superficie seguirán un modelo de selección coherente.

• Embedded toolbars contain document-specific commands only, not common commands such as Save.

Dialog-style editors

• El diseño del control debe seguir las convenciones de diseño de diálogo normales.

• Las pestañas dentro del editor no deben coincidir con la apariencia de las pestañas del documento, deben coincidir con uno de los dos estilos de pestaña interior permitidos.

• Los usuarios deben poder interactuar con los controles usando solo el teclado; activando el editor y el tabulador a través de controles o mediante mnemonics estándar.

• El diseñador debe usar el modelo Save común. No se debe colocar ningún botón general Guardar o confirmar en la superficie, aunque otros botones pueden ser adecuados.

Model designers

• Un diseñador vacío debe tener una marca de agua en la superficie que indica cómo empezar.

• La adición de elementos a la superficie de diseño debe realizarse a través del Cuadro de herramientas.

• Los elementos de la superficie seguirán un modelo de selección coherente.

• Embedded toolbars contain document-specific commands only, not common commands such as Save.

• Una leyenda puede aparecer en la superficie, ya sea indicativo o una marca de agua.

• El usuario debe poder personalizar la apariencia de las fuentes o colores mediante una página Opciones de herramientas>, ya sea la página Fuentes y colores compartidas o una específica del editor.

Reports

• Los informes suelen ser de solo información y no participan en el modelo Save. Sin embargo, pueden incluir interacción como vínculos a otra información o secciones relevantes que expandan y contraen.

• La mayoría de los comandos de la superficie deben ser hipervínculos, no botones.

• El diseño debe incluir un encabezado y seguir las directrices de diseño de informe estándar.

Dashboards

• Los paneles no tienen un modelo de interacción, pero sirven como medio para ofrecer una variedad de otras herramientas.

• No participan en el modelo Save.

• Los usuarios deben poder interactuar con los controles usando solo el teclado, ya sea activando el editor y la tabulación a través de controles o mediante mnemonics estándar.

Dialogs

Introduction

Los diálogos de Visual Studio normalmente deben admitir una unidad discreta del trabajo del usuario y, a continuación, descartarse.

Si ha determinado que necesita un cuadro de diálogo, tiene tres opciones, en orden de preferencia:

1. Integre las características en uno de los diálogos compartidos de Visual Studio.

2. Cree su propio cuadro de diálogo con un patrón que se encuentra en un cuadro de diálogo similar existente.

3. Cree un cuadro de diálogo, siguiendo las instrucciones de interacción y diseño.

En esta sección se describe cómo elegir el patrón de diálogo correcto en los flujos de trabajo de Visual Studio y las convenciones comunes para el diseño del cuadro de diálogo.

Themes

Los diálogos de Visual Studio siguen uno de los dos estilos básicos:

Standard (unthemed)

La mayoría de los diálogos son cuadros de diálogo de utilidad estándar y deben estar incontenibles. No vuelva a crear controles comunes o intente crear controles o botones "modernos" estilizados. Los controles y la apariencia del cromo siguen las directrices estándar de interacción del escritorio de Windows para los cuadros de diálogo.

Themed

Los cuadros de diálogo de "firma" especiales pueden ser temáticas. Los diálogos con temática tienen una apariencia distinta, que también tiene algunos patrones de interacción especiales asociados al estilo. Tema el cuadro de diálogo solo si cumple estos requisitos:

• The dialog is a common experience that will be seen and used often or by many users (for example, the New Project dialog.

• The dialog contains prominent product brand elements (for example, the Account Settings dialog).

• El cuadro de diálogo aparece como parte integral de un flujo mayor que incluye otros diálogos con temáticas (por ejemplo, el cuadro de diálogo Agregar servicio conectado ).

• El cuadro de diálogo es una parte importante de una experiencia que desempeña un papel estratégico en la promoción o diferenciación de una versión del producto.

Al crear un cuadro de diálogo con temas, use los colores de entorno adecuados y siga los patrones correctos de diseño e interacción. (Consulte Diseño para Visual Studio).

Dialog design

Los diálogos bien diseñados tienen en cuenta los siguientes elementos:

• Tarea de usuario que se admite

• Estilo de texto del cuadro de diálogo, idioma y terminología

• Convenciones de interfaz de usuario y opciones de control

• Especificación de diseño visual y alineación del control

• Keyboard access

Content organization

Tenga en cuenta las diferencias entre estos tipos básicos de diálogos:

• Simple dialogs present controls in a single modal window. La presentación puede incluir variaciones de patrones de control complejos, incluido un selector de campos o una barra de iconos.

• Layered dialogs are used to make the most of screen real estate when a single piece of UI comprises multiple groups of controls. Las agrupaciones del cuadro de diálogo se "superponen" a través de controles de pestaña, controles de lista de navegación o botones para que el usuario pueda elegir qué agrupación ver en cualquier momento dado.

• Wizards are useful for directing the user through a logical sequence of steps toward the completion of a task. Se ofrecen una serie de opciones en paneles secuenciales, que a veces presentan flujos de trabajo diferentes ("ramas") que dependen de una elección realizada en el panel anterior.

Simple dialogs

Un cuadro de diálogo simple es una presentación de controles en una sola ventana modal. Esta presentación puede incluir variaciones de patrones de control complejos, como un selector de campos. Para cuadros de diálogo simples, siga el diseño general estándar, así como cualquier diseño específico necesario para agrupaciones de controles complejos.

Crear clave de nombre seguro es un ejemplo de un cuadro de diálogo sencillo en Visual Studio.

Layered dialogs

Los diálogos en capas incluyen pestañas, paneles y árboles incrustados. Se usan para maximizar el patrimonio cuando hay varios grupos de controles ofrecidos en una sola parte de la interfaz de usuario. Las agrupaciones están superpuestas para que el usuario pueda elegir qué agrupación ver en cualquier momento.

En el caso más sencillo, el mecanismo para cambiar entre agrupaciones es un control tab. Hay varias alternativas disponibles. Consulte Priorización y capas para saber cómo elegir el estilo más adecuado.

El cuadro de diálogo Opciones de herramientas > es un ejemplo de un diálogo en capas mediante un árbol incrustado:

Opciones de herramientas > es un ejemplo de un cuadro de diálogo en capas en Visual Studio.

Wizards

Los asistentes son útiles para dirigir al usuario a través de una secuencia lógica de pasos en la finalización de una tarea. Se ofrecen una serie de opciones en paneles secuenciales y el usuario debe continuar cada paso antes de continuar con el siguiente paso. Once sufficient defaults are available, the Finish button is enabled.

Los asistentes modales se usan para tareas que:

• Contienen bifurcaciones, donde se ofrecen diferentes rutas de acceso en función de las opciones del usuario.

• Contienen dependencias entre pasos, donde los pasos posteriores dependen de la entrada del usuario de los pasos anteriores.

• Son lo suficientemente complejos que la interfaz de usuario debe usarse para explicar las opciones que se ofrecen y los posibles resultados en cada paso.

• Son transaccionales, lo que requiere que se complete un conjunto de pasos en su totalidad antes de que se confirmen los cambios.

Common conventions

Para lograr un diseño y una funcionalidad óptimos con los diálogos, siga estas convenciones en tamaño, posición, estándares, configuración y alineación del control, texto de la interfaz de usuario, barras de título, botones de control y teclas de acceso.

Para obtener instrucciones específicas del diseño, consulte Diseño para Visual Studio.

Size

Los diálogos deben caber en una resolución de pantalla mínima de 1024x768 y el tamaño del cuadro de diálogo inicial no debe superar los 900 x 700 píxeles. Los cuadros de diálogo pueden ser redimensionables, pero no es un requisito.

Hay dos recomendaciones para los cuadros de diálogo redimensionables:

1. Ese tamaño mínimo es un definido para el cuadro de diálogo que optimizará el conjunto de controles sin recorte y se ajustará para dar cabida al crecimiento razonable de la localización.

2. Que el tamaño escalado por el usuario persiste de la sesión a la sesión. Por ejemplo, si el usuario escala un cuadro de diálogo a 150%, se mostrará un inicio posterior del cuadro de diálogo en 150%.

Position

Los cuadros de diálogo deben aparecer centrados en el IDE en el primer inicio. No es necesario conservar la última posición de los cuadros de diálogo que no se pueden cambiar de tamaño, por lo que aparecerán centrados en los lanzamientos posteriores.

Para los cuadros de diálogo que se pueden cambiar de tamaño, el tamaño debe conservarse en los inicios posteriores. Para los cuadros de diálogo modales que se pueden cambiar de tamaño, no es necesario conservar la posición. Mostrarlos centrados en el IDE impide la posibilidad de que el cuadro de diálogo aparezca en una posición impredecible o inutilizable cuando la configuración de visualización del usuario haya cambiado.

En el caso de los cuadros de diálogo modelados que se pueden cambiar de posición, la posición del usuario debe mantenerse en los inicios posteriores, ya que el cuadro de diálogo puede usarse con frecuencia como parte integral de un flujo de trabajo mayor.

Cuando los diálogos deben generar otros diálogos, el diálogo más alto debe estar en cascada hacia la derecha y hacia abajo desde el elemento primario para que sea obvio para el usuario que ha navegado a un nuevo lugar.

Modality

Ser modal significa que los usuarios deben completar o cancelar el cuadro de diálogo antes de continuar. Dado que los diálogos modales impiden que el usuario interactúe con otras partes del entorno, el flujo de tareas de la característica debe usarlos con moderación posible. Cuando se necesita una operación modal, Visual Studio tiene varios diálogos compartidos en los que puede integrar las características. Si debe crear un cuadro de diálogo, siga el patrón de interacción de un diálogo existente con una funcionalidad similar.

When users need to perform two activities at once, like Find and Replace while writing new code, the dialog should be modeless so that the user can easily switch between them. Visual Studio suele usar ventanas de herramientas para este tipo de tareas vinculadas compatibles con el editor.

Control configuration

Sea coherente con las configuraciones de control existentes que logren lo mismo en Visual Studio.

Title bars

• El texto de la barra de título debe reflejar el nombre del comando que lo inició.

• No se debe usar ningún icono en las barras de título del cuadro de diálogo. En los casos en los que el sistema requiere uno, use el logotipo de Visual Studio.

• Los diálogos no deben tener botones minimizar ni maximizar.

• Los botones de ayuda de la barra de título han quedado en desuso. No los agregue a nuevos diálogos. Cuando existen, deben iniciar un tema de Ayuda que sea conceptualmente relevante para la tarea.

  
  Especificaciones de directrices para las barras de título en cuadros de diálogo de Visual Studio

Control buttons

In general, OK, Cancel, and Help buttons should be arranged horizontally in the lower right corner of the dialog. Se permite la pila vertical alternativa si un cuadro de diálogo tiene otros botones en la parte inferior del diálogo que presentarían confusión visual con los botones de control.

Configuraciones aceptables para botones de control en cuadros de diálogo de Visual Studio

El cuadro de diálogo debe incluir un botón de control predeterminado. This is a button that is invoked by pressing the Enter key - see Button IsDefault .To determine the best command to use as the default, choose from the following options (listed in order of precedence):

• Elija el comando más seguro y seguro como predeterminado. Esto significa elegir el comando con más probabilidades de evitar la pérdida de datos y evitar el acceso al sistema no deseado.

• Si la pérdida de datos y la seguridad no son factores, elija el comando predeterminado en función de la comodidad. Incluir el comando más probable como valor predeterminado mejorará el flujo de trabajo del usuario cuando el cuadro de diálogo admita tareas frecuentes o repetitivas.

Evite elegir una acción destructiva permanente para el comando predeterminado. Si este comando está presente, elija un comando más seguro como predeterminado en su lugar.

Access keys

Do not use access keys for OK or Cancel. Enter and Escape shortcuts can be set with Button IsDefault and Button IsCancel respectively.

Imagery

Use imágenes con moderación en los cuadros de diálogo. No use iconos grandes en cuadros de diálogo simplemente para usar espacio. Use imágenes solo si son una parte importante de transmitir el mensaje al usuario, como iconos de advertencia o animaciones de estado.

Priorización y capas

Priorización de la interfaz de usuario

Es posible que sea necesario llevar determinados elementos de interfaz de usuario a la vanguardia y colocar opciones y comportamientos más avanzados (incluidos comandos ocultos) en cuadros de diálogo. Incorpore la funcionalidad usada habitualmente a la vanguardia haciendo espacio para ella y haciendo que sea visible de forma predeterminada en la interfaz de usuario con una etiqueta de texto cuando se muestra el cuadro de diálogo.

Capas de la interfaz de usuario

Si ha determinado que un cuadro de diálogo es necesario, pero la funcionalidad relacionada que desea presentar al usuario va más allá de lo que se puede mostrar en un cuadro de diálogo simple, debe superponer la interfaz de usuario. Los métodos de capas más comunes que usa Visual Studio son pestañas y pasillos o paneles. En algunos casos, las regiones que pueden expandirse y contraer pueden ser adecuadas. Por lo general, no se recomienda la interfaz de usuario adaptable en Visual Studio.

Hay ventajas y desventajas en diferentes métodos de capas de la interfaz de usuario a través de controles de pestañas. Revise la lista siguiente para asegurarse de que elige una técnica de capas adecuada para su situación.

Tabbing

Switching mechanism	Ventajas y uso adecuado	Desventajas y uso inadecuado
Tab control	Agrupar lógicamente las páginas de diálogo en conjuntos relacionados Útil para menos de cinco (o el número de pestañas que caben en una fila en las páginas del cuadro de diálogo) de controles relacionados en el cuadro de diálogo Las etiquetas de tabulación deben ser cortas: una o dos palabras que puedan identificar fácilmente el contenido. Un estilo de diálogo del sistema común Ejemplo: Propiedades del elemento del Explorador > de archivos	La creación de etiquetas cortas descriptivas puede ser difícil Por lo general, no escala más de cinco pestañas en un cuadro de diálogo Inapropiado si tiene demasiadas pestañas para una fila (use una técnica de capas alternativa) Not extensible
Sidebar navigation	Dispositivo de conmutación simple que puede acomodar más categorías que pestañas Lista plana de categorías (sin jerarquía) Extensible Ejemplo: Personalizar... > Agregar comando	No es un buen uso del espacio horizontal si hay menos de tres grupos La tarea puede ser más adecuada para una lista desplegable
Tree control	Permite categorías ilimitadas Permite la agrupación o jerarquía de categorías Extensible Ejemplo: Opciones de herramientas >	Las jerarquías muy anidadas pueden provocar un desplazamiento horizontal excesivo Visual Studio tiene una sobreabundancia de vistas de árbol
Wizard	Ayuda con la finalización de tareas guiando al usuario a través de pasos secuenciales basados en tareas: el asistente representa una tarea de alto nivel y los paneles individuales representan subtareas necesarias para realizar la tarea general. Útil cuando la tarea cruza los límites de la interfaz de usuario, como cuando el usuario tendría que usar varios editores y ventanas de herramientas para completar la tarea. Útil cuando la tarea requiere bifurcación Útil cuando la tarea contiene dependencias entre pasos Útil cuando se pueden presentar varias tareas similares con una bifurcación de decisión en un cuadro de diálogo para reducir el número de diálogos similares diferentes	Inapropiado para cualquier tarea que no requiera un flujo de trabajo secuencial Un asistente puede sobrecargar y confundir a los usuarios con demasiados pasos Los asistentes tienen una superficie de pantalla limitada inherentemente

Pasillos o paneles

Los pasillos y paneles son diálogos o paneles que sirven como puntos de inicio a otros diálogos y ventanas. El "pasillo" bien diseñado muestra inmediatamente solo las opciones, comandos y configuraciones más comunes, lo que permite al usuario realizar fácilmente tareas comunes. Al igual que un pasillo del mundo real proporciona puertas para acceder a las habitaciones detrás de ellas, aquí la interfaz de usuario menos común se recopila en "salas" independientes (a menudo otros diálogos) de funcionalidad relacionada a la que se puede acceder desde el pasillo principal.

Como alternativa, una interfaz de usuario que ofrece toda la funcionalidad disponible en una sola colección en lugar de refactorizar la funcionalidad menos común en ubicaciones independientes es simplemente un panel.

Concepto de pasillo para exponer la interfaz de usuario adicional en Outlook

Adaptive UI

Mostrar u ocultar la interfaz de usuario en función del uso o la experiencia autoinformó de un usuario es otra manera de presentar la interfaz de usuario necesaria mientras oculta otras partes. Esto no se recomienda en Visual Studio, ya que los algoritmos para decidir cuándo mostrar u ocultar la interfaz de usuario pueden ser complicados y las reglas siempre serán incorrectas para algunos conjuntos de casos.

Projects

Proyectos en el Explorador de soluciones

La mayoría de los proyectos se clasifican como basados en referencias, basados en directorios o mixtos. Los tres tipos de proyectos se admiten simultáneamente en el Explorador de soluciones. La raíz de la experiencia del usuario en el trabajo con proyectos tiene lugar dentro de esta ventana. Aunque los distintos nodos de proyecto son proyectos de tipo de referencia, directorio o modo mixto, hay un patrón de interacción común que se debe aplicar como punto de partida antes de diverging en patrones de usuario específicos del proyecto.

Los proyectos siempre deben:

• Compatibilidad con la capacidad de agregar carpetas de proyecto para organizar el contenido del proyecto

• Mantener un modelo coherente para la persistencia del proyecto

Los proyectos también deben mantener modelos de interacción coherentes para:

• Quitar elementos de proyecto

• Saving documents

• Edición de propiedades del proyecto

• Edición del proyecto en una vista alternativa

• Drag-and-drop operations

Modelo de interacción de arrastrar y colocar

Los proyectos normalmente se clasifican como basados en referencias (capaces de conservar solo referencias a elementos de proyecto en el almacenamiento), basados en directorios (capaces de conservar solo los elementos de proyecto almacenados físicamente dentro de la jerarquía de un proyecto) o mixtos (capaces de conservar referencias o elementos físicos). The IDE accommodates all three types of projects simultaneously within the Solution Explorer.

From a drag-and-drop perspective, the following characteristics should apply to each type of project within the Solution Explorer:

• Reference-based project: The key point is that the project is dragging around a reference to an item in storage. Cuando un proyecto basado en referencia actúa como origen para una operación de movimiento, solo debe quitar la referencia al elemento del proyecto. El elemento no debe eliminarse realmente del disco duro. Cuando un proyecto basado en referencia actúa como destino para una operación de movimiento (o copia), debe agregar una referencia al elemento de origen original sin realizar una copia privada del elemento.

• Directory-based project: From a drag-and-drop point of view, the project is dragging around the physical item rather than a reference. Cuando un proyecto basado en directorios actúa como origen para una operación de movimiento, debe acabar eliminando el elemento físico del disco duro, así como quitarlo del proyecto. Cuando un proyecto basado en directorios actúa como destino para una operación de movimiento (o copia), debe realizar una copia del elemento de origen en su ubicación de destino.

• Mixed-target project: From a drag-and-drop point of view, the behavior of this type of project is based on the nature of the item being dragged (either a reference to an item in storage or the item itself). El comportamiento correcto para las referencias y los elementos físicos se describe anteriormente.

If there were only one type of project in the Solution Explorer, then drag-and-drop operations would be straightforward. Dado que cada sistema de proyecto tiene la capacidad de definir su propio comportamiento de arrastrar y colocar, se deben seguir ciertas directrices (basadas en el comportamiento de arrastrar y colocar del Explorador de Windows) para garantizar una experiencia de usuario predecible:

• An unmodified drag operation in the Solution Explorer (when neither Ctrl nor Shift keys are held down) should result in a move operation.

• La operación de arrastre de desplazamiento también debe dar lugar a una operación de movimiento.

• La operación ctrl-arrastrar debe dar lugar a una operación de copia.

• Los sistemas de proyectos mixtos y basados en referencia admiten la noción de agregar un vínculo (o referencia) al elemento de origen. Cuando estos proyectos son el destino de una operación de arrastrar y colocar (cuando se mantiene presionada Ctrl + Mayús ), debe dar lugar a una referencia al elemento que se agrega al proyecto.

No todas las operaciones de arrastrar y colocar son razonables entre combinaciones de proyectos mixtos, basados en directorios y basados en referencias. En concreto, resulta problemático pretender permitir una operación de movimiento entre un proyecto de origen basado en directorios y un proyecto de destino basado en referencias, ya que el proyecto basado en directorio de origen tendrá que eliminar el elemento de origen tras la finalización del movimiento. A continuación, el proyecto basado en referencia de destino acabaría con una referencia a un elemento eliminado.

También es engañoso pretender permitir una operación de copia entre estos tipos de proyectos porque el proyecto basado en referencia de destino no debe realizar una copia independiente del elemento de origen. Del mismo modo, no se debe permitir la arrastrar Ctrl + Mayús a un proyecto de destino basado en directorios porque un proyecto basado en directorios no puede conservar las referencias. En los casos en los que no se admite la operación de arrastrar y colocar, el IDE debe denegar la colocación y mostrar al usuario el cursor sin colocar (que se muestra en la tabla de punteros siguiente).

Para implementar correctamente el comportamiento de arrastrar y colocar, el proyecto de origen del arrastre debe comunicar su naturaleza al proyecto de destino. (Por ejemplo, ¿se basa en referencia o en directorios?) Esta información se indica mediante el formato del Portapapeles que ofrece el origen. Como origen de una operación de arrastrar (o copiar portapapeles), un proyecto debe ofrecer o CF_VSREFPROJECTITEMSCF_VSSTGPROJECTITEMS , respectivamente, dependiendo de si el proyecto está basado en referencia o basado en directorios. Ambos formatos tienen el mismo contenido de datos, que es similar al formato de WindowsCF_HDROP, excepto que las listas de cadenas, en lugar de ser nombres de archivo, son una lista Projref de cadenas terminadas doblementeNULL (como se devuelve de IVsSolution::GetProjrefOfItem o ::GetProjrefOfProject según corresponda).

Como destino de una operación de colocación (o de pegado del Portapapeles), un proyecto debe aceptar y CF_VSREFPROJECTITEMSCF_VSSTGPROJECTITEMS, aunque el control exacto de la operación de arrastrar y colocar varía en función de la naturaleza del proyecto de destino y del proyecto de origen. El proyecto de origen declara su naturaleza tanto si ofrece CF_VSREFPROJECTITEMS como CF_VSSTGPROJECTITEMS. El destino de la caída comprende su propia naturaleza y, por tanto, tiene suficiente información para tomar decisiones sobre si se debe realizar un movimiento, una copia o un vínculo. El usuario también modifica la operación de arrastrar y colocar que debe realizarse presionando ctrl, mayús o teclas Ctrl y Mayús. Es importante que el destino de colocación indique correctamente qué operación se realizará de antemano en sus DragEnter métodos y DragOver . The Solution Explorer automatically knows whether the source project and the target project are the same project.

No se admite específicamente arrastrar elementos de proyecto entre instancias de Visual Studio (por ejemplo, de una instancia de devenv.exe a otra). The Solution Explorer also directly disables this.

El usuario siempre debe poder determinar el efecto de una operación de arrastrar y colocar seleccionando un elemento, arrastrándolo a la ubicación de destino y observando cuál de los siguientes punteros del mouse aparece antes de quitar el elemento:

Mouse pointer	Command	Description
	No drop	No se puede quitar el elemento en la ubicación especificada.
	Copy	El elemento se copiará en la ubicación de destino.
	Move	El elemento se moverá a la ubicación de destino.
	Add reference	Se agregará una referencia al elemento seleccionado a la ubicación de destino.

Reference-based projects

En la tabla siguiente se resumen las operaciones de arrastrar y colocar (así como cortar, copiar y pegar) que se deben realizar en función de la naturaleza del elemento de origen y las teclas modificadoras presionadas para los proyectos de destino basados en referencia:

Modifier	Category	Elemento de origen: Referencia/Vínculo	Elemento de origen: elemento físico o sistema de archivos (CF_HDROP)
No modifier	Action	Move	Link
No modifier	Target	Agrega referencia al elemento original	Agrega referencia al elemento original
No modifier	Source	Elimina la referencia al elemento original.	Conserva el elemento original
No modifier	Result	DROPEFFECT_MOVE se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	DROPEFFECT_LINK se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.
Shift+Drag	Action	Move	No drop
Shift+Drag	Target	Agrega referencia al elemento original	No drop
Shift+Drag	Source	Elimina la referencia al elemento original.	No drop
Shift+Drag	Result	DROPEFFECT_MOVE se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	No drop
Ctrl+Drag	Action	Copy	No drop
Ctrl+Drag	Target	Agrega referencia al elemento original	No drop
Ctrl+Drag	Source	Conserva la referencia al elemento original.	No drop
Ctrl+Drag	Result	DROPEFFECT_COPY se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	No drop
Ctrl+Shift+Drag	Action	Link	Link
Ctrl+Shift+Drag	Target	Agrega referencia al elemento original	Agrega referencia al elemento original
Ctrl+Shift+Drag	Source	Conserva la referencia al elemento original.	Conserva el elemento original
Ctrl+Shift+Drag	Result	DROPEFFECT_LINK se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	DROPEFFECT_LINK se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.
Ctrl+Shift+Drag	Note	Igual que el comportamiento de arrastrar y colocar para los accesos directos en el Explorador de Windows.
Cut/Paste	Action	Move	Link
Cut/Paste	Target	Agrega referencia al elemento original	Agrega referencia al elemento original
Cut/Paste	Source	Conserva la referencia al elemento original.	Conserva el elemento original
Cut/Paste	Result	El elemento permanece en la ubicación original en el almacenamiento	El elemento permanece en la ubicación original en el almacenamiento
Copy/Paste	Action	Copy	Link
Copy/Paste	Source	Agrega referencia al elemento original	Agrega referencia al elemento original
Copy/Paste	Result	Conserva la referencia al elemento original.	Conserva el elemento original
Copy/Paste	Action	El elemento permanece en la ubicación original en el almacenamiento	El elemento permanece en la ubicación original en el almacenamiento

Directory-based projects

En la tabla siguiente se resumen las operaciones de arrastrar y colocar (así como cortar, copiar y pegar) que se deben realizar en función de la naturaleza del elemento de origen y las teclas modificadoras presionadas para los proyectos de destino basados en directorios:

Modifier	Category	Elemento de origen: Referencia/Vínculo	Elemento de origen: elemento físico o sistema de archivos (CF_HDROP)
No modifier	Action	Move	Move
No modifier	Target	Copia el elemento en la ubicación de destino	Copia el elemento en la ubicación de destino
No modifier	Source	Elimina la referencia al elemento original.	Elimina la referencia al elemento original.
Shift+Drag	Action	Move	Move
Shift+Drag	Target	Copia el elemento en la ubicación de destino	Copia el elemento en la ubicación de destino
Shift+Drag	Source	Elimina la referencia al elemento original.	Elimina el elemento de la ubicación original.
Shift+Drag	Result	DROPEFFECT_MOVE se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	DROPEFFECT_MOVE se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.
Ctrl+Drag	Action	Copy	Copy
Ctrl+Drag	Target	Copia el elemento en la ubicación de destino	Copia el elemento en la ubicación de destino
Ctrl+Drag	Source	Conserva la referencia al elemento original.	Conserva la referencia al elemento original.
Ctrl+Drag	Result	DROPEFFECT_COPY se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	DROPEFFECT_COPY se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.
Ctrl+Shift+Drag		No drop	No drop
Cut/Paste	Action	Move	Move
Cut/Paste	Target	Copia el elemento en la ubicación de destino	Copia el elemento en la ubicación de destino
Cut/Paste	Source	Elimina la referencia al elemento original.	Elimina el elemento de la ubicación original.
Cut/Paste	Result	El elemento permanece en la ubicación original en el almacenamiento	El elemento se elimina de la ubicación original en el almacenamiento
Copy/Paste	Action	Copy	Copy
Copy/Paste	Target	Agrega referencia al elemento original	Copia el elemento en la ubicación de destino
Copy/Paste	Source	Conserva el elemento original	Conserva el elemento original
Copy/Paste	Result	El elemento permanece en la ubicación original en el almacenamiento	El elemento permanece en la ubicación original en el almacenamiento

Mixed-target projects

En la tabla siguiente se resumen las operaciones de arrastrar y colocar (así como cortar, copiar y pegar) que se deben realizar en función de la naturaleza del elemento de origen y las teclas modificadoras presionadas para los proyectos de destino mixto:

Modifier	Category	Elemento de origen: Referencia/Vínculo	Elemento de origen: elemento físico o sistema de archivos (CF_HDROP)
No modifier	Action	Move	Move
No modifier	Target	Agrega referencia al elemento original	Copia el elemento en la ubicación de destino
No modifier	Source	Elimina la referencia al elemento original.	Elimina la referencia al elemento original.
No modifier	Result	DROPEFFECT_ MOVE se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	DROPEFFECT_ MOVE se devuelve como acción de ::Drop y el elemento se elimina de la ubicación original en el almacenamiento.
Shift+Drag	Action	Move	Move
Shift+Drag	Target	Agrega referencia al elemento original	Copia el elemento en la ubicación de destino
Shift+Drag	Source	Elimina la referencia al elemento original.	Elimina el elemento de la ubicación original.
Shift+Drag	Result	DROPEFFECT_ MOVE se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	DROPEFFECT_ MOVE se devuelve como acción de ::Drop y el elemento se elimina de la ubicación original en el almacenamiento.
Ctrl+Drag	Action	Copy	Copy
Ctrl+Drag	Target	Agrega referencia al elemento original	Copia el elemento en la ubicación de destino
Ctrl+Drag	Source	Conserva la referencia al elemento original.	Conserva el elemento original
Ctrl+Drag	Result	DROPEFFECT_ COPY se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	DROPEFFECT_ COPY se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.
Ctrl+Shift+Drag	Action	Link	Link
Ctrl+Shift+Drag	Target	Agrega referencia al elemento original	Agrega referencia al elemento de origen original
Ctrl+Shift+Drag	Source	Conserva la referencia al elemento original.	Conserva el elemento original
Ctrl+Shift+Drag	Result	DROPEFFECT_ LINK se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	DROPEFFECT_ LINK se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.
Cut/Paste	Action	Move	Move
Cut/Paste	Target	Copia el elemento en la ubicación de destino	Copia el elemento en la ubicación de destino
Cut/Paste	Source	Elimina la referencia al elemento original.	Elimina el elemento de la ubicación original.
Cut/Paste	Result	El elemento permanece en la ubicación original en el almacenamiento	El elemento se elimina de la ubicación original en el almacenamiento
Copy/Paste	Action	Copy	Copy
Copy/Paste	Target	Agrega referencia al elemento original	Copia el elemento en la ubicación de destino
Copy/Paste	Source	Conserva el elemento original	Conserva el elemento original
Copy/Paste	Result	El elemento permanece en la ubicación original en el almacenamiento	El elemento permanece en la ubicación original en el almacenamiento

These details should be taken into consideration when implementing dragging in the Solution Explorer:

• Diseño para varios escenarios de selección.

• Los nombres de archivo (ruta de acceso completa) deben ser únicos en el proyecto de destino o no se debe permitir la colocación.

• Los nombres de carpeta deben ser únicos (no distinguen mayúsculas de minúsculas) en el nivel en que se quitan.

• Hay diferencias de comportamiento entre los archivos que están abiertos o cerrados en el momento de arrastrar (no mencionados en escenarios anteriores).

• Los archivos de nivel superior se comportan de forma ligeramente diferente a los archivos de las carpetas.

Otro problema que se debe tener en cuenta es cómo controlar las operaciones de movimiento en los elementos que tienen diseñadores o editores abiertos. El comportamiento esperado es el siguiente (esto se aplica a todos los tipos de proyecto):

1. Si el editor o diseñador abierto no tiene cambios no guardados, la ventana del editor o diseñador debe cerrarse silenciosamente.

2. Si el editor o diseñador abierto tiene cambios no guardados, el origen de la arrastrar debe esperar a que se produzca la colocación y, a continuación, pida al usuario que guarde los cambios no confirmados en los documentos abiertos antes de cerrar la ventana con un símbolo del sistema similar al siguiente:

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

Esto proporciona al usuario la oportunidad de guardar el trabajo en curso antes de que el destino realice sus copias. Se ha agregado un nuevo método IVsHierarchyDropDataSource2::OnBeforeDropNotify para habilitar este control.

The target will then copy the state of the item as it is in storage (not including the unsaved changes in the editor if the user chose No). Una vez que el destino haya completado su copia (en IVsHierarchyDropDataSource::Drop), el origen tendrá la oportunidad de completar la parte de eliminación de la operación de movimiento (en IVsHierarchyDropDataSource::OnDropNotify).

Los editores con cambios no guardados deben dejarse abiertos. Para esos documentos con cambios no guardados, esto significa que se realizará la parte de copia de la operación de traslado, pero se anulará la parte de eliminación. In a multiple selection scenario when the user chooses No, those documents with unsaved changes should not be closed or removed, but those without unsaved changes should be closed and removed.