Patrones de aplicaciones para Visual Studio

Interacciones de ventana

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. Los patrones de diálogo modal se tratan en Diálogos.

Comparación de patrones de uso de ventanas

Las ventanas de documento casi siempre se muestran dentro del área del documento. Esto proporciona al editor de documentos una "fase central" para organizar ventanas de herramientas complementarias alrededor.

Una ventana de herramientas se muestra con más frecuencia como una ventana independiente y más pequeña contraída en el borde del IDE. Esto puede ser visible, oculto o oculto automáticamente. Sin embargo, a veces las ventanas de herramientas se presentan en el área del documento desactivando la propiedad Window/Docking en la ventana. 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.

Los cuadros de diálogo modeless no se recomienda en 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.

	Ventana documento	Ventana de herramientas	Cuadro de diálogo sin modo
Posición	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.
Modelo de confirmación	Confirmación retrasada 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.	Confirmación inmediata 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.
Visibilidad	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.
Instancias	Instancias múltiples 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.	Instancia única
Ejemplos	Editores de texto, como el editor de código Superficies de diseño, como un diseñador de formularios o una superficie de modelado Diseños de control similares a los cuadros de diálogo, como el Diseñador de manifiestos	El Explorador de soluciones proporciona una solución y proyectos contenidos en la solución El Explorador de servidores proporciona una vista jerárquica de los servidores y las conexiones de datos que el usuario elige abrir en la ventana. 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. El Explorador de propiedades muestra las propiedades del objeto seleccionado en una ventana de documento u otra ventana de herramientas. 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.

Ventanas de herramientas

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.

• Las ventanas de herramientas acopladas o ancladas se pueden adjuntar a cualquiera de los cuatro lados del área del documento. 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.

• Las ventanas de herramientas ocultas automáticamente se desanclan. 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.

• Las ventanas de herramientas visibles automáticamente aparecen automáticamente cuando otra parte de la interfaz de usuario, como un editor, se inicia o obtiene el foco.

• Las ventanas de herramientas flotantes se desplazan fuera del IDE. Esto es útil para las configuraciones de varios monitores.

• Las ventanas de herramientas de documentos con pestañas se pueden acoplar dentro del área del documento. 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 la 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 la interfaz de varios documentos (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. La lista debe responder a los comandos GoToNextLocation y GoToPrevLocation cambiando también el elemento seleccionado actualmente en la ventana.

Algunos ejemplos de ventanas de herramientas de lista navegables son la 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

Ventana de herramientas	Función
Explorador de soluciones	Á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).
Vista de clases	Árbol jerárquico de las clases y varios elementos del conjunto de trabajo de documentos, independientemente de los propios archivos.
Explorador de servidores	Árbol jerárquico que muestra todos los servidores y conexiones de datos de la solución.
Esquema del documento	Estructura jerárquica del documento activo.

Ventanas de herramientas de cuadrícula

Ventana de herramientas	Función
Propiedades	Cuadrícula que muestra una lista de propiedades para el objeto seleccionado, junto con selectores de valores para editar esas propiedades.
Lista de tareas	Cuadrícula que permite al usuario crear, editar o eliminar tareas y comentarios.

Ventanas de herramientas de contenido

Ventana de herramientas	Función
Ayuda	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.
Ayuda dinámica	Ventana de herramientas que muestra vínculos a temas de ayuda aplicables a la selección actual.
Examinador de objetos	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

Ventana de herramientas	Función
Buscar	Cuadro de diálogo que permite al usuario buscar o buscar y reemplazar en varios archivos de la solución.
Búsqueda avanzada	Cuadro de diálogo que permite al usuario buscar o buscar y reemplazar en varios archivos de la solución.

Otras ventanas de herramientas

Ventana de herramientas	Función
Cuadro de herramientas	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

Ventana de herramientas	Función
Autos
Inmediato
Output	La ventana de salida se puede usar siempre que tenga eventos de texto o estado para declarar.
Memoria
Puntos de interrupción
En ejecución
Documentos
Pila de llamadas
Locals
Watches
Desensamblado
Registros
Subprocesos

Convenciones del editor de documentos

Interacciones de documentos

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 un fuerte sentido de la selección asociada a 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

• Mantenga un modelo de interacción coherente en las experiencias comunes de nuevo archivo y archivo abierto.

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

• Los comandos de menú se integran adecuadamente en menús comunes, como los menús Editar, Formato y Ver . 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 la ventana Explorador de soluciones o jerarquía activa similar.

• Al hacer doble clic en un documento de la Explorador de soluciones debe realizar la misma acción que Abrir.

• Si se puede usar más de un editor en un tipo de documento, el usuario debe poder invalidar o restablecer la acción predeterminada en un tipo de documento determinado mediante el cuadro de diálogo Abrir con haciendo clic con el botón derecho en el archivo y seleccionando Abrir con en el menú contextual.

• 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.

• Editor basado en texto: editor de código, archivos de registro

• Superficie de diseño: Diseñador de formularios WPF, Formularios Windows Forms

• Editor de estilo de diálogo: Diseñador de manifiestos, propiedades del proyecto

• Diseñador de modelos: diseñador de flujo de trabajo, mapa de código, diagrama de arquitectura, progresión

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.

• Informes: informe de IntelliTrace, informe de Hyper-V, informe del generador de perfiles

• Panel: Centro de diagnóstico

Editores basados en texto

• 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.

Superficies de diseño

• 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.

• Las barras de herramientas incrustadas solo contienen comandos específicos del documento, no comandos comunes como Guardar.

Editores de estilo de diálogo

• 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.

Diseñadores de modelos

• 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.

• Las barras de herramientas incrustadas solo contienen comandos específicos del documento, no comandos comunes como Guardar.

• 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.

Informes

• 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.

Paneles

• 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.

Diálogos

Introducción

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.

Temas

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

Estándar (no bloqueado)

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.

Temática

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:

• El cuadro de diálogo es una experiencia común que se verá y usará a menudo o por muchos usuarios (por ejemplo, el cuadro de diálogo Nuevo proyecto .

• El cuadro de diálogo contiene elementos destacados de marca de producto (por ejemplo, el cuadro de diálogo Cuenta Configuración).

• 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 Conectar).

• 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).

Diseño de cuadros de diálogo

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

• Acceso mediante el teclado

Organización de contenido

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

• Los cuadros de diálogo simples presentan controles en una sola ventana modal. La presentación puede incluir variaciones de patrones de control complejos, incluido un selector de campos o una barra de iconos.

• Los diálogos en capas se usan para sacar el máximo partido al espacio real de la pantalla cuando una sola parte de la interfaz de usuario consta de varios grupos de controles. 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.

• Los asistentes son útiles para dirigir al usuario a través de una secuencia lógica de pasos hacia la finalización de una tarea. 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.

Cuadros de diálogo simples

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.

Cuadros de diálogo en capas

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.

Asistentes

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. Una vez disponibles los valores predeterminados suficientes, el botón Finalizar está habilitado.

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.

Convenciones comunes

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 al 150 %, se mostrará un inicio posterior del cuadro de diálogo al 150 %.

Posición

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.

Cuando los usuarios necesitan realizar dos actividades a la vez, como Buscar y reemplazar al escribir código nuevo, el cuadro de diálogo debe ser modelado para que el usuario pueda cambiar fácilmente entre ellos. Visual Studio suele usar ventanas de herramientas para este tipo de tareas vinculadas compatibles con el editor.

Configuración del control

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

Barras de título

• 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

Botones de control

En general, los botones Aceptar, Cancelar y Ayuda deben organizarse horizontalmente en la esquina inferior derecha del cuadro de diálogo. 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. Para determinar el mejor comando que se va a usar como valor predeterminado, elija entre las siguientes opciones (enumeradas en orden de prioridad):

• 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.

Claves de acceso

No use las teclas de acceso para los botones Aceptar, Cancelar o Ayuda . Estos botones se asignan a las teclas de método abreviado de forma predeterminada:

Nombre del botón	Método abreviado de teclado
OK (CORRECTO)	Entrar
Cancelar	Esc
Ayuda	F1

Imágenes

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.

Tabulación

Mecanismo de conmutación	Ventajas y uso adecuado	Desventajas y uso inadecuado
Control Tab	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 de Explorador de archivos > elemento	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) No extensible
Navegación lateral	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
Asistente	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

Interfaz de usuario adaptable

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.

Proyectos

Proyectos del 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 una consis modo carpa l para la persistencia del proyecto

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

• Quitar elementos de proyecto

• Guardar documentos

• Edición de propiedades del proyecto

• Edición del proyecto en una vista alternativa

• Operaciones de arrastrar y colocar

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). El IDE admite los tres tipos de proyectos simultáneamente dentro del Explorador de soluciones.

Desde una perspectiva de arrastrar y colocar, las siguientes características deben aplicarse a cada tipo de proyecto dentro del Explorador de soluciones:

• Proyecto basado en referencia: el punto clave es que el proyecto se está arrastrando alrededor de una referencia a un elemento en el almacenamiento. 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.

• Proyecto basado en directorios: desde un punto de vista de arrastrar y colocar, el proyecto se arrastra alrededor del elemento físico en lugar de una referencia. 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.

• Proyecto de destino mixto: desde un punto de vista de arrastrar y colocar, el comportamiento de este tipo de proyecto se basa en la naturaleza del elemento que se está arrastrando (ya sea una referencia a un elemento en el almacenamiento o en el propio elemento). El comportamiento correcto para las referencias y los elementos físicos se describe anteriormente.

Si solo hubiera un tipo de proyecto en la Explorador de soluciones, las operaciones de arrastrar y colocar serían sencillas. 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:

• Una operación de arrastre sin modificar en el Explorador de soluciones (cuando no se mantienen presionadas las teclas Ctrl ni Mayús) debe dar lugar a una operación de movimiento.

• 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_VSREFPROJECTITEMS CF_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_VSREFPROJECTITEMS CF_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 . El Explorador de soluciones sabe automáticamente si el proyecto de origen y el proyecto de destino son el mismo proyecto.

No se admite específicamente arrastrar elementos de proyecto entre instancias de Visual Studio (por ejemplo, de una instancia de devenv.exe a otra). El Explorador de soluciones también deshabilita directamente esto.

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	Comando	Descripción
	Sin colocar	No se puede quitar el elemento en la ubicación especificada.
	Copiar	El elemento se copiará en la ubicación de destino.
	Mover	El elemento se moverá a la ubicación de destino.
	Agregar referencia	Se agregará una referencia al elemento seleccionado a la ubicación de destino.

Proyectos basados en referencia

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:

Modificador	Category	Elemento de origen: Referencia/Vínculo	Elemento de origen: elemento físico o sistema de archivos (CF_HDROP)
Sin modificador	Acción	Mover	Vínculo
Sin modificador	Destino	Agrega referencia al elemento original	Agrega referencia al elemento original
Sin modificador	Source	Elimina la referencia al elemento original.	Conserva el elemento original
Sin modificador	Resultado	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.
Mayús+Arrastrar	Acción	Mover	Sin colocar
Mayús+Arrastrar	Destino	Agrega referencia al elemento original	Sin colocar
Mayús+Arrastrar	Source	Elimina la referencia al elemento original.	Sin colocar
Mayús+Arrastrar	Resultado	DROPEFFECT_MOVE se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	Sin colocar
Ctrl+Arrastrar	Acción	Copiar	Sin colocar
Ctrl+Arrastrar	Destino	Agrega referencia al elemento original	Sin colocar
Ctrl+Arrastrar	Source	Conserva la referencia al elemento original.	Sin colocar
Ctrl+Arrastrar	Resultado	DROPEFFECT_COPY se devuelve como acción de ::Drop y el elemento permanece en la ubicación original en el almacenamiento.	Sin colocar
Ctrl+Mayús+Arrastrar	Acción	Vínculo	Vínculo
Ctrl+Mayús+Arrastrar	Destino	Agrega referencia al elemento original	Agrega referencia al elemento original
Ctrl+Mayús+Arrastrar	Source	Conserva la referencia al elemento original.	Conserva el elemento original
Ctrl+Mayús+Arrastrar	Resultado	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+Mayús+Arrastrar	Nota:	Igual que el comportamiento de arrastrar y colocar para los accesos directos en el Explorador de Windows.
Cortar y pegar	Acción	Mover	Vínculo
Cortar y pegar	Destino	Agrega referencia al elemento original	Agrega referencia al elemento original
Cortar y pegar	Source	Conserva la referencia al elemento original.	Conserva el elemento original
Cortar y pegar	Resultado	El elemento permanece en la ubicación original en el almacenamiento	El elemento permanece en la ubicación original en el almacenamiento
Copiar y pegar	Acción	Copiar	Vínculo
Copiar y pegar	Source	Agrega referencia al elemento original	Agrega referencia al elemento original
Copiar y pegar	Resultado	Conserva la referencia al elemento original.	Conserva el elemento original
Copiar y pegar	Acción	El elemento permanece en la ubicación original en el almacenamiento	El elemento permanece en la ubicación original en el almacenamiento

Proyectos basados en directorios

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:

Modificador	Category	Elemento de origen: Referencia/Vínculo	Elemento de origen: elemento físico o sistema de archivos (CF_HDROP)
Sin modificador	Acción	Mover	Mover
Sin modificador	Destino	Copia el elemento en la ubicación de destino	Copia el elemento en la ubicación de destino
Sin modificador	Source	Elimina la referencia al elemento original.	Elimina la referencia al elemento original.
Mayús+Arrastrar	Acción	Mover	Mover
Mayús+Arrastrar	Destino	Copia el elemento en la ubicación de destino	Copia el elemento en la ubicación de destino
Mayús+Arrastrar	Source	Elimina la referencia al elemento original.	Elimina el elemento de la ubicación original.
Mayús+Arrastrar	Resultado	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+Arrastrar	Acción	Copiar	Copiar
Ctrl+Arrastrar	Destino	Copia el elemento en la ubicación de destino	Copia el elemento en la ubicación de destino
Ctrl+Arrastrar	Source	Conserva la referencia al elemento original.	Conserva la referencia al elemento original.
Ctrl+Arrastrar	Resultado	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+Mayús+Arrastrar		Sin colocar	Sin colocar
Cortar y pegar	Acción	Mover	Mover
Cortar y pegar	Destino	Copia el elemento en la ubicación de destino	Copia el elemento en la ubicación de destino
Cortar y pegar	Source	Elimina la referencia al elemento original.	Elimina el elemento de la ubicación original.
Cortar y pegar	Resultado	El elemento permanece en la ubicación original en el almacenamiento	El elemento se elimina de la ubicación original en el almacenamiento
Copiar y pegar	Acción	Copiar	Copiar
Copiar y pegar	Destino	Agrega referencia al elemento original	Copia el elemento en la ubicación de destino
Copiar y pegar	Source	Conserva el elemento original	Conserva el elemento original
Copiar y pegar	Resultado	El elemento permanece en la ubicación original en el almacenamiento	El elemento permanece en la ubicación original en el almacenamiento

Proyectos de destino mixto

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:

Modificador	Category	Elemento de origen: Referencia/Vínculo	Elemento de origen: elemento físico o sistema de archivos (CF_HDROP)
Sin modificador	Acción	Mover	Mover
Sin modificador	Destino	Agrega referencia al elemento original	Copia el elemento en la ubicación de destino
Sin modificador	Source	Elimina la referencia al elemento original.	Elimina la referencia al elemento original.
Sin modificador	Resultado	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.
Mayús+Arrastrar	Acción	Mover	Mover
Mayús+Arrastrar	Destino	Agrega referencia al elemento original	Copia el elemento en la ubicación de destino
Mayús+Arrastrar	Source	Elimina la referencia al elemento original.	Elimina el elemento de la ubicación original.
Mayús+Arrastrar	Resultado	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+Arrastrar	Acción	Copiar	Copiar
Ctrl+Arrastrar	Destino	Agrega referencia al elemento original	Copia el elemento en la ubicación de destino
Ctrl+Arrastrar	Source	Conserva la referencia al elemento original.	Conserva el elemento original
Ctrl+Arrastrar	Resultado	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+Mayús+Arrastrar	Acción	Vínculo	Vínculo
Ctrl+Mayús+Arrastrar	Destino	Agrega referencia al elemento original	Agrega referencia al elemento de origen original
Ctrl+Mayús+Arrastrar	Source	Conserva la referencia al elemento original.	Conserva el elemento original
Ctrl+Mayús+Arrastrar	Resultado	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.
Cortar y pegar	Acción	Mover	Mover
Cortar y pegar	Destino	Copia el elemento en la ubicación de destino	Copia el elemento en la ubicación de destino
Cortar y pegar	Source	Elimina la referencia al elemento original.	Elimina el elemento de la ubicación original.
Cortar y pegar	Resultado	El elemento permanece en la ubicación original en el almacenamiento	El elemento se elimina de la ubicación original en el almacenamiento
Copiar y pegar	Acción	Copiar	Copiar
Copiar y pegar	Destino	Agrega referencia al elemento original	Copia el elemento en la ubicación de destino
Copiar y pegar	Source	Conserva el elemento original	Conserva el elemento original
Copiar y pegar	Resultado	El elemento permanece en la ubicación original en el almacenamiento	El elemento permanece en la ubicación original en el almacenamiento

Estos detalles deben tenerse en cuenta al implementar el arrastre en el Explorador de soluciones:

• 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.

A continuación, el destino copiará el estado del elemento tal como está en el almacenamiento (sin incluir los cambios no guardados en el editor si el usuario eligió 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. En un escenario de selección múltiple cuando el usuario elige No, esos documentos con cambios no guardados no deben cerrarse ni quitarse, pero aquellos sin cambios no guardados deben cerrarse y quitarse.