Well, my minimal example has fallen into play!
So indeed the second argument is not optional.
Set eFile = eVault.GetFileFromPath(sFichier, eFolder)
The only other manipulation I performed was a
regsrv32 "C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS PDM\EdmInterface.dll"
which may have put the dll record back in order. EdmInterface.dll was necessarily loaded, otherwise I would have had many other messages... It remains to be seen how it behaves in an ePDM task!
I don't like to close without having understood everything, but hey THANK YOU VERY MUCH for your help!
2 Likes
Maybe the PDM API documentation is fake as well. Even without doing "Late Binding" I always put an argument after the memory file path.
Duplicate, I can't delete
1 Like
I think the documentation shows the intent of the developers, but the implementation in the function is wrong.
The second argument is passed to the function by reference, which allows it to access it by writing. To be clear, this argument does not specify the directory in which to look for the file. It simply allows you to recover the directory object in which the file was found. But as we look for a file by its path, we already know the parent directory. This second argument is absolutely not essential. Maybe we can gain a few lines of code in some cases.
On the other hand, be careful if the file does not exist, the function will put Null in the second argument. In my minimal example, getFileFromPath can empty eFolder by assigning it to Null, and crash the rest. Well, that was just an example.