2009-09-03 9 views
15

Sto convertendo un'app WPF in Silverlight.Forma personalizzata in Silverlight (porting app da WPF)

L'app include una classe che eredita da Shape. Sostituisce la proprietà DefiningGeometry per restituire un oggetto Path. Tuttavia, la classe Silverlight Shape non ha una proprietà DefiningGeometry.

Leggere su internet ho trovato altri con lo stesso problema. La soluzione sembra coinvolgere direttamente l'ereditarietà di Control e l'impostazione della proprietà Content sul percorso. Tuttavia, voglio anche conservare i miei gestori di eventi (MouseEnter, MouseLeave, GotFocus, LostFocus) e vorrei che mantenga la sua posizione e ridimensiona proporzionalmente al resto dell'applicazione.

Sono principalmente uno sviluppatore di back-end, quindi questo non è il mio forte. Sarei grato se qualcuno potesse fornirmi un esempio di come ottenere ciò.

+4

È possibile ottenere più risposte, se si pubblica la classe originale. Quindi altri potrebbero riscriverlo rapidamente per te. In bocca al lupo. –

+0

Questo è un problema irrisolto sui forum silverlight http://forums.silverlight.net/forums/p/39904/113634.aspx e anche la soluzione della forma di sottoclasse in silverlight 4 (http://blogs.msdn.com/b /nickkramer/archive/2009/12/03/subclassing-shape-or-more-accurately-path.aspx) non aiuta con il problema di proprietà DefiningGeometry. Dovremmo iniziare una taglia su una soluzione per questo. – Alain

risposta

16

Non sarà possibile produrre una classe che funzioni allo stesso modo poiché Silverlight non supporta la creazione di elementi personalizzati che derivano dalla classe base Shape.

Il motivo per cui è impossibile creare una forma personalizzata in Silveright è che Silverlight non condivide il "livello visivo" di WPF. Se vuoi comprendere appieno il motivo per cui ciò che stai cercando è impossibile, devi capire in che modo Silverlight è molto diverso da WPF qui. (E se non ti interessa, salta i prossimi 2 paragrafi.)

In WPF, puoi lavorare su due livelli completamente diversi: il livello visivo o il livello quadro. I servizi del livello visivo sono forniti da WindowsBase.dll e PresentationCore.dll. Questo fornisce servizi di rendering e input di base. Ma se vuoi cose come lo styling, l'associazione dei dati, il layout, i template e così via, hai bisogno dei servizi framework e questi sono forniti da PresentationFramework.dll. I tipi di forme - Rectangle, Path e così via - sono tutti tipi di framework - derivano dallo FrameworkElement e supportano l'associazione dati, il layout, l'animazione e così via. Ma sono implementati sopra il livello visivo - se guardi uno qualsiasi dei tipi Shape in Reflector o ILDASM vedrai che tutti hanno la precedenza sul metodo OnRender, ed è qui che vive il codice che definisce la forma attuale. (OnRender è una funzione di livello visivo.) E poiché il livello visivo è un'API pienamente supportata e documentata, sei libero di scrivere le tue forme in WPF - puoi scrivere esattamente lo stesso tipo di codice che troverai nel classi di forma incorporate.

Silverlight non rende questa distinzione visiva/struttura: in Silverlight, il livello visivo di WPF è essenzialmente collassato nel livello framework.Quindi, se guardi i tipi di forma in Reflector o ILDASM, vedrai che non contengono il metodo OnRender e sono quasi vuoti. Questo perché in Silverlight, le forme sono tutte intrinseche: il plug-in ha una gestione speciale integrata per Ellipse, Path e tutte le altre forme. Quindi l'insieme delle forme non è aperto all'estensione in Silverilght. Non esiste un metodo OnRender per eseguire l'override in Silverlight. Quindi non puoi semplicemente scrivere la tua classe personalizzata che deriva da Shape in Silverlight.

Quindi, sia un Control personalizzato o un UserControl sarà la strada da percorrere, temo. Ciò non dovrebbe tuttavia impedire il funzionamento di MouseEnter e MouseLeave. Hai davvero scoperto che quelli non funzionano? O stai solo dando per scontato che non funzioneranno?

+0

+1 per conoscere la tua teoria, in particolare per i paradigmi così nuovi. – Alain

+0

+1 risposta eccellente – ColinE

+0

+1 per la spiegazione, -1 a Microsoft per l'estensibilità totale. –

0

Cosa succede se mantenere la classe esistente, consente di chiamarlo CustomShape, come è, quindi inerente al controllo con qualcosa come CustomShapeContainer? CustomShapeContainer sarebbe essenzialmente solo un wrapper attorno a CustomShape. È quindi possibile passare tutti gli eventi che arrivano in CustomShapeContainer direttamente in CustomShape e quindi restituire l'oggetto DefininingGeometry delle forme come contenuto dei Contenitori.

A prima vista, questo sembra il percorso di minor resistenza.

0

Non si dispone degli stessi spazi dei nomi in Silverlight. Silverlight xaml è un sottoinsieme di WPF xaml e ci sono degli assembly che non sono inclusi in Silvelright. Queste tecnologie sono destinate a diverse soluzioni os di tipo.

Potrebbe essere necessario ricominciare. Tuttavia, se si utilizzava lo schema MVVM, un codice molto piccolo, si potrebbe essere in grado di riutilizzare ViewModel, Model e servizi. Forse le risorse, gli stili sarebbero OK per riutilizzare "così com'è". Ma la vista: inizia nuova.

0

Partendo con Silverlight 3, v'è un particolare tipo di Shape denominata Path che definisce una proprietà Data di tipo geometria. Dovresti essere in grado di eseguire il porting del codice WPF originale che ha creato una Geometria in questa proprietà Data.

+1

So che l'articolo MSDN che colleghi suggerisce in altro modo, ma Path è stato in Silverlight sin dall'inizio. –