Dans mon application Eclipse RCP, j'ai un arbreViewer qui est une cible de chute pour les fichiers, cela fonctionne bien dans la plupart des cas, mais lorsque j'essaie de faire glisser des fichiers stockés sur un CD-ROM de Windows Explorer au nœud, l'icône indique des gouttes. sont autorisés ne changent pas et ne fait rien.
Puisque les gens semblaient confus sur ma question voici une explication plus détaillée:
Lors de l'exécution du code ci-dessous (fourni par Baz), je suis capable de faire glisser des fichiers et de les déposer dans la zone de texte, lorsque Je traîne un fichier de la plupart des emplacements de ma machine, la fenêtre apparaît comme ceci ->
Le curseur indique que je peux tomber, et lorsque je libère la souris, la méthode maintenant quand Je fais la même chose, mais prenez un fichier d'explorateur qui figure sur un DVD dans mon lecteur optique, alors il ressemble à ceci: indiquant que la goutte n'est pas autorisée, et lorsque je libère la souris, la méthode Il convient également de noter que je suis capable de déposer les mêmes fichiers DVD dans un dossier de l'éclipse Navigator, indiquant que ce n'est pas un problème spécifique à la machine, il doit y avoir quelque chose de différent dans les arbres éclipse cela le permet mais je ne peux pas le voir. Drop (droptargetEvent) est invoquée. 
Drop (DroptargetEvent) est la méthode Pas invoqué.
3 Réponses :
DND ne fonctionne pas comme vous le pensez.
considère télécharger du fichier de Web .
Lorsque vous De même, lorsque vous validez le fonctionnement de la chute, vous ne pouvez pas connaître les données réelles, car il existe Vous ne pouvez donc valider que la liste déroulante en fonction du type de contenu, et non du "contenu réel". Les codes de validation typiques sont les suivants: après avoir accepté "Transferdata", le transfert récupérera les données réelles de la connexion. < p> Alors, rappelez-vous, "transferdata" est différent des données réelles. Le fichier ps: presse-papiers fonctionne de la même manière. FileTransfer récupère les fichiers de la forma d'une chaîne tableau Le chemin absolu vers chaque fichier, pas le fichier Java objet objet.
Merci je savais tout ça. Que suggérez-vous que la réponse au problème est alors?
J'ai fait voté cela moi-même, c'est une information détaillée à coup sûr, mais ce n'est pas une réponse, Jeeyul a supposé que je ne comprends pas comment utiliser la goutte de traînée et que vous attendiez simplement que le fichier se déplace automatiquement. Ce n'est pas le cas.
Il semble que toutes les opérations du MDN n'est pas possible ne sont prises en charge lors d'un périphérique CDROM. Par conséquent, vous devez mettre en œuvre quelques méthodes supplémentaires sur le Droptargetadapter afin de modifier l'opération de chute en cours pour affiner les opérations qui seront réellement effectuées afin que l'OS n'empêche pas la goutte .
J'ai pris votre exemple et je viens de faire la petite modification du droptargettapter
C'est un bon travail là mon bon gars. Donc, essentiellement remplacer le détail pour toujours apparaître comme si c'était une copie? Cela ne causera-t-il pas de comportement étrange pour d'autres types d'événements?
Vous pouvez donc ajouter du code pour être plus sélectif de la "modification" de cet événement. J'ajouterai un certain code à ma réponse qui montre comment vous pouvez "renifler" l'emplacement de ce qui est sur le point d'être abandonné et de faire une certaine détermination quand de modifier et quand de partir seul.
Merci, je vais voir si je peux aussi trouver l'équivalent dans les éclipsers.
Je pense que vous avez mis à jour votre question clarifie quel problème est.
Votre cible de goutte utilisée expéditeur (dans ce cas, coquille du système d'exploitation) refusera la communication du MDN selon laquelle la décision du destinataire est.
Coup d'écran de la vôtre Affiche dnd_move comme indicateur.
Puisque nous ne pouvons pas supprimer des fichiers en lecture seule sur des supports tels que DVD,
dropaccept () vous donne la dernière chance de modifier la demande de communication,
Utilisez-le soigneusement, car plusieurs auditeurs cibles de gouttes par chaque type de transfert peuvent exister. Pour soutenir ce cas, les API du MDN de TreeViewer sont légèrement différentes avec SWT's One.
Avez-vous vérifié si le
transfertype dans la méthode validatedop diffère de celui qui tombe du disque dur?Ce sont des objets transférata qui ne semblent pas avoir de différences de structure majeures, mais l'opération semble toujours être 16 pour les fichiers ROM, tandis que pour les fichiers qui fonctionnent les opérations changent à 2 lorsqu'il est sur un nœud et 16 quand suggère à moi que le nœud ne s'inscrit pas comme une cible viable pour ce qui est traîné. Il est étrange qu'un appel à validationDrop soit fabriqué même s'il n'a aucune intention de vous permettre de le réaliser.
Basé sur le nom
** valider ** goutte () c'est logique. Va faire des recherches un peu. Peut-être que je trouverai une solution.Le nom le fait sonner comme il devrait être chuté, mais dans cette situation, même s'il est vrai que le framework n'essaiera pas de réaliser la chute car il est déjà décidé que la cible est invalide. Merci pour votre temps à l'avance Baz