¿Qué enfoques están disponibles para los datos ficticios de tiempo de diseño en WPF?

Estoy trabajando sin mezcla de expresiones y solo usando el editor XAML en vs2010. Dejando de lado la sabiduría de esto, cada vez veo más la necesidad de un enlace de datos en tiempo de diseño. Para casos simples, la propiedad FallbackValue funciona muy bien (Textboxes y TextBlocks, etc.). Pero especialmente cuando se trata de ItemsControl y similares, uno realmente necesita datos de muestra para ser visibles en el diseñador para que pueda ajustar y modificar los controles y las plantillas de datos sin tener que ejecutar el ejecutable.

Sé que ObjectDataProvider permite vincular a un tipo y, por lo tanto, puede proporcionar datos en tiempo de diseño para visualizar, pero luego hay algunos malabares para permitir que los datos reales en tiempo de ejecución se vinculen sin desperdiciar recursos cargando cargando tanto el tiempo de diseño , datos dummied y los enlaces de tiempo de ejecución.

Realmente lo que quiero es la capacidad de tener, por ejemplo, “John”, “Paul”, “George” y “Ringo” en el diseñador de XAML como elementos adaptables en ItemsControl , pero tengo datos reales que aparecen cuando el la aplicación se ejecuta

También sé que Blend permite algunos atributos extravagantes que definen datos de enlace de tiempo de diseño que WPF ignora de manera efectiva en condiciones de tiempo de ejecución.

Entonces mis preguntas son:

1. ¿Cómo podría aprovechar enlaces de tiempo de diseño de colecciones y datos no triviales en el diseñador XAML del estudio visual y luego cambiar a enlaces de tiempo de ejecución sin problemas?

2. ¿Cómo han resuelto otros este problema de tiempo de diseño frente a tiempo de ejecución? En mi caso, no puedo usar fácilmente los mismos datos para ambos (como se podría hacer con, por ejemplo, una consulta de base de datos).

3. ¿Se combinan sus alternativas a la expresión que podría usar para el diseño XAML integrado a datos? (Sé que hay algunas alternativas, pero específicamente quiero algo que pueda usar y ver datos de muestras encuadernados, etc.)

Con VS2010 puede usar los atributos de tiempo de diseño (funciona tanto para SL como para WPF). Por lo general, tengo una fuente de datos simulada de todos modos, así que solo se trata de:

  • Agregar la statement del espacio de nombres

     xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
  • Agregar el contexto de datos simulados a recursos de ventana / control

        
  • Establecer contexto de datos de tiempo de diseño

      

Funciona lo suficientemente bien.

Como una amalgama de la respuesta aceptada por Goran y el excelente comentario de Rene.

  • Agregue la statement del espacio de nombres. xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

  • Haga referencia al contexto de datos de tiempo de diseño desde el código.

Karl Shifflett describe un enfoque que debería funcionar igualmente bien para VS2008 y VS2010:

Visualización de datos de tiempo de diseño en Visual Studio 2008 Cider Designer en WPF y Silverlight Projects

Laurent Bugnion tiene un enfoque similar que se centra en Expression Blend. Podría funcionar para VS2010, pero aún no lo he confirmado.

Simular datos en modo de diseño en Microsoft Expression Blend

Tal vez las nuevas funciones en tiempo de diseño de Visual Studio 2010 y Expression Blend 4 sean una opción para usted.

Cómo funciona se muestra en la aplicación de ejemplo BookLibrary del WPF Application Framework (WAF) . Descargue la versión .NET4.

Utilizo este enfoque para generar datos de tiempo de diseño con .NET 4.5 y Visual Studio 2013.

Solo tengo un ViewModel. El modelo de vista tiene una propiedad IsInDesignMode que indica si el modo de diseño está activo o no (vea la clase ViewModelBase ). Luego puede configurar sus datos de tiempo de diseño (como llenar un control de elementos) en el constructor de modelos de vista.

Además, no cargaría datos reales en el constructor de modelos de vista, esto podría ocasionar problemas en el tiempo de ejecución, pero la configuración de datos para el tiempo de diseño no debería ser un problema.

 public abstract class ViewModelBase { public bool IsInDesignMode { get { return DesignerProperties.GetIsInDesignMode(new DependencyObject()); } } } public class ExampleViewModel : ViewModelBase { public ExampleViewModel() { if (IsInDesignMode == true) { LoadDesignTimeData(); } } private void LoadDesignTimeData() { // Load design time data here } } 

Similar a la respuesta mejor valorada, pero mejor en mi opinión: puede crear una propiedad estática para devolver una instancia de datos de diseño y hacer referencia directamente a XAML de esta forma:

    

Esto evita la necesidad de usar UserControl.Resources . Su propiedad estática puede funcionar como una fábrica que le permite construir tipos de datos no triviales, por ejemplo, si no tiene un ctor predeterminado, puede llamar a una fábrica o contenedor aquí para inyectarlo en dependencias apropiadas.

Utilicé Visual Studio 2017 y seguir todas las guías y preguntas como esta, y todavía estaba enfrentando un que simplemente no ejecutaba el código que tenía dentro del constructor de un DesignFooViewModel que hereda de FooViewModel . Confirmé la parte “no se ejecutó” después de esta guía “práctica” de MSDN (spoiler: depuración de MessageBox ). Si bien esto no está directamente relacionado con la pregunta original, espero que les ahorre a los demás mucho tiempo.

Resulta que no estaba haciendo nada mal. El problema es que mi aplicación necesita ser desarrollada para x64. Como el Visual Studio todavía está en 2018, es un proceso de 32 bits y aparentemente no puede convertir un proceso de host de 64 bits para la parte del diseñador, no puede usar mis clases x64. Lo realmente malo es que no hay errores en ningún registro que se me ocurra.

Por lo tanto, si tropieza con esta pregunta porque está viendo datos falsos con su modelo de vista de tiempo de diseño (por ejemplo: muestra el Name sin importar el valor de la propiedad) la causa es es probable que sea tu construcción x64. Si no puede cambiar su configuración de comstackción a anycpu o x86 debido a las dependencias, considere crear un nuevo proyecto que sea completamente anycpu y no tenga las dependencias (ni dependencias). Así que terminas dividiendo la mayoría o todas menos las partes de inicialización del código de tu proyecto “WPF App” en un proyecto de “biblioteca de clases C #”.

Para la base de código en la que estoy trabajando creo que esto forzará una separación saludable de las preocupaciones a costa de una duplicación de código que probablemente sea una cosa positiva.