pourquoi le DatePicker wpftoolkit manger la clé de retour vers le bas événement?

Question

Je me demande si quelqu'un sait pourquoi le datepicker passera les touches standard pour toute la clé de contrôle parent événement routé vers le bas, mais pas la clé de retour?

voici le XAML je l'ai écrit:

    <WrapPanel Name="_wpParameters" 
               Grid.Row="0" Grid.Column="0" 
               Orientation="Horizontal" 
               Grid.IsSharedSizeScope="True"
               Keyboard.KeyDown="_wpParameters_KeyDown" >
        <!-- this is where the dynamic parameter controls will be added -->
    </WrapPanel>

Voici le code que j'utilisais pour vérifier la clé de retour:

private void _wpParameters_KeyDown(object sender, KeyEventArgs e)
{
    if (e.Key == Key.Return)
    {
        RaiseEvent(new RoutedEventArgs(LoadLiveResultsEvent, this));
    }
}

J'utilisais la touche enfoncée sur un accident (destiné à utiliser jusqu'à la clé), mais je l'ai trouvé intéressant que le numérique standard et / caractères ont tiré la logique, mais pas la clé de retour. Toute idée est la raison pour laquelle la clé de retour ne sont pas inclus comme une clé enfoncée la touche?

Answer 1

  

L'événement KeyDown est un niveau inférieur   événement d'entrée de texte qui pourrait ne pas se comporter   comme prévu sur certains contrôles. Cette   est parce que certains contrôles ont le contrôle   compositing ou de manutention classe   fournit une version de niveau supérieur   gestion de saisie de texte et connexes   événements.

consulté sur MSDN .. .mon hypothèse est que le contrôle consomme l'événement et peut-être avoir commis le texte à la source bindable et d'autres nettoyage puis marquer l'événement traité.

Answer 2

En outre dû mentionner ma solution. J'ai eu une vue parent, qui gère l'événement keyDown de tous viewmodels enfants. Je déclarai un comportement pour les contrôles spéciaux comme DatePicker, MaskedTextBox, etc ... que les prises PreviewKeyDown événement tunnel et relance KeyDown événement bouillonnant:

public class EnterPressedBehavior : Behavior<UIElement>
{
    public ICommand EnterPressedCommand { get; private set; }

    protected override void OnAttached()
    {
        base.OnAttached();
        AssociatedObject.PreviewKeyDown += EnterPressed;
    }

    protected override void OnDetaching()
    {
        base.OnDetaching();
        AssociatedObject.PreviewKeyDown -= EnterPressed;
    }

    private void EnterPressed(object sender, KeyEventArgs keyEventArgs)
    {
        if (Keyboard.PrimaryDevice != null && Keyboard.PrimaryDevice.ActiveSource != null)
        {
            var eventArgs = new KeyEventArgs(Keyboard.PrimaryDevice, Keyboard.PrimaryDevice.ActiveSource, 0, keyEventArgs.Key) { RoutedEvent = UIElement.KeyDownEvent };

            AssociatedObject.RaiseEvent(eventArgs);
        }
    }
}

ce comportement attribué à Datepicker:

<DatePicker x:Name="BirthDateDatePicker" Grid.Column="1"
                    Grid.Row="6" Margin="3" HorizontalAlignment="Stretch"                                              
                    IsEnabled="{Binding PersonFieldsEditDenied}"
                    Validation.ErrorTemplate="{StaticResource DefaultValidationTemplate}"
                    AutomationProperties.AutomationId="BirthDateDatePicker">
            <i:Interaction.Behaviors>
                <viewModels:EnterPressedBehavior />
            </i:Interaction.Behaviors>
</DatePicker>

qui est écouté par vue parent:

<Window
       xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
       xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
       Title=""
       KeyDown="OnKeyDownHandler">

Code de derrière:

private void OnKeyDownHandler(object sender, KeyEventArgs e)
    {
        if (e.Key == Key.Enter)
        {
            // your code
        }
    }