Immaginate che queste proprietà siano state digitate come UIElements (o qualche altro oggetto specifico WPF). Come aggiungerei oggetti ai tuoi controlli che non erano UIElements?
Dovresti fornire un wrapper derivato da un oggetto WPF che espone le informazioni richieste. La maggior parte delle volte il wrapper chiamerebbe semplicemente ToString() dell'oggetto da incartare. Visto che la maggior parte dei tipi che utilizzerai fornisce un'implementazione predefinita abbastanza buona di ToString() ha senso chiamarla semplicemente invece di fare in modo che lo sviluppatore scriva i wrapper per tutto.
In secondo luogo, immagina se fossero stati digitati come un'interfaccia. Cosa succede se vuoi comunicare qualcosa che questa interfaccia non può?Le uniche opzioni sono (a) lo sviluppatore vive con le limitazioni del framework o (b) Microsoft aggiorna l'interfaccia e rompe tutto il codice esistente che è già stato scritto.
Considerare inoltre se si utilizza un modello come MVVM. Il design attuale significa che i tuoi modelli di vista possono esporre proprietà che non sono legate a WPF in alcun modo che alla fine rende il tuo codice più riutilizzabile attraverso diverse tecnologie.
Infine, ricorda che esiste una differenza tra l'oggetto che rappresenta la proprietà e il modo in cui WPF esegue il rendering di tali informazioni. PER ESEMPIO. se si utilizza un tipo primitivo come System.String, WPF creerà un blocco di testo e imposta la proprietà text sul risultato di ToString(). Ciò consente una separazione netta tra i dati che viene visualizzato dall'interfaccia utente e che l'informazione è resa dall'interfaccia utente.
prendere un semplice classe che rappresenta una voce di menu, ad esempio:
public class MenuItem
{
public string Text { get; set; }
public bool IsChecked { get; set; }
public bool IsEnabled { get; set; }
}
Questo tipo espone solo i dati sulla voce di menu e non ha informazioni su come queste informazioni dovrebbero essere rese. Infatti, a parte il nome della classe (MenuItem) questo non è nemmeno specifico per una voce di menu e gli stessi dati potrebbero essere utilizzati in un altro controllo dell'interfaccia utente come una lista di controllo selezionata senza modifiche richieste. Se la classe esponeva elementi dell'interfaccia utente specifici per WPF, le informazioni dovevano essere adattate da un altro tipo per ciascun controllo dell'interfaccia utente.
fonte
2012-06-17 11:25:18
Penso che sia bello, ma l'oggetto non deve essere una sorta di elemento dell'interfaccia utente? Sia TextBox sia Image sono FrameworkElements. L'unica cosa che ho visto che puoi assegnare che non è un FrameworkElement è una stringa ... è davvero l'unica cosa? Se così fosse, non sarebbe una buona ragione per essere "Oggetto", dato che potrei semplicemente creare un'etichetta o un wrapper attorno alla mia stringa. – Trevor
@Rovert No, dipende dalla proprietà, se c'è un aspetto visivo e un modo per WPF di convertirlo in un'immagine, quindi verrà mostrato. È possibile assegnare * qualsiasi * a un oggetto. Credo che sia un prodotto di [TypeConversion] (http://msdn.microsoft.com/en-us/library/aa970913.aspx) necessario per far funzionare il markup di Xaml. –
Punto interessante su TypeConversion. Questo ha in realtà molto più senso di come e cosa può decidere di mostrare. Ad esempio, guardando a ImageSource per capire come funzionano, c'è una grande confusione, ma ora so che ci deve essere un comportamento dinamico dietro le quinte. Grazie! – Trevor