2009-09-03 8 views
15

Estoy convirtiendo una aplicación WPF a Silverlight.Forma personalizada en Silverlight (aplicación de portado de WPF)

La aplicación incluye una clase que hereda de Shape. Anula la propiedad DefiningGeometry para devolver un objeto Path. Sin embargo, la clase Silverlight Shape no tiene una propiedad DefiningGeometry.

Leyendo en Internet He encontrado otros con este mismo problema. La solución parece implicar heredar directamente de Control y establecer la propiedad Content en la ruta. Sin embargo, también quiero retener mis controladores de eventos (MouseEnter, MouseLeave, GotFocus, LostFocus) y me gustaría mantener su posición y cambiar el tamaño proporcionalmente al resto de la aplicación.

Soy principalmente un desarrollador de back-end, así que este no es mi fuerte, agradecería que alguien me diera una muestra del esquema de cómo lograr esto.

+4

Puede obtener más respuestas, si publica la clase original. Luego, otros podrían reescribirlo rápidamente para usted. Buena suerte. –

+0

Este es un problema no resuelto en los foros de silverlight http://forums.silverlight.net/forums/p/39904/113634.aspx e incluso la solución de forma de subclases en Silverlight 4 (http://blogs.msdn.com/b /nickkramer/archive/2009/12/03/subclassing-shape-or-more-accurately-path.aspx) no ayuda con el problema de propiedad de DefininingGeometry. Deberíamos comenzar una recompensa por una solución para esto. – Alain

Respuesta

16

No podrá crear una clase que funcione de la misma manera porque Silverlight no admite la creación de elementos personalizados que se derivan de la clase base Shape.

La razón por la que es imposible crear una forma personalizada en Silveright es que Silverlight no comparte la "capa visual" de WPF. Si quiere entender completamente por qué lo que intenta es imposible, debe comprender cómo Silverlight es muy diferente de WPF aquí. (Y si no le importa, omita los siguientes 2 párrafos).

En WPF, puede trabajar en dos niveles completamente diferentes: la capa visual o la capa de infraestructura. Los servicios de la capa visual son proporcionados por WindowsBase.dll y PresentationCore.dll. Esto proporciona servicios básicos de renderizado y entrada. Pero si desea cosas como el estilo, el enlace de datos, el diseño, la creación de plantillas, etc., necesita los servicios de framework, y PresentationFramework.dll los proporciona. Los tipos de formas - Rectangle, Path, y así sucesivamente - son todos tipos de marcos - derivan de FrameworkElement y admiten el enlace de datos, el diseño, la animación, etc. Pero se implementan en la parte superior de la capa visual: si observas cualquiera de los tipos Shape en Reflector o ILDASM, verás que todos anulan el método OnRender, y ahí es donde vive el código que define la forma real. (OnRender es una función de capa visual.) Y como la capa visual es una API completamente compatible y documentada, puede escribir sus propias formas en WPF; puede escribir exactamente el mismo tipo de código que encontrará en el clases de formas incorporadas.

Silverlight no hace esta distinción visual/framework - en Silverlight, la capa visual de WPF esencialmente se ha colapsado en la capa de framework.Entonces, si observa los tipos de formas en Reflector o ILDASM, verá que no contienen el método OnRender, y están casi vacíos. Eso es porque en Silverlight, las formas son intrínsecas: el complemento tiene un control especial incorporado para Ellipse, Path y todas las demás formas. Entonces, el conjunto de formas no está abierto a la extensión en Silverilght. No hay un método OnRender para anular en Silverlight. Por lo tanto, simplemente no puede escribir su propia clase personalizada derivada de Shape en Silverlight.

Por lo tanto, un Control personalizado o un UserControl será el camino a seguir, me temo. Sin embargo, esto no debería detener el funcionamiento de MouseEnter y MouseLeave. ¿De verdad has encontrado que esos no funcionan? ¿O solo estás asumiendo que no funcionarán?

+0

+1 para conocer su teoría, especialmente para paradigmas que son tan nuevos. – Alain

+0

+1 excelente respuesta – ColinE

+0

+1 como explicación, -1 para Microsoft por su extensibilidad total. –

0

¿Qué ocurre si conservamos su clase existente, permitiéndole llamar CustomShape, como está, entonces inherente desde Control con algo como CustomShapeContainer? CustomShapeContainer básicamente sería un envoltorio alrededor de CustomShape. A continuación, puede pasar todos los eventos que entran en CustomShapeContainer directamente a CustomShape y luego devolver el objeto DefininingGeometry de formas como contenido de Contenedores.

A primera vista, este parece ser el camino de menor resistencia.

0

No tiene los mismos espacios de nombres en Silverlight. Silverlight xaml es un subconjunto de WPF xaml y hay conjuntos que no están incluidos en Silvelright. Estas tecnologías están pensadas para diferentes soluciones tipo os.

Es posible que tenga que comenzar de nuevo. Sin embargo, si usaste el patrón MVVM, muy poco código detrás, entonces podrías volver a usar tu modelo de vista, modelo y servicios. Tal vez los recursos, los estilos estarían bien para reutilizar "tal cual". Pero la Vista: comienza nuevo.

0

Comenzando con Silverlight 3, hay un tipo especial de forma llamada Path que define una propiedad Data de tipo Geometría. Debería poder portar el código WPF original que creó una Geometría a esta propiedad de Datos.

+1

Sé que el artículo de MSDN que enlaza sugiere lo contrario, pero Path ha estado en Silverlight desde el principio. –

Cuestiones relacionadas