---

Août 2015

Volume 30, numéro 8

Cet article a fait l'objet d'une traduction automatique.

Windows 10 - Modern Drag and Drop pour Windows Applications universelles

Par Alain Zanchetta

Cet article est basé sur le publique preview de Windows 10 et Visual Studio 2015.

Glisser- d├⌐poser est une manière intuitive pour transférer les données dans une application ou entre applications sur le bureau Windows. Il fait ses débuts dans Windows 3.1 avec le gestionnaire de fichiers et a été ensuite étendu à toutes les applications supportant OLE 2, telles que Microsoft Office. Quand Windows 8 a été libéré, Microsoft a introduit un nouveau type d'application Windows, appelé un app Store de Windows, qui a été conçu pour les tablettes et toujours affiché en mode plein écran. Parce qu'une demande a été visible à un moment donné, goutte et inter-applications drag n'a pas de sens et autres moyens de partage de données, tels que le charme de part, ont été développés. Dans Windows 10, cependant, les applications sur un ordinateur de bureau PC sont encore en cours d'exécution en mode fenêtré, ce qui signifie que plusieurs fenêtres sont affichées sur l'écran, et donc faire glisser et déposer fait un come-back comme une application Universal Windows API, avec l'ajout de nouvelles fonctionnalités qui améliorent l'UX.

Concepts de Drag-and-Drop

Glisser- d├⌐poser permet à l'utilisateur de transférer des données entre les applications ou au sein d'une application utilisant un geste standard (presse-attente-et-pan avec le doigt) ou la presse-et-pan avec une souris ou un stylet.

La source de glissement, ce qui est de l'application ou la zone où le geste de drag est déclenché, fournit les données à transférer en remplissant un objet de paquet de données qui peut contenir des formats de données standard, y compris le texte, RTF, HTML, bitmaps, de stockage ou des formats de données personnalisés. La source indique également le type d'opérations, qu'il prend en charge : copier, déplacer ou lien. Lorsque le pointeur est relâché, chute se produit. La cible de déplacement, ce qui est de la demande ou la zone située sous le pointeur, traite l'ensemble de données et retourne le type d'opération qu'il effectuée.

Pendant l'opération glisser / déplacer, la traînée UI fournit une indication visuelle du type d'opération de drag-and-drop qui se déroule. Cette rétroaction visuelle est initialement fournie par la source, mais peut être modifiée par les cibles que le pointeur se déplace au-dessus d'eux.

Drop et drag moderne est disponible sur le bureau, tablette et téléphone. Il permet le transfert de données entre ou au sein de tout type d'application, y compris les applications Windows classique, bien que cet article se concentre sur l'API de XAML pour la goutte et drag moderne.

Mise en œuvre de Drag and Drop

La cible de source et de la chute de drag jouent des rôles différents. Une application peut ont les composants d'interface utilisateur qui sont uniquement des sources de traînée, seulement drop cibles ou les deux, comme l'exemple d'application Photo Booth sur la Figure 1.

Figure 1 Drag Sources et cibles de dépôt

Une opération de glisser-déplacer est entraînée entièrement par des entrées d'utilisateur, donc sa mise en œuvre est presque exclusivement basé sur des événements, comme le montre Figure 2.

Figure 2 Drag et Drop événements

Mettre en œuvre une Source faites glisser dans Windows 8.1, un ListView peut être la source d'une opération de glisser-déplacer en app si sa propriété CanDragItems est définie sur true :

<ListView CanDragItems="True"
          DragItemsStarting="ListView_DragItemsStarting"
          ItemsSource="{Binding Pictures}"
          ItemTemplate="{StaticResource PictureTemplate}"
          />

L'application peut gérer l'événement DragItemsStarting sur la source. C'est toujours pris en charge dans Windows 10 avec l'ajout d'un événement DragItemsCompleted, qui n'était pas nécessaire dans les applications Windows 8.1 où source et cible doivent appartenir au même processus.

La source de glissement de la main pour moderne glisser- d├⌐poser est le UIElement, qui donne accès à toutes les fonctionnalités de drag-and-drop modernes et est le principal objectif du présent article.

Faire UIElement déplaçable consiste à définir sa propriété CanDrag sur true. Cela peut être fait dans la balise ou dans le codebehind. Le cadre XAML gère la reconnaissance de mouvement et déclenche l'événement DragStarting pour indiquer le début d'une opération glisser. L'application doit configurer le DataPackage en remplissant son contenu et en indiquant quelles opérations sont prises en charge. L'application source peut mettre différents formats dans le DataPackage, qui rendra compatible avec plus de cibles, comme le montre Figure 3. Les opérations prises en charge sont définies dans le type DataPackageOperation et peuvent être copie, déplacement, de lien ou de toute combinaison de ceux-ci.

Figure 3 DragStarting de manutention et de remplir le DataPackage

private void DropGrid_DragStarting(UIElement sender,
  DragStartingEventArgs args)
{
  if (Picture == null)
  {
    args.Cancel = true;
  }
  else if (_fileSource != null)
  {
    args.Data.RequestedOperation =
      DataPackageOperation.Copy | DataPackageOperation.Move;
    args.Data.SetStorageItems(new IStorageItem[] { _fileSource });
  ...
}

Vous pouvez annuler l'opération de glisser dans le gestionnaire d'événements en définissant la propriété Cancel du paramètre DragStartingEventArgs ; par exemple, dans notre exemple d'application, un espace réservé d'image commencera une opération glisser que si elle a reçu une image ou un fichier.

Le gestionnaire de DragStartingEvent est aussi l'endroit où l'application source peut personnaliser la traînée UI, qui est expliqué plus loin dans cet article.

Dans certains cas, l'application pourrait à utiliser un geste spécial pour lancer une opération de glisser-déplacer, ou voulez autoriser le glissement d'un contrôle dont les interactions normales interfèrent avec le geste de drag-and-drop, par exemple, la zone de texte, qui a déjà réagit aux événements de pointeur vers le bas en changeant sa sélection. Dans ces cas, l'application peut implémenter sa propre détection de mouvement et ensuite lancer une opération de glisser-déplacer en appelant la méthode StartDragAsync. Notez que cette méthode attend un identificateur de pointeur et, par conséquent, impossible de démarrer une opération de glisser-déplacer avec les périphériques non standards, comme un capteur Kinect. Une fois que StartDragAsync est appelée, le reste de l'opération de glisser- d├⌐poser suit le même schéma que si CanDrag = True avait été utilisée, dont l'événement DragStarting.

Une fois que l'utilisateur a relâché le pointeur, l'opération de glisser-déplacer est terminée et la source est avertie par le biais de l'événement DropCompleted, qui contient la DataPackageOperation retournée par la cible sur laquelle l'utilisateur a relâché le pointeur, ou DataPackageOperation.None si le pointeur a été libéré sur une cible qui n'accepte pas les données ou si annuler a été pressé :

private void DropGrid_DropCompleted(UIElement sender, DropCompletedEventArgs args)
{
  if (args.DropResult == DataPackageOperation.Move)
  {
    // Move means that we should clear our own image
    Picture = null;
    _bitmapSource = null;
    _fileSource = null;
  }
}

StartDragAsync retourne une IAsyncOperation < DataPackageOperation > ; l'application source peut gérer la fin de l'opération en attente sur la IAsyncOperation ou en gérant l'événement DropCompleted. Par programmation annulation après le DragStarting événement est possible grâce à l'interface IAsyncOperation, mais peut être inquiétant pour l'utilisateur.

Notez que bien que tant la traînée de ListView et baisse et le UIElement glisser- d├⌐poser sont mises en œuvre sur les mêmes services système et sont entièrement compatibles, ils ne soulèvent pas les mêmes événements du côté de la source. Autrement dit, si un ListView a sa propriété CanDragItems la valeur true, seuls les DragItemsStarting et les DragItemsCompleted sont déclenchés. DragStarting et DropCompleted sont des événements liés à la propriété CanDrag de l'UIElement.

Mise en œuvre d'une cible Drop n'importe quel UIElement peut être une cible de déplacement fourni sa propriété AllowDrop la valeur true. Lors d'une opération de glisser-déplacer, les événements suivants peuvent être déclenchés sur une cible : DragEnter, DragOver, DragLeave et Drop. Ces événements existent déjà au point 8.1 de Windows, mais la classe DragEventArgs a été étendue dans Windows 10 pour donner aux applications d'accéder à toutes les fonctionnalités de moderne glisser / déplacer. Lorsque vous gérez un événement de drag-and-drop, l'application cible doit tout d'abord inspecter le contenu de la DataPackage par le biais de la propriété de l'objet DataView de l'argument d'événement ; dans la plupart des cas, vérifiant la présence d'une données type est suffisant, et il peut être fait de façon synchrone. Dans certains cas, comme avec les fichiers, l'application pourrait avoir à vérifier le type des fichiers disponibles avant d'accepter ou ignorer le DataPackage. C'est une opération asynchrone et exige l'application cible pour prendre un report et le compléter plus tard (ce modèle est détaillé plus loin dans cet article).

Une fois que la cible a déterminé si elle peut traiter les données, il doit définir la propriété AcceptedOperation de l'instance de DragEventArgs pour permettre au système fournir la rétroaction de droite à l'utilisateur.

Notez que si l'application retourne DataTransferOperation.None—or une opération ne pas acceptée par la source — de gestionnaire d'événements drop ne tiendra même si l'utilisateur relâche le pointeur au-dessus de la cible ; l'événement DragLeave sera déclenché à la place.

L'application peut gérer DragEnter ou DragOver ; la AcceptedOperation retournée par DragEnter est conservée si DragOver n'est pas géré. Comme DragEnter est appelée une seule fois, il devrait être préféré à DragOver pour des raisons de performances. Toutefois, dans le cas de cibles imbriquées, il faut retourner la valeur correcte de DragOver, dans le cas où une cible parent pourrait substituer (paramètre Handled sur true empêche l'événement de propagation jusqu'à parent). Dans l'exemple d'application, chaque espace réservé photo vérifie les images dans le DataPackage et achemine l'événement vers la grille parent uniquement si aucune image n'est disponible, qui permet à la grille d'accepter le texte même s'il est physiquement supprimée sur un espace réservé (voir Figure 4).

Figure 4 gérant DragEnter et en inspectant DataPackage

private async void DropGrid_DragEnter(object sender, DragEventArgs e)
{
  if (!App.IsSource(e.DataView))
  {
    bool forceMove = ((e.Modifiers & DragDropModifiers.Shift) ==
      DragDropModifiers.Shift);
    if (e.DataView.Contains(StandardDataFormats.Bitmap))
    {
      _acceptData = true;
      e.AcceptedOperation = (forceMove ? DataPackageOperation.Move :
        DataPackageOperation.Copy);
      e.DragUIOverride.Caption = "Drop the image to show it in this area";
      e.Handled = true;
    }
    else if (e.DataView.Contains(StandardDataFormats.StorageItems))
    {
      // Notify XAML that the end of DropGrid_Enter does
      // not mean that we have finished to handle the event
      var def = e.GetDeferral();
      _acceptData = false;
      e.AcceptedOperation = DataPackageOperation.None;
      var items = await e.DataView.GetStorageItemsAsync();
      foreach (var item in items)
      {
        try
        {
          StorageFile file = item as StorageFile;
          if ((file != null) && file.ContentType.StartsWith("image/"))
          {
            _acceptData = true;
            e.AcceptedOperation = (forceMove ? DataPackageOperation.Move :
              DataPackageOperation.Copy);
            e.DragUIOverride.Caption = "Drop the image to show it in this area";
            break;
          }
        }
        catch (Exception ex)
        {
          Debug.WriteLine(ex.Message);
        }
      }
      e.Handled = true;
      // Notify XAML that now we are done
      def.Complete();
    }
  }
  // Else we let the event bubble on a possible parent target
}

Concepts avancés

Personnalisation de la rétroaction visuelle les seuls commentaires que OLE 2 faites glisser puis goutte fourni était de changer le curseur de la souris selon la réponse de la cible de l'événement DragOver. Drop et drag moderne permet des scénarios plus avancés comme la rétroaction visuelle fournie à l'utilisateur est plus riche. La traînée de l'interface utilisateur se compose de trois parties : contenu visuel, glyphe et légende.

Le contenu visuel représente les données glissées. Il pourrait être déplacé UIElement (si la source est une application XAML) ; une icône standard choisie par le système basé sur le contenu de la DataPackage ; ou une image personnalisée définie par l'application.

Le glyphe reflète le type d'opération acceptée par la cible. Cela peut prendre quatre formes différentes, correspondant aux valeurs du type DataPackageOperation. Elle ne peut être personnalisée par les applications, mais il peut être masqué.

La légende est une description donnée par la cible. Selon l'application cible, une opération de copie peut-être, par exemple, l'ajout d'une chanson à une playlist, le téléchargement d'un fichier à OneDrive ou une copie de fichier simple. La légende permet des commentaires plus précis que le glyphe et joue un rôle très semblable à une info-bulle.

La table de Figure 5 montre comment la source et la cible peuvent personnaliser ces différentes parties. Lorsque le pointeur n'est pas sur une cible de dépôt, la traînée UI est exactement ce que la source a configuré. Lorsque le pointeur se trouve sur une cible de déplacement, certaines parties du visuel peuvent être substituées par la cible ; tous les remplacements sont désactivées lorsque le pointeur quitte la cible.

Figure 5 personnalisations disponibles à la Source et la cible

	Source	Target
Contenu visuel	Par défaut = élément déplacé Pouvez utiliser le contenu généré par le système, basé sur DataPackage Pouvez utiliser toute image bitmap	Par défaut = ce qui a été défini par la source Ne pouvez pas utiliser le contenu généré par le système Pouvez utiliser toute image bitmap Pouvez afficher ou masquer
Glyphe	Pas d'accès	Aspect basé sur AcceptedOperation Pouvez afficher ou masquer
Caption	Pas d'accès	Pouvez utiliser n'importe quelle chaîne Pouvez afficher ou masquer

Lorsqu'une opération glisser-déplacer commence, si l'application source ne cherche pas à personnaliser la traînée de l'interface utilisateur dans le gestionnaire d'événements DragStarting, un instantané de l'UIElement déplacé est pris par XAML et utilisé comme le contenu de l'interface utilisateur de glisser. Le UIElement initial est toujours affiché dans sa position initiale, qui est un comportement différent de ListView, où les ListViewItems déplacés sont cachés à leur position initiale. Parce que la capture instantanée de l'UIElement déplacé est prise après que l'événement DragStarting a été déclenché, il est possible de déclencher un changement d'état visuel lors de cet événement pour modifier la capture instantanée. (Notez qu'État de UIElement est également altérée et, même si elle est restaurée, un léger scintillement pourrait arriver.)

Lorsque vous gérez un événement de DragStarting, la source de glissement peut personnaliser la rétroaction visuelle par le biais de la propriété de DragUI de la classe DragStartingEventArgs. Par exemple, demander au système d'utiliser le contenu de la DataPackage pour générer le contenu visuel se fait par l'intermédiaire de SetContentFromDataPackage, comme le montre Figure 6.

La figure 6 en utilisant SetContentFromDataPackage pour générer le contenu visuel

private void DropGrid_DragStarting(UIElement sender, DragStartingEventArgs args)
{
  ...
  if (_fileSource != null)
  {
    args.Data.RequestedOperation = DataPackageOperation.Copy | DataPackageOperation.Move;
    args.Data.SetStorageItems(new IStorageItem[] { _fileSource });
    args.DragUI.SetContentFromDataPackage();
  }
  else if (_bitmapSource != null)
  {
    args.Data.RequestedOperation = DataPackageOperation.Copy | DataPackageOperation.Move;
    args.Data.SetBitmap(_bitmapSource);
    args.DragUI.SetContentFromDataPackage();
  }
}

Vous pouvez définir une image personnalisée comme le contenu de la traînée de l'interface utilisateur à l'aide de deux classes différentes : la classe BitmapImage XAML bien connue ou une nouvelle classe de Windows 10, SoftwareBitmap. Si cette image bitmap est une ressource de l'application, il est plus facile d'utiliser un BitmapImage et initialisez-la avec l'URI de la ressource :

private void SampleBorder_DragStarting(UIElement sender, DragStartingEventArgs args)
{
  args.Data.SetText(SourceTextBox.SelectedText);
  args.DragUI.SetContentFromBitmapImage(new BitmapImage(new Uri(
    "ms-appx:///Assets/cube.png", UriKind.RelativeOrAbsolute)));
}

Si la bitmap doit être générée à la volée Lorsque l'opération glisser démarre ou lorsque le pointeur entre dans une cible de déplacement, un SoftwareBitmap peut être créée dans la zone tampon générée par la classe RenderTargetBitmap XAML, qui génère une image bitmap contenant la représentation visuelle d'un UIElement, comme indiqué dans Figure 7. Ce UIElement doit être dans l'arborescence visuelle XAML mais n'a pas besoin d'être sur la partie visible de la page. Parce que RenderTargetBitmap fait ce rendu de façon asynchrone, il est nécessaire de prendre un report ici pour XAML sache si la bitmap n'est pas prête lorsque le gestionnaire d'événements est terminé et attend que le report à remplir pour mettre à jour le contenu de l'interface utilisateur de glisser. (Nous allons vous expliquer le mécanisme de report plus en détail dans la section suivante de cet article.)

Figure 7 personnalisation contenu UI Drag avec RenderTargetBitmap et SoftwareBitmap

private async void PhotoStripGrid_DragStarting(UIElement sender, DragStartingEventArgs args)
{
  if ((Picture1.Picture == null) || (Picture2.Picture == null)
    || (Picture3.Picture == null) || (Picture4.Picture == null))
  {
    // Photo Montage is not ready
    args.Cancel = true;
  }
  else
  {
    args.Data.RequestedOperation = DataPackageOperation.Copy;
    args.Data.SetDataProvider(StandardDataFormats.Bitmap, ProvideContentAsBitmap);
    App.SetSource(args.Data);
    var deferral = args.GetDeferral();
    var rtb = new RenderTargetBitmap();
    const int width = 200;
    int height = (int)(.5 + PhotoStripGrid.ActualHeight / PhotoStripGrid.ActualWidth
                         * (double)width);
    await rtb.RenderAsync(PhotoStripGrid, width, height);
    var buffer = await rtb.GetPixelsAsync();
    var bitmap = SoftwareBitmap.CreateCopyFromBuffer(buffer, BitmapPixelFormat.Bgra8, width, height,
                                                                    BitmapAlphaMode.Premultiplied);
    args.DragUI.SetContentFromSoftwareBitmap(bitmap);
    deferral.Complete();
  }
}

Bien sûr, si le SoftwareBitmap a déjà été généré — et il pourrait être mis en cache pour les opérations ultérieures de drag-and-drop — aucun report n'est nécessaire.

Pour les SetContentFromBitmapImage et SetContentFromSoftwareBitmap, vous pouvez spécifier un point d'ancrage qui indique comment positionner la traînée de l'interface utilisateur par rapport à la position du pointeur. Si vous utilisez la surcharge sans paramètre de point d'ancrage, le coin supérieur gauche de l'image bitmap personnalisé suivra le pointeur. La méthode DragStartingEventArgs GetPosition retourne la position du pointeur par rapport à n'importe quel UIElement, qui peut être utilisé pour définir la position de départ de la traînée UI exactement où le UIElement déplacé se trouve.

Du côté de la cible, les différentes parties du visuel déplacé peuvent être personnalisé dans les gestionnaires d'événements DragEnter ou DragOver. Personnalisation faite par le biais de la propriété DragUIOverride de la classe DragEventArgs, qui expose les quatre méthodes de SetContentFrom identiques à DragUI sur le côté de la source, ainsi que quatre propriétés qui vous permettent de masquer les différentes parties de la DragUI et modifier la légende. Enfin, DragUIOverride expose également une méthode Clear qui réinitialise tous les remplacements de la DragUI faite par la cible.

Les opérations asynchrones The Windows Universal Applications API applique un modèle asynchrone pour toutes les opérations qui peuvent prendre plus de quelques millisecondes. Ceci est particulièrement critique dans le cas de glisser / déplacer, que ces opérations sont entièrement pilotées par l'utilisateur. En raison de sa richesse, glisser- d├⌐poser utilise trois différents modes asynchrones : appels asynchrones, les reports et les rappels.

Les appels asynchrones sont utilisées lorsque l'application appelle un système API qui peut prendre un certain temps pour terminer. Ce modèle est maintenant bien connu par les développeurs de Windows et est rendu simple par l'async et attendent les mots-clés en c# (ou create_task, puis en C++). Toutes les méthodes qui extraient des données de DataPackage suivent ce modèle, tels que GetBitmapAsync, dont notre exemple d'application utilise pour récupérer une référence d'image flux, comme le montre Figure 8.

Figure 8 utilisation des appels asynchrones à lire la DataPackage

private async void DropGrid_Drop(object sender, DragEventArgs e)
{
  if (!App.IsSource(e.DataView))
  {
    bool forceMove = ((e.Modifiers & DragDropModifiers.Shift) ==
      DragDropModifiers.Shift);
    if (e.DataView.Contains(StandardDataFormats.Bitmap))
    {
      // We need to take a deferral as reading the data is asynchronous
      var def = e.GetDeferral();
      // Get the data
      _bitmapSource = await e.DataView.GetBitmapAsync();
      var imageStream = await _bitmapSource.OpenReadAsync();
      var bitmapImage = new BitmapImage();
      await bitmapImage.SetSourceAsync(imageStream);
      // Display it
      Picture = bitmapImage;
      // Notify the source
      e.AcceptedOperation = forceMove ? DataPackageOperation.Move :
        DataPackageOperation.Copy;
      e.Handled = true;
      def.Complete();
    }
...
}

Produits reportés sont utilisées lorsque le cadre XAML rappelle dans le code d'une application qui pourrait lui-même émettre un appel asynchrone avant de retourner une valeur attendue par le cadre. Ce modèle n'était pas largement utilisé dans les versions précédentes du langage XAML, nous allons donc prendre le temps de l'analyser. Lorsqu'un bouton génère un événement Click, c'est un aller simple appel en ce sens qu'aucune valeur ne doit être retourné par l'application. Si un appel asynchrone est effectué par l'application, son résultat sera disponible après la fin du gestionnaire d'événements Click, mais c'est parfaitement bien, parce que ce gestionnaire ne retourne pas une valeur.

En revanche, lorsque XAML déclenche un DragEnter ou DragOver, un événement, elle prévoit que l'application de définir la propriété AcceptedOperation des arguments d'événement pour indiquer si le contenu de la DataPackage peut être géré. Si l'application ne se soucie du type de données disponibles à l'intérieur de la DataPackage, ce encore faire de manière synchrone, par exemple :

private void DropTextBox_DragOver(object sender, DragEventArgs e)
{
  bool hasText = e.DataView.Contains(StandardDataFormats.Text);
  e.AcceptedOperation = hasText ? DataPackageOperation.Copy :
    DataPackageOperation.None;
}

Toutefois, si, par exemple, l'application peut accepter que certains types de fichier, il ne doit pas seulement vérifier les types de données à l'intérieur de la DataPackage, il doit accéder à des données, aussi bien, qui ne peuvent être faites de façon asynchrone. Cela signifie que l'exécution du code est suspendue jusqu'à ce que les données ont été lues et que le gestionnaire d'événements DragEnter (ou DragOver) sera terminé avant l'application sait si elle peut accepter des données. Ce scénario est exactement le but de l'ajournement : en obtenant un report de l'objet DragEventArg, l'application indique XAML qu'elle différera certains de son traitement, et en remplissant le report, l'application avertit XAML que ce traitement est effectué et les propriétés de sortie de l'instance de DragEventArgs ont été définies. Renvoyer à Figure 4 de voir comment notre exemple d'application vérifie StorageItems après avoir obtenu un report.

Le report peut également servir lors de la personnalisation du contenu UI glisser sur le côté de la cible requiert des opérations asynchrones telles que de la méthode RenderAsync de la RenderTargetBitmap.

Du côté de la source d'une opération de glisser-déplacer, DragStartingEvent­Args expose un report, trop, dont le but est de permettre l'exploitation de commencer dès que le gestionnaire d'événements met fin (même si le report n'a pas été terminé) afin de fournir la rétroaction plus rapide à l'utilisateur, même si la création d'une bitmap pour personnaliser l'interface utilisateur de glisser prend un certain temps.

Les rappels sont utilisés dans le DataPackage de reporter fournissant les données jusqu'à ce qu'il est vraiment nécessaire. Avec ce mécanisme, l'application source peut annoncer plusieurs formats dans le DataPackage, mais que les données réellement lues par une cible devra être établi et transmis. Dans de nombreux cas, le rappel ne sera jamais appelé — par exemple, si aucune cible ne peut comprendre le format de données correspondant — qui est une belle performance d'optimisation.

Notez que, dans de nombreux cas, fournissant les données réelles exigera un appel asynchrone et, par conséquent, le DataProviderRequest paramètre de ce rappel expose un report pour que les applications peuvent avertir qu'ils ont besoin de davantage de temps fournir les données et alors que les données sont disponibles, comme le montre Figure 9.

La figure 9, reportant les données jusqu'à ce qu'elle est lue

private void DeferredData_DragStarting(UIElement sender,
  DragStartingEventArgs args)
{
  args.Data.SetDataProvider(StandardDataFormats.Text, ProvideDeferredText);
}
async void ProvideDeferredText(DataProviderRequest request)
{
  var deferral = request.GetDeferral();
  var file = await KnownFolders.DocumentsLibrary.GetFileAsync(fileName);
  var content = await FileIO.ReadTextAsync(file);
  request.SetData(content);
  deferral.Complete();
}

Synthèse

Lorsque vous écrivez une application qui manipule des formats de données standard tels que des fichiers, des images ou du texte, vous devez envisager d'implémenter drag et drop puisqu'il s'agit d'une opération naturelle et bien connue des utilisateurs. Les bases du glisser / déplacer sont déjà familiers à ceux qui ont programmé avec Windows Forms et Windows Presentation Foundation, qui réduit la courbe d'apprentissage de cette fonctionnalité riche, avec ses concepts spécifiques telles que la personnalisation de l'interface utilisateur de glisser et les modèles relativement non utilisés tels que le motif de report. Si vous voulez juste pour soutenir les scénarios de base drag-and-drop, vous pouvez compter sur votre expérience antérieure et ont une implémentation simple ou, si vous préférez, vous pouvez exploiter pleinement les nouvelles fonctionnalités pour fournir une expérience personnalisée à l'utilisateur.

---

Anna Pai est ingénieur logiciel sur l'équipe Xbox. Elle a précédemment travaillé sur Silverlight, Silverlight pour Windows Phone puis XAML pour Windows et Windows Phone.

Alain Zanchetta est ingénieur en logiciels de l'équipe de XAML Windows. Il a été un architecte dans la division Conseil de Microsoft France.

Merci à l'expert technique Microsoft suivant d'avoir relu cet article : Clément Fauchère
Clement Fauchere est ingénieur logiciel en équipe de Shell Windows chez Microsoft.