Maggio 2019

Volume 34 Numero 5

[XAML]

Controlli XAML personalizzati

Dal Jerry Nixon

Qualità di sviluppatore aziendale, si ha una buona conoscenza SQL Server. Si conoscono i servizi Web di .NET. E, per l'utente, la progettazione di interfacce belle di XAML (probabilmente con Windows Presentation Foundation [WPF]) è un gioco da ragazzi. Analogamente a migliaia di altri sviluppatori di carriera, le tecnologie Microsoft è riempire il curriculum ed ritagliare gli articoli di MSDN Magazine simile alla seguente, per poi aggiungerli alla bacheca Kanban. Ottenere le forbici, questo articolo è posta in gioco nella tabella.

È possibile migliorare le tue competenze con i controlli XAML. Il framework XAML offre una ricca libreria di controlli per lo sviluppo dell'interfaccia utente, ma per portare a termine ciò che si desidera, è più necessario. In questo articolo vi mostrerò come ottenere i risultati desiderati usando i controlli XAML personalizzati.

Controlli personalizzati

Esistono due approcci per la creazione di controlli personalizzati in XAML: i controlli utente e basate su modelli. I controlli utente sono un approccio semplice e facile integrazione con progettazione alla creazione di un layout riutilizzabile. Controlli basati su modelli offrono un layout flessibile con un'API personalizzabile per gli sviluppatori. Come nel caso in qualsiasi lingua, layout sofisticati può generare migliaia di righe di XAML che può essere difficoltosa la navigazione in modo produttivo. Controlli personalizzati sono una strategia efficace per ridurre il codice di layout.

Scelta dell'approccio corretto influirà sulla modalità correttamente è possibile usare e riutilizzare i controlli nell'applicazione. Di seguito sono riportate alcune considerazioni che consentono di iniziare.

Semplicità. Semplice non è sempre semplice, ma solo semplice è sempre facile. Controlli utente sono semplici e pratici. Gli sviluppatori su qualsiasi livello possano recapitarli con poco copertura per la documentazione.

Esperienza di progettazione. Molti sviluppatori piace la finestra di progettazione XAML. Layout di controllo basato su modelli può essere compilato nella finestra di progettazione, ma è il controllo utente in grado di accogliere l'esperienza in fase di progettazione.

Superficie dell'API. Creazione di una superficie dell'API intuitiva consente agli sviluppatori di utilizzarlo con facilità. Controlli utente supportano le proprietà personalizzate, eventi e metodi, ma i controlli basati su modelli sono le più flessibili.

Gli oggetti visivi flessibile. Offrendo un'esperienza predefinita ottimale consente agli sviluppatori di utilizzare i controlli con facilità. I controlli flessibili supportano gli oggetti visivi basati su modelli r. Solo i controlli basati su modelli supportano i modelli di r.

Per sommare, controlli utente sono ottimali per l'esperienza di progettazione e di semplicità, mentre i controlli basati su modelli offrono la migliore superficie dell'API e gli oggetti visivi più flessibili.

Se si decide di iniziare con un controllo utente ed eseguire la migrazione a un controllo basato su modelli, è necessario un lavoro anticipo. Tuttavia, non terminale. Questo articolo inizia con un controllo utente e sposta in un controllo basato su modelli. È importante tenere presente che molti layout riutilizzabile richiedono solo i controlli utente. È anche ragionevole aprire una soluzione line-of-business e individuare i controlli utente e i controlli basati su modelli.

Una nuova storia utente

È necessario consentire agli utenti di fornire il consenso al contratto di licenza dell'utente finale (EULA) nella nuova applicazione. Come si e si sia noto, nessun utente desidera fornire il consenso per un contratto di licenza. Note legali deve comunque, assicurarsi che gli utenti selezionare "Accetto" prima di continuare. Pertanto, anche se le condizioni di licenza è poco chiaro, si intende verificare che l'interfaccia XAML sia in diretta e intuitiva. Si avvia la creazione di prototipi; aggiungere un elemento TextBlock, una casella di controllo, un pulsante, come illustrato nella figura 1, e quindi si avviare alcune riflessioni.

La creazione di prototipi dell'interfaccia utente
Figura 1 UI con prototipo

La creazione di prototipi nella finestra di progettazione XAML è veloce. Ed è facile perché si ha impiegato il tempo necessario per informazioni su strumenti. Ma per quanto riguarda altri form nell'applicazione? Questa funzionalità in un punto potrebbe essere necessario. Incapsulamento è un modello di progettazione usato per nascondere una logica complessa dal consumer. Don ' t repeat personalmente (DRY) è un altro, con particolare attenzione sul riutilizzo del codice.  XAML offre sia tramite i controlli utente e i controlli personalizzati. Gli sviluppatori XAML si conosce i controlli personalizzati sono più potenti rispetto ai controlli utente, ma non si tratta di semplice. Si decide di iniziare con un controllo utente. Forse possibile svolgere il lavoro. Avviso Spoiler: Questo non è possibile.

Controlli utente

Controlli utente sono semplici. Forniscono interfacce riutilizzabili e un codebehind incapsulato e personalizzato. Per creare un controllo utente, selezionare il controllo utente dalla finestra di dialogo Aggiungi nuovo elemento, come illustrato nella figura 2.

Aggiungi finestra di dialogo Nuovo elemento
Figura 2 Aggiungi finestra di dialogo Nuovo elemento

Controlli utente sono in genere un elemento figlio di un altro controllo. Tuttavia, il ciclo di vita è analoga a quella di windows e le pagine che un controllo utente può essere il valore impostato per la proprietà Window.Current.Content. I controlli utente sono complete, che supportano Visual gestione dello stato, alle risorse interne e ogni altro graffatura del framework XAML. Sviluppo di queste App non è una compromissione delle funzionalità disponibili. Il mio obiettivo è per riutilizzarli in una pagina, sfruttare il supporto per la gestione dello stato di Visual, risorse, gli stili e associazione dati. L'implementazione di XAML è semplice e facile integrazione con progettazione:

<UserControl>
  <StackPanel Padding="20">
    <TextBlock>Lorem ipsum.</TextBlock>
    <CheckBox>I agree!</CheckBox>
    <Button>Submit</Button>
  </StackPanel>
</UserControl>

Questo XAML viene eseguito il rendering il prototipo precedente e illustra quanto semplice può essere un controllo utente. Naturalmente, vi è alcun comportamento personalizzato ancora, solo il comportamento predefinito dei controlli che viene dichiarato.

Il percorso rapido testo EULA è lunghi, pertanto è necessario indirizzare le prestazioni di testo. TextBlock (e solo l'elemento TextBlock) è stato ottimizzato per usare il percorso rapido, di memoria insufficiente e per il rendering della CPU. Si è progettato per essere veloci, ma è possibile potrebbero alterare che:

<TextBlock Text="Optimized" />
<TextBlock>Not optimized</TextBlock>

Usare TextBlock inline controlli come < eseguire / > e < LineBreak / > si interrompe di ottimizzazione. Le proprietà come CharacterSpacing, LineStackingStrategy e TextTrimming possono eseguire la stessa. Sembra complicato. C'è un semplice test:

Application.Current.DebugSettings
  .IsTextPerformanceVisualizationEnabled = true;

IsTextPerformanceVisualizationEnabled è un'impostazione di debug poco nota che è possibile visualizzare il testo nell'applicazione è ottimizzata quando esegue il debug. Se il testo non è verde, è tempo da analizzare.

Con ogni versione di Windows, meno proprietà compromettere il percorso rapido; Tuttavia, esistono ancora diversi problemi che in modo imprevisto e influire negativamente sulle prestazioni. Un piccolo intenzionale eseguendo il debug, ciò non rappresenta un problema.

Le regole non modificabile esistono opinioni tante poiché sono presenti opzioni per dove risiederà la logica di business. In generale mette modificabili a meno regole più vicino al controllo. Si tratta in genere più facile e veloce e ottimizza la manutenibilità.

Regole di business, l'altro, sono diverse dalla convalida dei dati. Rispondere alle immissioni di dati e il controllo per gli intervalli di lunghezza e numeriche di testo è semplicemente la convalida. Regole determinano i tipi di comportamento degli utenti.

Ad esempio, una banca ha una regola business non per concedere un prestito per i clienti con un punteggio di credito di sotto di un particolare valore. Un ruolo di idraulico ha una regola a non a un cliente all'esterno di un determinato codice postale di viaggio. Le regole sono sul comportamento. In alcuni casi, le regole di modificare ogni singolo giorno, ad esempio nuovi prestiti di influenzare i punteggi di carta di credito. In altri casi, le regole mai cambiano, ad esempio come un meccanico mai non funzionerà su un Subaru meno recente 2014.

Si consideri ora criteri di accettazione: Un utente non è possibile fare clic sul pulsante fino a quando non è selezionata la casella di controllo. Si tratta di una regola e mantenuti è non modificabile, poiché è possibile ottenere. Voglio implementarla vicino al mio controlli:

<StackPanel Padding="20">
  <TextBlock>Lorem ipsum.</TextBlock>
  <CheckBox x:Name="AgreeCheckBox">I agree!</CheckBox>
  <Button IsEnabled="{Binding Path=IsChecked,
    ElementName=AgreeCheckBox}">Submit1</Button>
  <Button IsEnabled="{x:Bind Path=AgreeCheckBox.IsChecked.Value,
    Mode=OneWay}">Submit2</Button>
</StackPanel>

In questo codice, l'associazione dati perfettamente soddisfa il requisito. Il pulsante Submit1 Usa l'associazione di dati WPF (e della piattaforma UWP) classico. Il pulsante Submit2 Usa l'associazione di dati moderna piattaforma UWP.

Si noti che nel figura 3 Submit2 abilitato. Si tratta di giusto? Beh, in Progettazione di Visual Studio, associazione dati classica ha il vantaggio di rendering in fase di progettazione. Per ora, associazione dati compilati (X:Bind) si verifica solo in fase di esecuzione. Scelta tra l'associazione dati classica e compilata è la decisione di facile più difficile che si intende verificare. Binding compilato da un lato, è veloce. Tuttavia, nell'associazione altri, classico è semplice. Binding compilato esiste al problema di prestazioni difficile dell'indirizzo XAML: associazione dati. Poiché l'associazione classica richiede reflection di runtime, è intrinsecamente più lento, faticano a scalare.

Implementazione di una regola di Business con l'associazione dati
Figura 3 implementazione di una regola di Business con il Data Binding

Molte nuove funzionalità sono stati aggiunti all'associazione classico, ad esempio di associazione asincrona. e diversi modelli di dispongano emersa per aiutare gli sviluppatori. Ancora, come UWP postured riesca WPF, tuttavia aveva lo stesso problema di trascinamento. Di seguito è un aspetto da considerare: La possibilità di utilizzare l'associazione classico in modalità asincrona non è stata trasferita a UWP da WPF. Leggere in che cosa si desidera, ma incoraggiare gli sviluppatori aziendali a investire nel binding compilato. Binding compilato sfrutta il generatore di codice XAML, la creazione di code-behind automaticamente e l'accoppiamento tra le istruzioni di associazione con proprietà reale e i tipi di dati previsto in fase di esecuzione.

A causa di questo accoppiamento, tipi non corrispondenti possono verificarsi errori, di come può provare a eseguire l'associazione a oggetti anonimi o oggetti JSON dinamici. Questi casi limite non vengono esclusi dal molti sviluppatori, ma sono state perse:

  • Binding compilato risolve i problemi di prestazioni del data binding e presenta alcuni vincoli.
  • Compatibilità con le versioni precedenti mantiene il supporto dell'associazione classico offrendo contemporaneamente agli sviluppatori UWP un'opzione migliore.
  • Sono investiti innovazione e miglioramenti al data binding in binding compilato, associazione non classico.
  • Funzionalità quali associazione di funzione sono disponibili solo con binding compilato in cui strategia Microsoft di associazione è chiaramente concentrata.

La semplicità e la fase di progettazione supporta ancora di distribuzione classica associazione mantiene l'argomento attivo, premendo il tooling team di Microsoft developer per continuare a migliorare l'esperienza di sviluppatore e binding compilato. Si noti che in questo articolo, la scelta di uno o l'altra avrà un impatto quasi-illimitate offerte dal. Alcuni degli esempi verrà illustrata l'associazione classico mentre altri utenti visualizzano binding compilato. Spetta all'utente decidere. La decisione, naturalmente, è più significativa nelle app di grandi dimensioni.

Eventi personalizzati eventi personalizzati non possono essere dichiarati in XAML, in modo da gestirli nel codice il sottostante. Ad esempio, è possibile inoltrare l'evento click del pulsante di invio a un evento click personalizzati nel controllo utente:

public event RoutedEventHandler Click;
public MyUserControl1()
{
  InitializeComponent();
  SubmitButton.Click += (s, e)
    => Click?.Invoke(this, e);
}

In questo caso, il codice genera gli eventi personalizzati, l'inoltro di RoutedEventArgs dal pulsante. Utilizzo di sviluppatori grado di gestire in modo dichiarativo, questi eventi come ogni altro evento in XAML:

<controls:MyUserControl1 Click="MyUserControl1_Click" />

Il valore è che dispendiosa in termini di sviluppatori non dovranno avere un nuovo paradigma; i controlli personalizzati e out-infrastrutture proprietarie funzionalmente hanno lo stesso comportamento.

Proprietà personalizzate per permettere agli sviluppatori dispendiosa in termini di fornire le proprie EULA, posso impostare l'attributo X:FieldModifier sul controllo TextBlock. Ciò consente di modificare il comportamento di compilazione XAML dal valore privato predefinito:

<TextBlock x:Name="EulaTextBlock" x:FieldModifier="public" />

Ma semplice non significa valida. Questo metodo offre una piccola astrazione e richiede che gli sviluppatori comprendere la struttura interna. È inoltre necessario codebehind. Pertanto, eviteranno utilizzando l'approccio dell'attributo in questo caso:

public string Text
{
  get => (string)GetValue(TextProperty);
  set => SetValue(TextProperty, value);
}
public static readonly DependencyProperty TextProperty =
  DependencyProperty.Register(nameof(Text), typeof(string),
    typeof(MyUserControl1), new PropertyMetadata(string.Empty));

Altrettanto facile né le avvertenze: è una proprietà di dipendenza dei dati con associazione a proprietà Text del TextBlock. In questo modo lo sviluppatore dispendiosa in termini di leggere, scrivere o eseguire l'associazione alla proprietà di testo personalizzata:

<StackPanel Padding="20">
  <TextBlock Text="{x:Bind Text, Mode=OneWay}" />
  <CheckBox>I agree!</CheckBox>
  <Button>Submit</Button>
</StackPanel>

La proprietà di dipendenza è necessaria per supportare il data binding. Controlli affidabile supportano casi di uso di base come l'associazione dati. Inoltre, la proprietà di dipendenza consente di aggiungere una sola riga alla mia base di codice:

<TextBox Text="{x:Bind Text, Mode=TwoWay,
  UpdateSourceTrigger=PropertyChanged}" />

Data binding bidirezionale per le proprietà personalizzate in controlli utente è supportata senza INotifyPropertyChanged. Questo avviene perché le proprietà di dipendenza generano eventi modificati interni che consente di monitorare il framework di associazione. Tratta proprio dell'INotifyPropertyChanged.

Il codice precedente lavoriate che UpdateSourceTrigger determina quando sono registrate le modifiche. I valori possibili sono Explicit, LostFocus e PropertyChanged. Quest'ultimo si verifica quando vengono apportate modifiche.

Ostacoli dispendiosa in termini di sviluppatore potrebbe essere necessario impostare la proprietà di contenuto del controllo utente. Si tratta di un approccio intuitivo, ma non è supportata da tutti i controlli utente. La proprietà è già impostata sul XAML è stata dichiarata:

<Controls:MyUserControl>
  Lorem Ipsum
</Controls:MyUserControl>

Questa sintassi sovrascrive la proprietà di contenuto: TextBlock, la casella di controllo e il pulsante. Se prende in considerazione del modello di un caso d'uso XAML base, il controllo utente non riesce offrire un'esperienza completa e affidabile. Controlli utente sono facili, ma offrono controllo offrivano estendibilità. Una sintassi intuitiva e supporto di re-creazione di modelli fanno parte di un'esperienza comune. È possibile prendere in considerazione un controllo basato su modelli.

Controlli basati su modelli

XAML ha visto grandi miglioramenti nel consumo di memoria, prestazioni, accessibilità e coerenza visiva. Gli sviluppatori amano XAML in quanto è flessibile. Controlli basati su modelli sono nella fattispecie.

I controlli basati su modelli possono definire qualcosa di completamente nuovo, ma è in genere composto da diversi esistenti controlli. In questo esempio di un controllo TextBlock, casella di controllo e pulsante insieme è un tipico scenario.

Non confondere l'altro, i controlli basati su modelli con i controlli personalizzati. Un controllo basato su modelli è un layout personalizzato. Un controllo personalizzato è semplicemente una classe che eredita un controllo esistente senza elementi relativi allo stile personalizzato. In alcuni casi, se tutto quello che serve è un ulteriore metodo o una proprietà su un controllo esistente, i controlli personalizzati sono un'ottima opzione; loro gli oggetti visivi e per la logica sono già presenti e si sta semplicemente estenderle a.

Modello di controllo layout di un controllo è definito da un oggetto ControlTemplate. Questa risorsa particolare viene applicata in fase di esecuzione. Ogni finestra e pulsante si trova nell'oggetto ControlTemplate. Un modello di controllo sono facilmente accessibili per la proprietà del modello. Tale proprietà di modello non è in sola lettura. Gli sviluppatori possono impostarlo a un oggetto ControlTemplate personalizzato, la trasformazione di oggetti visivi di un controllo e il comportamento per soddisfare le proprie esigenze particolari. Che sarà la potenza di re-creazione di modelli:

<ControlTemplate>
  <StackPanel Padding="20">
    <ContentControl Content="{TemplateBinding Content}" />
    <CheckBox>I agree!</CheckBox>
    <Button>Submit1</Button>
  </StackPanel>
</ControlTemplate>

ControlTemplate XAML è simile a qualsiasi altra dichiarazione di layout. Nel codice precedente, si noti che l'estensione di markup TemplateBinding speciale. Questa associazione speciale è ottimizzata per le operazioni di modello unidirezionale. Poiché Windows 10 versione 1809, X:Bind sintassi è supportata nelle definizioni di un oggetto ControlTemplate UWP. In questo modo per le associazioni di funzioni nei modelli e ad alte prestazioni, compilato e bidirezionali. TemplateBinding funziona nella maggior parte dei casi.

Generic. XAML per creare un controllo basato su modelli, selezionare controllo basato su modelli nella finestra di dialogo Aggiungi nuovo elemento. Ciò introduce tre file: il file XAML. il codebehind; e themes/generic.xaml, che contiene l'oggetto ControlTemplate. Il file themes/generic.xaml è identico a WPF. È speciale. Il framework di unirla in risorse dell'app automaticamente. Le risorse definite qui hanno come ambite a livello di applicazione:

<Style TargetType="controls:MyControl">
  <Setter Property="Template">
    <Setter.Value>
      <ControlTemplate TargetType="controls:MyControl" />
    </Setter.Value>
  </Setter>
</Style>

ControlTemplate vengono applicati utilizzando gli stili impliciti: stili senza una chiave. Stili espliciti dispongono di una chiave utilizzata per applicarli ai controlli. stili impliciti vengono applicati in base a TargetType. Pertanto, è necessario impostare DefaultStyleKey:

public sealed class MyControl : Control
{
  public MyControl() => DefaultStyleKey = typeof(MyControl);
}

Questo codice imposta DefaultStyleKey, che determina quali stile viene applicato in modo implicito per il controllo. Lo imposto sul valore corrispondente di TargetType in ControlTemplate:

<ControlTemplate TargetType="controls:MyControl">
  <StackPanel Padding="20">
    <TextBlock Text="{TemplateBinding Text}" />
    <CheckBox Name="AgreeCheckbox">I agree!</CheckBox>
    <Button IsEnabled="{Binding IsChecked,
      ElementName=AgreeCheckbox}">Submit</Button>
  </StackPanel>
</ControlTemplate>

TemplateBinding Associa proprietà Text del TextBlock alla proprietà di dipendenza personalizzate copiate dal controllo utente per il controllo basato su modelli. TemplateBinding è un modo molto efficiente e in generale l'opzione migliore.

Figura 4 Mostra il risultato del mio lavoro nella finestra di progettazione. Il layout personalizzato dichiarati in ControlTemplate viene applicato al controllo personalizzato e l'associazione viene eseguita e viene eseguito il rendering in fase di progettazione:

 

<controls:MyControl Text="My outside value." />

Visualizzare in anteprima in modo trasparente utilizzando le proprietà interne
Figura 4 Preview in modo trasparente utilizzando le proprietà interne

La sintassi per usare il controllo personalizzato è semplice. Creerò una migliore, consentendo allo sviluppatore di usare testo inline. Si tratta la sintassi più intuitiva per impostare il contenuto di un elemento. XAML fornisce un attributo di classe per Aiutami a tale scopo, come figura 5 Mostra.

Figura 5 usando l'attributo di classe per impostare la proprietà di contenuto

[ContentProperty(Name = "Text")]
public sealed class MyControl : Control
{
  public MyControl() => DefaultStyleKey = typeof(MyControl);
  public string Text
  {
    get => (string)GetValue(TextProperty);
    set => SetValue(TextProperty, value);
  }
  public static readonly DependencyProperty TextProperty =
    DependencyProperty.Register(nameof(Text), typeof(string),
      typeof(MyControl), new PropertyMetadata(default(string)));
}

Si noti che l'attributo ContentProperty, che proviene dallo spazio dei nomi Windows.UI.Xaml.Markup. Indica a quale proprietà diretta, deve essere scritto il contenuto in linea dichiarato in XAML. Pertanto, a questo punto, è possibile dichiarare contenuto personale simile al seguente:

<controls:MyControl>
  My inline value!
</controls:MyControl>

È accattivante. Controlli basati su modelli offrono la flessibilità per la progettazione di interazioni tra i controlli e la sintassi in qualunque modo sembra più intuitivo per l'utente. Figura 6 Mostra il risultato di introdurre ContentProperty al controllo.

Anteprima di progettazione
Figura 6 anteprima di progettazione

Il ContentControl dove in precedenza era necessario creare una proprietà personalizzata ed eseguire il mapping di tale proprietà per il contenuto del controllo, XAML offre un controllo già compilato adatto. È noto come ContentControl e impostarne la proprietà viene chiamata il contenuto. ContentControl fornisce anche le proprietà ContentTemplate e ContentTransition per gestire la visualizzazione e le transizioni. Pulsante, casella di controllo, Frame e molti controlli XAML standard ereditano ContentControl. Data mining potrebbero essere, un computer remoto. Utilizzerà solo contenuto invece del testo:

public sealed class MyControl2 : ContentControl
{
  // Empty
}

In questo codice, si noti che la sintassi concisa per creare un controllo personalizzato con una proprietà di contenuto. ContentControl auto-esegue il rendering come ContentPresenter quando dichiarati. È una soluzione semplice e rapida. C'è tuttavia uno svantaggio: ContentControl non supporta le stringhe letterali in XAML. Perché viola il mio obiettivo per rendere il controllo supporta le stringhe letterali, applicato al controllo, prendere in considerazione ContentControl un secondo momento.

L'accesso ai controlli interni la direttiva X:Name dichiara il nome del campo generato automaticamente in un codebehind. Assegnare un X:Name di MyCheckBox una casella di controllo e il generatore viene creato un campo nella classe denominata MyCheckBox.

Invece di X:Key (solo per le risorse) non è possibile creare un campo. Aggiunge le risorse a un dizionario di tipi non risolti fino a quando non vengono innanzitutto utilizzati. Per le risorse, X:Key offre miglioramenti delle prestazioni.

Poiché X:Name crea un campo sottostante, non può essere usato in un oggetto ControlTemplate; i modelli vengono disaccoppiati da qualsiasi classe sottostante. Al contrario, utilizzare la proprietà Name.

Nome è una proprietà di dipendenza in FrameworkElement, un predecessore del controllo. Utilizzarla quando non è possibile usare x: il nome. Nome e X:Name si escludono a vicenda in un determinato ambito a causa di FindName.

FindName è un metodo XAML utilizzato per individuare gli oggetti in base al nome; funziona con nome o l'attributo X:Name. È affidabile nel codebehind, ma non in controlli basati su modelli in cui è necessario usare GetTemplateChild:

protected override void OnApplyTemplate()
{
  if (GetTemplateChild("AgreeCheckbox") is CheckBox c)
  {
    c.Content = "I really agree!";
  }
}

GetTemplateChild è un metodo helper utilizzato nell'override OnApplyTemplate per trovare controlli creati da un oggetto ControlTemplate. Usato per trovare i riferimenti a controlli interni.

La modifica del modello del modello di controllo è semplice, ma ho creato la classe in modo da prevedere i controlli con determinati nomi. Devo assicurarmi che il nuovo modello gestisce questa dipendenza. Creiamo un oggetto ControlTemplate di nuovo:

<ControlTemplate
  TargetType="controls:MyControl"
  x:Key="MyNewStyle">

Piccole modifiche a un oggetto ControlTemplate sono normali. Non è necessario iniziare da zero. Nel riquadro della struttura di documenti Visual Studio, fare doppio clic su qualsiasi controllo ed estrarre una copia del relativo modello corrente (vedere figura 7).

L'estrazione di un modello di controllo
Figura 7 l'estrazione di un modello di controllo

Se conservano le relative dipendenze, mio nuovo ControlTemplate può modificare completamente gli oggetti visivi e i comportamenti di un controllo. La dichiarazione di uno stile esplicito per il controllo indica al framework di ignorare lo stile predefinito implicito:

<controls:MyControl Style="{StaticResource MyControlNewStyle}">

Ma questo riscrittura di ControlTemplate viene fornito con un messaggio di avviso. Gli sviluppatori e progettisti di controllo necessario prestare attenzione supportare le funzionalità di accessibilità e localizzazione. È facile rimuovere questi elementi per errore.

TemplatePartAttribute sarebbe utile se un controllo personalizzato è stato possibile comunicare gli elementi denominati prevede di ricevere. Alcuni elementi denominati possono essere necessarie solo durante i casi limite. In WPF, è necessario TemplatePartAttribute:

[TemplatePart (
  Name = "EulaTextBlock",
  Type = typeof(TextBlock))]
public sealed class MyControl : Control { }

Questa sintassi viene illustrato come il controllo può comunicare le dipendenze interne per gli sviluppatori esterni. In questo caso, prevede che un elemento TextBlock con il nome EulaTextBlock nella mio ControlTemplate. È anche possibile specificare gli stati visivi che offrono il controllo personalizzato:

[TemplateVisualState(
  GroupName = "Visual",
  Name = "Mouseover")]
public sealed class MyControl : Control { }

TemplatePart viene utilizzato da Blend con TemplateVisualState agli sviluppatori di Guida rispetto alle aspettative durante la creazione di modelli personalizzati. Un oggetto ControlTemplate può essere convalidato rispetto ai attribuzioni di questi. Poiché 10240, WinRT ha inserito tali attributi. Piattaforma UWP possono usarle, ma non di Blend per Visual Studio. Questi rimangono una procedura ottima dei problemi, ma la documentazione è comunque l'approccio migliore.

Accessibilità controlli XAML proprietarie vengono meticolosamente progettati e testati per essere accessibile, compatibile e accattivante. Requisiti di accessibilità sono ora cittadini di prim'ordine e i requisiti di versione per ogni controllo.

Quando si ri-modello di un controllo proprietarie, si mettono a rischio la funzionalità di accessibilità scrupoloso aggiunte dai team di sviluppo. Questi sono difficili da ottenere right e semplice errato. Quando si sceglie di reimpostare come modelli un controllo, dovrebbe essere buona familiarità con le funzionalità di accessibilità di framework e le tecniche per la relativa implementazione. In caso contrario, si perde una parte considerevole del loro valore.

Aggiunta di accessibilità come un requisito di versione consente non solo quelli con esigenze particolari permanente, ma anche gli utenti che sono temporaneamente subisca. Riduce inoltre rischio quando controlla prima parte del modello.

L'operazione è stata!

Dopo l'aggiornamento da un controllo utente a un controllo basato su modelli, ho presentato un minimo di codice nuovi. Ma ho aggiunto diverse funzionalità. Si consideri quali sono state eseguite complessiva.

Incapsulamento. Il controllo è una raccolta di diversi controlli, unite in bundle con oggetti visivi personalizzati e comportamenti che gli sviluppatori dispendiosa in termini di riutilizzare con facilità un'applicazione.

La logica di business. Il controllo incorpora regole business che soddisfano i criteri di accettazione della storia utente. Ho inserire le regole non modificabile vicino al controllo e un'esperienza avanzata in fase di progettazione, è supportato anche.

Eventi personalizzati. Il controllo espone eventi personalizzati di specifica del controllo come ad esempio "fare clic su" che aiutano gli sviluppatori interagiscono con il controllo, senza la necessità di comprendere la struttura interna del layout.

Proprietà personalizzate. Il controllo espone le proprietà per consentire allo sviluppatore dispendiosa in termini di influenzare il contenuto del layout. Si è trattato in modo da supportare completamente l'associazione di dati XAML.

Sintassi dell'API. Il controllo supporta un approccio intuitivo che consente agli sviluppatori di dichiarare il contenuto con le stringhe letterali e in modo semplice. Utilizzato l'attributo ContentProperty a questo scopo.

I modelli. Il controllo viene fornito con un oggetto ControlTemplate che un'interfaccia intuitiva viene disposto predefinito. Tuttavia, XAML del modello è supportato per consentire agli sviluppatori di consumer personalizzare gli oggetti visivi in base alle esigenze.

È molto da fare

Il controllo deve essere più, ma non molto altro ancora, ovvero un po' particolare attenzione a layout (ad esempio la necessità di scorrere verso il testo di grandi dimensioni) e alcune proprietà (ad esempio, il contenuto della casella di controllo). Sono incredibilmente chiudere.

I controlli possono supportare la gestione dello stato Visual, una funzionalità nativa di XAML che consente di modificare proprietà basato su eventi di ridimensionamento o gli eventi del framework (ad esempio, al passaggio del mouse). Controlli maturi presentano gli stati di visualizzazione.

I controlli possono supportare la localizzazione. la funzionalità nativa nella piattaforma UWP Usa i controlli di associazione direttiva X:Uid con stringhe si Indicizzano che vengono filtrate dalle impostazioni locali attive. Controlli maturi supportano la localizzazione.

I controlli possono supportare le definizioni di stile esterno per facilitare l'aggiornamento gli oggetti visivi senza richiedere un nuovo modello; Ciò può comportano gli oggetti visivi condivisi e sfruttare i temi e stili BasedOn. Controlli maturi condividono e riusare gli stili.

Conclusioni

La creazione di prototipi un'interfaccia utente in XAML è veloce. Controlli utente creano con facilità i layout semplici e riutilizzabili. I controlli basati su modelli richiedono maggiore impegno per creare layout semplici e riutilizzabili con capacità più sofisticate. L'approccio giusto è compito dello sviluppatore, basato su una notevole esperienza e conoscenza. rsperimento. Per apprendere gli strumenti, più produttivi si acquisirà.

Windows Form Visual Basic 6 è riuscito nel 2002, esattamente come WPF ha avuto esito positivo di Windows Form nel 2006. Portare con esso in WPF XAML: un linguaggio dichiarativo per l'interfaccia utente. Gli sviluppatori Microsoft non aveva mai nulla di simile a XAML. Oggi, Xamarin e UWP portare XAML per iOS, Android, HoloLens, Surface Hub, Xbox, IoT e i desktop moderno. In effetti, XAML è ora la tecnologia di creazione del sistema operativo Windows stesso.

XAML la gioia degli sviluppatori in tutto il mondo perché è così la produttività e flessibile. I tecnici Microsoft sono la stessa. Poiché si sta sviluppando la propria App e anche Windows 10 con XAML. Il futuro è chiaro, gli strumenti sono potenti e la tecnologia è più accessibile che mai.


Jerry Nixonè un senior software tecnico e architetto nella progettazione Software commerciale Microsoft. Ha sviluppato ed destinati due decenni di software. Relatore, organizzatore, docente e autore, Nixon è anche l'host di DevRadio. La maggior parte del suo giorni impiegata insegnare suo tre figlie backstories "Star Trek" e vengono tracciati episodio.

Grazie per i seguenti esperti Microsoft per la revisione dell'articolo: Daniel Jacobson, Dmitry Lyalin, Daren May, Ricardo Minguez Pablos


Discutere di questo articolo nel forum di MSDN Magazine