objects microsoft español .net wpf silverlight xaml

microsoft - ¿Qué características de.Net/WPF echas de menos cuando trabajas en Silverlight?



xaml objects (11)

¿Dónde empiezo? :)

  • Sin multibomba
  • No ElementName = vinculante
  • TemplateBinding solo puede referirse a propiedades directas, no adjuntas DP
  • Sin enlace RelativeSource
  • No vinculante para las propiedades secundarias , por ejemplo, {Binding Path=Foo.Bar[0].Baz}
  • Sin posibilidad de suscribirse a eventos modificados en ninguna propiedad de dependencia arbitraria: el autor de la clase tiene que definir explícitamente un evento (y en la mayoría de los casos, solo una o dos propiedades en los controles SL realmente lo hacen)
  • El Visual State Manager requiere que el autor del control conozca todos los estados con capacidad de estilo cuando se escribe el control, lo que rompe completamente la historia de "extensión a través de estilos / plantillas, no herencia" que promueve WPF.
  • Sin adornos
  • Sin navegación
  • Sin herencia de propiedad de dependencia
  • Soporte No / sucky para diccionarios de recursos externos / diccionarios fusionados
  • La historia de validación apesta (solo es marginalmente mejor en WPF)
  • Impresión
  • <Setter .. Value="{Binding ...}" /> no es compatible

Además de eso, varias firmas de métodos cambiaron sin una buena razón. Por ejemplo, IIRC, las sobrecargas de Dispatcher.Invoke son diferentes, en lugar de que SL ignore los parámetros que aún no puede manejar. O como otro ejemplo, ObservableCollection en WPF puede generar Agregar, Eliminar, Reemplazar y Mover eventos - en SL solo son los tres primeros.

Desde que escribo el código para trabajar en ambas plataformas, el código termina lleno de patrones de estrategia y #ifdefs. Se siente como C ++ de nuevo :-)

Recientemente comencé a trabajar con Silverlight e inmediatamente noté la diferencia entre el Silverlight BCL y el .Net y WPF completo. Para algunos de ellos, encontré excelentes soluciones publicadas en línea por otros desarrolladores, y otras fueron más complicadas. ¿Qué características / clases le sorprendieron / decepcionaron al encontrar ausentes de las bibliotecas de clases de Silverlight, y qué hizo para evitarlas?

Algunos de los míos fueron:

  1. No hay animaciones desencadenadas por eventos : creé una clase auxiliar con métodos estáticos para adjuntar cada tipo de animación que he usado a los guiones gráficos en una biblioteca compartida, y en el nivel de la aplicación creo clases con métodos estáticos para juntarlos como lo hubiera hecho en XAML si trabaja en WPF. Hasta ahora, esta ha sido una buena solución para mantener mis animaciones organizadas y la lógica fuera de mis controladores de eventos.
  2. ScrollViewer no es compatible con la rueda del mouse : Adam Cooper creó una excelente biblioteca de clases que agrega esta funcionalidad que requiere el mínimo de código para implementar en cualquier proyecto de Silverlight. Su sitio parece estar inactivo en este momento, así que aquí hay un enlace al blog de Tim Heuer que lo explica y lo vincula (para que esté disponible cuando su sitio vuelva a estar en línea). Agregue soporte de rueda del mouse a ScrollViewer en Silverlight
  3. SortedDictionary<T, K> encuentra. Encontré esta publicación que contiene una implementación, pero no terminé usándola yo mismo.
  4. ResourceDictionary.MergedDictionaries no está disponible . Nuevamente ... encontré a alguien que implementó esto y publicó el código fuente, pero parecía ser un poco complicado. Probablemente lo resolveré un poco, pero todavía tengo que hacerlo. MergedDictionaries en Silverlight
  5. La propiedad asociada a ZIndex solo está disponible en el objeto Canvas. Publiqué esto como una pregunta aquí en SO, y alguien hizo una gran sugerencia para envolver mis contenedores en una colección, si eso es lo que se necesita. Se siente un poco descuidado, pero debes hacer lo que tienes que hacer. Mis contenedores están anidados a tres niveles de profundidad, por lo que podría necesitar deformarlos todos en objetos Canvas y configurar el Canvas.ZIndex tres veces para cada evento. Feo como el pecado, pero si es el único, entonces que así sea.

Me interesa ver qué otros problemas comunes han encontrado los desarrolladores de Silverlight más experimentados y qué ha hecho para solucionarlos.

Además de la excelente lista de Paul Stovell :

  • Sin extensiones de marcado personalizado.
  • No x:Type extensión de marcado.
  • No LayoutTransform (aunque hay workarounds ).
  • No hay metadatos de conveniencia para DependencyProperties (tiene que definir manualmente la invalidación de medidas / arreglos / renderizaciones, cambios de propiedad, etc.).
  • No hay clases de Drawing o DrawingContext livianas (tienen que usar elementos Shape ).
  • Sin comandos.

Al parecer, comentar sobre el comentario de Felixthehat requiere una cierta reputación.

Pero me gustaría secundar su llamado a desencadenantes de eventos / propiedades ... El marco Triggers en WPF me permite hacer cosas realmente poderosas como diseñador de interacciones sin tener que sumergirme en el código. Lo extraño.

Aquí hay algunas cosas que encontré cuando convertí una aplicación WPF a Silverlight:

  1. La clase Enum es diferente ... No se puede hacer esto en Silverlight (puede en WPF) para enlazar a un Enum:

    HoleType1.ItemsSource = Enum.GetValues ​​(typeof (Hole.HoleTypes));

  2. Los colores del pincel funcionan de manera diferente ...

WPF:

protected Brush _CurrentHoleColor = Brushes.Red;

Silverlight:

protected Brush _CurrentHoleColor = new SolidColorBrush(Colors.Red);

3. Todavía no he sacado este, pero hay algo diferente acerca de este código WPF que había usado para verificar dónde se hizo clic en el mouse:

System.Windows.Media.VisualTreeHelper.HitTest(canvas1, p);

4. Creo que algo es ligeramente diferente sobre las sobrecargas usadas para crear nuevos hilos con

this.Dispatcher.BeginInvoke(....)

Como diseñador, la falta de desencadenantes de eventos / propiedades es tan desempoderante.

No soy C # / oop chico, así que cuando tengo que desencadenar una cadena de guiones gráficos cuando un artículo se carga o se hace clic en un botón o después de que termina otro guión gráfico, tengo que llamar a los desarrolladores en :(

La mayor queja que tengo es la falta de soporte completo para todas las vinculaciones de WCF disponibles. Solo el hecho de poder utilizar BasicHttpBinding a menudo significa que una solución Silverlight a un problema no es una opción válida.

Los estilos inmutables de Silverlight y la falta de fusión de diccionarios también son importantes: si está escribiendo controles, estos dos le dan mucha molestia, por no mencionar los archivos generic.xaml inmanejables.

Perspectiva 3d es genial, ¡pero no puedo esperar para obtener 3D real!

Probablemente, el soporte para Socket o UDP no sea el mayor problema para mí, seguido de las clases de cifrado que faltan.

Además, las clases perdidas como StringDictionary y ApplicationException a las que te acostumbras y luego encuentras que no existen son un problema. En general, es posible encontrar un sustituto o una solución, pero personalmente preferiría que la descarga de Silverlight fuera de 5MB a 6MB, así que no tuvimos que hacerlo ;-).

Un truco realmente útil que vi en un blog que me permitió reutilizar mis ensamblajes .Net normales fue agregar elementos existentes como un enlace. En varios casos ahora tengo dos archivos de proyecto que usan los mismos archivos de clase con un objetivo .Net 3.5 y el otro el tiempo de ejecución de Silverlight. Estoy muy agradecido de haber encontrado ese truco ya que estaba empezando a seguir el camino de crear diferentes bases de código para .Net 3.5 y Silverlight.

Sin soporte 3D

  • ScrollViewer no tiene evento de cambio (debe usar un corte de enlace)
  • Ningún soporte de menú contextual agnóstico del navegador hasta la versión 4
  • Soporte limitado de DocumentFlow
  • Sin soporte MD5 (pero los algoritmos hash más modernos en su lugar)
  • WebClient no le permite hacer solicitudes autenticadas por HTTP.

Mi mayor problema:

  • Un nido de espacios de nombres de ratas