Drag and drop vers l'explorateur Windows [Résolu]
A voir également:
- Drag and drop vers l'explorateur windows
- Visual Basic / VB.NET : Drag and drop d'un webbrowser ou explorateur vers composant windows media pl - Guide
- Delphi / Pascal : Drag and drop depuis une application externe et l'explorer windows - CodeS SourceS - Guide
- Visual Basic / VB.NET : Drag'n'drop de l'explorateur vers une listbox - CodeS SourceS - Guide
- Delphi / Pascal : Drag 'n' drop de l'explorateur vers une listview - CodeS SourceS - Guide
- Drag and drop de mon application vb6 vers word (en une ligne de code) - Codes sources - Visual Basic / VB.NET (Divers)
5 réponses
Tu peux te débrouiller pour surveiller le système de fichier et détecter la création d'un fichier bidon que tu envoyes au travers du dragNdrop. Ensuite, après ça, tu sauras dans quel répertoire s'est effectué le dNd et libérer l'explorateur de fichiers.
Console.Out.WriteLine("Warny")
Il y a 10 types de personnes
Ceux qui comptent en binaire... et les autres
Console.Out.WriteLine("Warny")
Il y a 10 types de personnes
Ceux qui comptent en binaire... et les autres
Merci Yes, ça marche très bien, je valide la réponse !
Malheureusement ce n'est valable que si le fichier n'est pas trop gros, ou pas trop long à générer, et donc dans le cas d'un client FTP, ce n'est pas tout à fait adapté. En effet le fichier n'est déplacé vers la cible du drop que quand il est entièrement écrit dans le répertoire temporaire. Si c'est un gros fichier téléchargé à partir d'un serveur FTP, l'explorer reste "freezé" jusqu'à la fin du transfert, ce qui bien sur n'est pas acceptable...
Il n'y aurait aucun problème si l'appli WinForms pouvait connaître la destination finale du fichier, mais j'ai beau chercher, je ne trouve pas. D'ailleurs il semblerait que je ne sois pas le seul à avoir ce problème, vu que même des applications pourtant matures ne semblent capables de gérer ce genre de choses. Exemples :
<li>dans WinRAR, si on drag un fichier d'une archive vers l'explorer, la fenetre cible reste freezée jusqu'à la fin de la décompression.</li><li>dans FileZilla (client FTP, justement...) on peut faire glisser un fichier de l'explorer vers le serveur, mais pas dans l'autre sens</li><li>...</li>Bref, ça m'a tout l'air d'être une impasse... Si quelqu'un a une autre idée, elle est la bienvenue !
Tom
Malheureusement ce n'est valable que si le fichier n'est pas trop gros, ou pas trop long à générer, et donc dans le cas d'un client FTP, ce n'est pas tout à fait adapté. En effet le fichier n'est déplacé vers la cible du drop que quand il est entièrement écrit dans le répertoire temporaire. Si c'est un gros fichier téléchargé à partir d'un serveur FTP, l'explorer reste "freezé" jusqu'à la fin du transfert, ce qui bien sur n'est pas acceptable...
Il n'y aurait aucun problème si l'appli WinForms pouvait connaître la destination finale du fichier, mais j'ai beau chercher, je ne trouve pas. D'ailleurs il semblerait que je ne sois pas le seul à avoir ce problème, vu que même des applications pourtant matures ne semblent capables de gérer ce genre de choses. Exemples :
<li>dans WinRAR, si on drag un fichier d'une archive vers l'explorer, la fenetre cible reste freezée jusqu'à la fin de la décompression.</li><li>dans FileZilla (client FTP, justement...) on peut faire glisser un fichier de l'explorer vers le serveur, mais pas dans l'autre sens</li><li>...</li>Bref, ça m'a tout l'air d'être une impasse... Si quelqu'un a une autre idée, elle est la bienvenue !
Tom
C'est effectivement la solution que j'avais finalement adoptée !
Ce qui est un peu galère c'est qu'il faut surveiller tous les lecteurs séparément, donc autant d'instances de FileSystemWatcher que de lecteurs... Finalement j'ai développé un composant pour gérer ça de façons transparente, ça merche nickel.
Ce qui est un peu galère c'est qu'il faut surveiller tous les lecteurs séparément, donc autant d'instances de FileSystemWatcher que de lecteurs... Finalement j'ai développé un composant pour gérer ça de façons transparente, ça merche nickel.