2009-08-18 6 views

Répondre

8

Ce n'est pas quelque chose que vous pouvez déterminer à partir des événements, car les événements ne font aucune hypothèse sur les besoins ou les capacités de votre application.

L'interprétation d'un drag/drop particulier ayant une sémantique particulière relève de la responsabilité de l'application elle-même - le système d'exploitation ne peut pas savoir comment l'application réagira à la suppression d'un fichier. pour l'utilisateur.

Pour de nombreuses applications, il n'y aura aucune distinction entre copier/déplacer, il y aura simplement glisser-déposer. La distinction copier/déplacer est quelque chose que Windows Explorer s'applique aux opérations sur les fichiers. Pour glisser/déposer "vanille", il applique des règles basées sur les volumes de lecteur d'origine et de destination. Glisser/déposer des fichiers sur un volume est une opération par défaut move. Faire glisser/déposer à travers volumes est un copie, par défaut.

Mais ce ne sont que des règles par défaut déterminées par l'application (Windows Explorer). L'utilisateur peut remplacer ces paramètres par défaut à l'aide de raccourcis clavier lors du glissement et (surtout) lors de la suppression. Mais ceux-ci sont définis et interprétés par l'application particulière - c'est-à-dire Windows Explorer - pas le système d'exploitation. Donc, si votre application est une cible de dépôt pour les fichiers qui peuvent être déplacés de Windows Explorer, et s'il est logique que votre application fasse la distinction entre copier et déplacer, vous devrez peut-être prendre en charge la même modificateurs de clavier que Windows Explorer prend en charge. Je ne crois pas que ce sont modifiables (même si je vous conseille cette confirmer), de sorte que vous pouvez simplement tester l'état de la touche Ctrl ou Maj enfoncées dans vos événements glisser:

Ctrl   = COPY 
Shift  = MOVE 
Ctrl + Shift = MAKE SHORTCUT (if this is applicable to your application) 

GetKeyState() peut être utilisé directement interroger l'état d'une clé spécifique à un moment donné dans le temps.

Si un variant comportement « par défaut » est souhaitée, alors vous devrez appliquer vos propres tests à l'information de source pour déterminer qui par défaut est plus logique (par exemple pour imiter les Explorateur Windows règles par défaut « aux limites de volume »), ou choisissez simplement l'action par défaut la plus appropriée ou la plus intuitive pour votre application.

+0

+1 pour GetKeyState() - mais si les concepts de déplacement et de copie ne sont pas codés en dur dans la VCL, pourquoi le curseur de glissement acquiert un signe "+" (indiquant la copie) lorsque la touche de contrôle est enfoncée. – Roddy

+0

Eh bien, la VCL ne définit pas ce curseur de "copie" pour les opérations de glisser/déposer internes à la VCL, ce n'est donc probablement pas le paramètre * VCL * de ce curseur. Je pense que c'est la VCL * not * qui définit le curseur. Par exemple, l'Explorateur Windows définit le curseur lorsque l'utilisateur appuie sur Ctrl pendant un glissement. Si la cible de suppression ne remplace pas spécifiquement ce curseur, elle ne changera pas (Notepad et PaintShop Pro conservent également le curseur de copie de manière inappropriée, par exemple). Il se peut même que l'application cible ne soit même pas capable de changer le curseur, ce qui pourrait être "possédé" par la source de glissement. Je devrais vérifier. – Deltics

+0

Lors de l'utilisation de DragAcceptFiles() pour recevoir des fichiers à partir de l'Explorateur Windows (la seule façon d'obtenir un curseur + "copier"), il ne semble pas que l'application cible puisse changer le curseur * drag * Le système de glisser-déposer de fichiers Windows envoie uniquement une notification * drop *. Et ce mécanisme n'implique pas les événements de glisser VCL de toute façon. Peut-être que plus d'informations sur votre implémentation spécifique peuvent aider. Utilisez-vous un contrôle glisser-déposer tiers pour prendre en charge la suppression de fichiers, par exemple? – Deltics

0

Vous n'êtes pas sûr de Delphi en particulier, mais en C#, vous vérifiez la propriété AllowedEffect de votre paramètre d'événement. Puisqu'ils relient tous deux à Win32 je ne peux pas imaginer qu'il y ait beaucoup de différence.

http://msdn.microsoft.com/en-us/library/system.windows.forms.drageventargs.aspx a un bon exemple. J'espère que cela t'aides!

+0

Malheureusement aucune aide. La VCL Delphi n'utilise pas les appels Win32 pour son glisser-déposer 'interne', AFAIK. – Roddy

+0

Toujours .. pas besoin de downvote. Je l'ai trouvé utile. +1 –

4

La réponse courte est - vous n'avez pas. Le système de drag-n-drop intégré de la VCL ne distingue pas entre les deux. Vous pouvez cependant dériver vos propres classes TDragObject/Ex pour contrôler le type de données qui est réellement déplacé.

4

Si vous souhaitez utiliser Drag'n'Drop entre votre application et d'autres applications Windows, il vaut la peine de consulter le Drag and Drop Component Suite for Delphi d'Anders Melander.
Le dernier code étant here.

+1

En fait, je l'utilise déjà ;-) – Roddy