Discussion :

[FarookFreeman]

Bonjour,


Je souhaite réaliser des opération de DnD d'une application que je créé vers l'explorateur windows.

J'aimerai savoir quel(s) protocole(s) réseau utilise l'explorateur windows pour récupérer les fichiers dans le cas où ces fichiers sont sur un PC distant.

Un dieu vivant pourrait il me répondre ?

[matazz]

Va voir ici c'est un treeView avec exploratin réseaux, je pense que tu doit avoir les appels aux API windows qui font ça http://www.codeguru.com/Cpp/controls...icle.php/c729/

[matazz]

T'as aussi ce lien sur les réseaux :http://www.codeguru.com/Cpp/I-N/network/

[Aurelien.Regat-Barrel]

As-tu essayé de désigner le fichier source par son nom UNC (\\serveur\path) ?

[FarookFreeman]

As-tu essayé de désigner le fichier source par son nom UNC (\\serveur\path) ? >> le pb, c'est que je ne souhaite pas passer par ça : c'est trop restreint ça ne marche qu'en réseau local il me semble. Du moins je n'ai jamais réussi à accéder à quelque PC que ce soit hors de mon réseau local.

J'explique le contexte :

Je suis en train de créer un client/serveur de fichier. Du moment que le serveur de fichier est executé sur le serveur et que ce serveur est connecté au net, tous les PC pourront y accéder avec des authentifications/permissions. C'est à peu de chose pret un ftp, sauf que là tous les lecteurs du serveur pourront etre accédés.

J'ai donc mon serveur de fichier propre. Je souhaiterais connaitre le protocole de l'explorateur windows, savoir comment il fait pour accéder aux ressources du réseau, voir quels protocoles il utilise.

L'autre solution serait de récupérer les fichiers draggé (qui sont sur les PC distants) sur le PC local, puis de faire le transfert ensuite vers l'explorateur. Mais cela suppose savoir bloquer l'explorateur windows pednat le téléchargement des fichiers distants.

[FarookFreeman]

J'ai regardé les URL. J'ai vu des samples intéressantes mais aucune ne traite du sujet en question.

En fait, si j'ai dit des bêtises dans le post précédent, n'hésitez pas à me le signaler . (L'ignorant n'est pas béni).

[Aurelien.Regat-Barrel]

Normalement c'est pas limité au réseau local, c'est plutot les firewall qui bloquent ça en dehors à mon avis.
Le protocole du partage de fichiers de Windows c'est NetBIOS je crois. Ca s'utilise avec les fonctions Net*
http://msdn.microsoft.com/library/en-us/netmgmt/netmgmt/about_network_management.asp
http://win32.mvps.org/network/nfe.html
Mais si t'utilises une désignation UNC il me semble que ça marche de manière transparente, réseau local ou non. Maintenant si un firewall bloque ton serveur...

L'autre solution serait de récupérer les fichiers draggé (qui sont sur les PC distants) sur le PC local, puis de faire le transfert ensuite vers l'explorateur. Mais cela suppose savoir bloquer l'explorateur windows pednat le téléchargement des fichiers distants.

j'ai pas bien pigé en fait. Tu cherches à utiliser le protocole de partage de fichiers Windows ou simplement faire un drag & drop de fichier depuis une appli vers l'explorer ?

[FarookFreeman]

Je sais je suis un peu confus, mais c'est parce que je cherche les outils adéquats.

Le problème est le suivant :

Lors d'un drag de mon appli vers l'explorateur windows, les données de transfert (description des fichiers draggés) est contenu en mémoire.
0/ Lors du drop dans l'explorateur windows, l'explorateur récupère la description en mémoire et tente de récupérer les fichiers, ce qui n'est pas possible (voir 1/, 2/ et 3/)

Or, mon appli est en fait un pseudo-explorer qui visualise le système de fichier d'un PC distant en se connectant à un serveur de fichier que j'ai commencé à implémenter.
1/ Par conséquent, les fichiers draggé n'existent pas en local, et peuvent appartenir à un PC linux.
2/ De plus, la notion de partage ne sera pas implémenté, donc tous les volumes du PC distant seront accessibles depuis mon appli.
3/ Autrement dit, l'UNC étant lié au partage du PC en question, elle ne sera pas suffisante, et le protocole NETBIOS n'est dans ce cas là pas adéquate.



Je reviens à ce que j'avais mal dit dans le post précédent :

Du coup, je cherche une méthode pour que mon DnD s'effectue correctement, quelque soit le fichier distant. Par conséquent, je tente de m'informer sur les 2 solutions suivantes :
- possibilités du service de fichier de windows
- implémentation de DnD qui me permette de répondre aux demandes de windows lorsque le drop est effectué

La 1ere solution ne me plait pas trop.

La 2e solution avance : un pote m'a montré qu'on pouvait faire ça avec les formats de transfert CFSTR_FILECONTENTS et CFSTR_FILEDESCRIPTOR. On a testé et ça marche.
Maintenant, je souhaite changer le medium de transfert des donnée et utiliser un IStream, donc je suis obligé de coder un objet COM implémentant l'interface IStream. Et je vais le tenter !!!


Bref, tout ça pour un petit DnD !!!!!

[Aurelien.Regat-Barrel]

Je comprends un peu mieux. Tu peux aussi créer ton propre namespace dans le shell, => un répertoire géré comme tu veux. Comme les repertoire Historique par exemple, ou panneau de configuration. C'est toi qui gère le contenu du répertoire. C'est intéressant car l'utilisateur peut s'y rendre comme dans un répertoire classique (voir IQueryInfo).
http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/programmersguide/shell_adv/namespaceextension/nse_view.asp
Tu peux t'inspirer des sources de TortoiseCVS.
codeproject est une mine d'or à ce sujet:
http://www.codeproject.com/shell/NamespaceExtImpl.asp
d'ailleurs pour le drag & drop:
http://www.codeproject.com/shell/explorerdragdrop.asp

[FarookFreeman]

Bien reçu et merci pour cette 3 ème solution.

J'ai regardé très brièvement. Je ne sais pas trop où ça m'envoie mais j'ai vu des CLSID et ca signifierait pas mal d'implémentation de COM/OLE/DCOM enfin tout ça koi ...

A priori je campe avarement sur ma 2e solution (par peur du COM et ses concepts). Je n'aurais qu'un objet COM à coder.
Mais il est vrai que les potentialités de cette 3ème solution sont indéniables. Donc il est possible que j'y vienne un jour ou l'autre, quand j'aurais du temps ... .

Merci chef !