2012-06-17 14 views
10

Potrei mancare qualcosa sui fondamenti del design WPF, ma mi chiedevo perché molte proprietà sui controlli WPF sono esposte come il tipo "Oggetto"?Perché molte proprietà in WPF sono un "oggetto" anziché un'interfaccia?

Ad esempio, MenuItem.Icon è un oggetto e quindi MenuItem.ToolTip. Come utente per la prima volta, ciò mi confondeva molto (mi sembrava di utilizzare un linguaggio di programmazione dinamico, non avendo idea se impostare ToolTip su un tipo String funzionasse o meno). Inoltre, ho provato a impostare Icon su un 'System.Drawing.Icon' e ottengo una ArgumentException di "Argument 'picture' deve essere una immagine che può essere utilizzata come un'icona." Non dovresti digitare la proprietà in modo che possa almeno descrivere che cosa dovresti dare nel mondo?

Onestamente, la mia ipotesi sul motivo è perché non è possibile implementare un'interfaccia su un tipo che non è stato creato (senza creare un wrapper), ma è solo un'ipotesi.

Grazie mille per le vostre risposte e approfondimenti!

risposta

2

Il motivo principale a mio parere è che dal momento che uno Object è la "classe base definitiva di tutte le classi nel .Net Framework". Questo ti dà flessibilità, in WPF non sei limitato a un tipo predefinito. Wpf è diverso e ha una curva di apprendimento, ma offre molte più opzioni per creare un prodotto che abbia un bell'aspetto.

cioè

È possibile assegnare un TextBox a una descrizione comandi:

TextBox tb = new TextBox(); 
tb.Text = "Hello World"; 
this.ToolTip = tb; 

una bitmap

BitmapImage myBitmapImage = new BitmapImage(new Uri((@"C:\Temp\20100706.jpg"))); 
Image image = new Image(); 
image.Source = myBitmapImage; 
this.ToolTip = image; 

e assegnando un immagine per un MenuItem

BitmapImage myBitmapImage = new BitmapImage(new Uri((@"C:\Temp\20100706.jpg"))); 
Image image = new Image(); 
image.Source = myBitmapImage; 
menuItem1.Icon = image; 
+0

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

+0

@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. –

+0

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

1

consideri il ToolTip per esempio. Una descrizione comando è un , che può contenere qualsiasi tipo di oggetto CLR (Common Language Runtime) (come una stringa o un oggetto DateTime) o un oggetto UIElement (come un rettangolo o un pannello). Ciò consente di aggiungere contenuti multimediali a controlli come Button e CheckBox.

Per questo motivo, elementi come ToolTip sono esposti come Object, ovvero la radice della gerarchia di tipi (con conseguente facilità d'uso, flessibilità e chiarezza del codice).

0

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.

Problemi correlati