Cóż, mój minimalny przykład wpadł w grę!
Tak więc drugi argument nie jest opcjonalny .
Set eFile = eVault.GetFileFromPath(sFichier, eFolder)
Jedyną inną manipulacją, którą wykonałem, było
regsrv32 "C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS PDM\EdmInterface.dll"
co mogło przywrócić porządek w rekordzie DLL. EdmInterface.dll koniecznie został załadowany, w przeciwnym razie miałbym wiele innych wiadomości... Dopiero się okaże, jak zachowa się w zadaniu ePDM!
Nie lubię kończyć bez zrozumienia wszystkiego, ale hej BARDZO DZIĘKUJĘ za pomoc!
2 polubienia
Być może dokumentacja API PDM jest również fałszywa. Nawet bez wykonywania "Late Binding" zawsze umieszczam argument po ścieżce do pliku pamięci.
Duplikat, nie mogę usunąć
1 polubienie
Myślę, że dokumentacja pokazuje intencje programistów, ale implementacja w funkcji jest błędna.
Drugi argument jest przekazywany do funkcji przez odwołanie, co pozwala jej uzyskać do niego dostęp przez zapis. Żeby było jasne, ten argument nie określa katalogu, w którym należy szukać pliku. Po prostu pozwala odzyskać obiekt katalogu, w którym znaleziono plik. Ale gdy szukamy pliku po jego ścieżce, znamy już katalog nadrzędny. Ten drugi argument absolutnie nie jest istotny. Być może w niektórych przypadkach uda nam się zdobyć kilka linijek kodu.
Z drugiej strony należy zachować ostrożność, jeśli plik nie istnieje, funkcja umieści Null w drugim argumencie. W moim minimalnym przykładzie getFileFromPath może opróżnić eFolder, przypisując go do Null, i zawiesić resztę. Cóż, to był tylko przykład.