AccessText
è un FrameworkElement
che agisce più o meno come un particolare tipo di TextBlock
che permette a qualsiasi carattere della tastiera dopo una singola sottolineatura (_
) per agire come chiave di accesso.
Per un dato controllo, il comportamento dei tasti di accesso associati dipende dal suo metodo OnAccessKey
. OnAccessKey
è un metodo virtuale di UIElement
, che fornisce le seguenti definizioni:
protected virtual void OnAccessKey(AccessKeyEventArgs e)
{
this.Focus();
}
Quindi, qualsiasi controllo che non esclude la definizione di OnAccessKey
definita da UIElement
manterrà il comportamento predefinito, che è per il controllo sia messo a fuoco quando viene premuto il tasto di accesso.
ButtonBase
, che Button
eredita, ha la seguente definizione per OnAccessKey
:
protected override void OnAccessKey(AccessKeyEventArgs e)
{
if (e.IsMultiple)
base.OnAccessKey(e);
else
this.OnClick();
}
Così il comportamento predefinito di Button
e altri controlli che ereditano da ButtonBase
sarà quello di portare il controllo della messa a fuoco, se IsMultiple
è vero , altrimenti, genererà l'evento click. (IsMultiple
è true se una chiave di accesso è associata a più di uno UIElement
.)
Con queste premesse in mente, qui ci sono le risposte alle vostre domande specifiche:
Il comportamento definitiva di un elemento AccessText
utilizzato come di un controllo ContentPresenter
è quello di registrare la prima lettera dopo una singola sottolineatura con il AccessKeyManager
, che invocherà il metodo OnAccessKey
del controllo quando si preme il tasto. Sapere cosa questo farà per un particolare controllo richiede la conoscenza della definizione di OnAccessKey
per quel controllo. Se non ci sono sostituzioni nella catena di ereditarietà, premendo il tasto di accesso si mette a fuoco il controllo. Se è presente un override, il comportamento dipenderà dalla definizione del metodo prevalente. Questo può essere determinato tramite la sperimentazione, la lettura della documentazione pertinente o l'esame del codice sorgente.
AccessText
è un FrameworkElement
per gli stessi motivi che TextBlock
è un FrameworkElement
. Ha una forma visiva e occupa spazio che il sistema di layout deve prendere in considerazione quando posiziona altri elementi relativi ad esso. Inoltre, lo stile FrameworkElements
consente lo styling e possiedono la propria proprietà DataContext
, che consente di ottenere scenari vincolanti che altrimenti non sarebbero possibili. Se AccessText
non fosse uno FrameworkElement
, sarebbe inutilmente limitante e impedirebbe ragionevoli (anche se forse rari) casi d'uso che gli sviluppatori WPF potrebbero avere.
Modifica
Ecco un esempio di un pulsante di accensione di fantasia che dimostra l'utilità di AccessText
essere un FrameworkElement
:
<Grid>
<Button Width="150"
Height="35"
Command="{Binding PowerCommand}">
<StackPanel Orientation="Horizontal">
<TextBlock Text="Status" />
<Rectangle Margin="5,2,0,0"
Width="10"
Height="10"
Fill="{Binding PowerFill}" />
<AccessText Margin="25,0,0,0"
Text="{Binding PowerText}" />
</StackPanel>
</Button>
</Grid>
Questo si traduce in (dopo aver premuto Alt):

Dopo aver cliccato sul pulsante, o premendo Alt + S, il modello di vista sarebbe rispondere al comando cambiando il Text
e Fill
, con conseguente questo:

clic o utilizzando il tasto di accesso ritornerebbe al primo stato.
@KyloRen, ho tentato di dare un po 'di più alla risposta n. – devuxer
cosa deve probabilmente associare uno sviluppatore WPF nella classe AccessText? –
* che cosa ha probabilmente bisogno di associare uno sviluppatore WPF nella classe AccessText? * Sicuramente la proprietà 'Text', e possibilmente cose come' Margin', 'Foreground',' FontWeight' e 'FontStyle'. * So che posso impostare un layout per una classe di testo di accesso, ma sarà sempre un bisogno? * Aggiungerò un esempio. Ti sento che avere uno speciale "FrameworkElement" solo per questo scopo era una scelta di design strana. Non sono sicuro del motivo per cui non hanno semplicemente aggiunto una proprietà 'RecognizesAccessKey' a' TextBlock' e lo chiamano un giorno. – devuxer