ben vlà que mon exemple minimal est tombé en marche !
Alors en effet le second argument n'est pas facultatif. Il faut bien écrire :
Set eFile = eVault.GetFileFromPath(sFichier, eFolder)
La seule autre manipulation que j'ai réalisée c'est un
regsrv32 "C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS PDM\EdmInterface.dll"
qui a peut-être remis de l'ordre dans l'enregistrement des dll. EdmInterface.dll était forcément chargé sinon j'aurais eu bien d'autres messages… Reste à vérifier comment cela se comporte dans une tâche ePDM !
J'aime pas clore sans avoir tout compris, mais bon MERCI BEAUCOUP pour votre aide !
2 « J'aime »
Peut-être la documentation des API PDM qui est fausse également. Même sans faire du "Late Binding" j'ai toujours mis un argument après le chemin du fichier de mémoire.
Doublon, je ne peux pas supprimer
1 « J'aime »
Je pense que la documentation montre bien l'intention de développeurs mais que l'implémentation dans la fonction est fausse.
Le second argument est passé à la fonction par référence, cela lui permet d'y accéder en écriture. En clair cet argument ne précise pas à la fonction le répertoire dans lequel chercher le fichier. Il permet simplement de récupérer l'objet répertoire dans lequel le fichier a été trouvé. Or comme on cherche un fichier par son chemin, donc on connait déjà le répertoire parent. Ce second argument n'est absolument pas indispensable. Peut-être peut-on gagner quelques lignes de codes dans certains cas.
Par contre, attention si le fichier n'existe pas, la fonction mettra Null dans le second argument. Dans mon exemple minimal, getFileFromPath peut vider eFolder en l'assignant à Null, et faire planter la suite. Enfin, ce n'était qu'un exemple.