Nun, mein minimales Beispiel ist ins Spiel gekommen!
Das zweite Argument ist also in der Tat nicht optional.
Set eFile = eVault.GetFileFromPath(sFichier, eFolder)
Die einzige andere Manipulation, die ich durchgeführt habe, war ein
regsrv32 "C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS PDM\EdmInterface.dll"
was den DLL-Eintrag vielleicht wieder in Ordnung gebracht hätte. EdmInterface.dll wurde notwendigerweise geladen, sonst hätte ich viele andere Meldungen bekommen... Es bleibt abzuwarten, wie es sich in einer ePDM-Aufgabe verhält!
Ich schließe nicht gerne, ohne alles verstanden zu haben, aber hey VIELEN DANK für Ihre Hilfe!
2 „Gefällt mir“
Vielleicht ist auch die PDM-API-Dokumentation gefälscht. Auch ohne "Late Binding" setze ich immer ein Argument nach dem Pfad der Speicherdatei.
Duplizieren, ich kann nicht löschen
1 „Gefällt mir“
Ich denke, die Dokumentation zeigt die Absicht der Entwickler, aber die Implementierung in der Funktion ist falsch.
Das zweite Argument wird als Referenz an die Funktion übergeben, was es ihr ermöglicht, durch Schreiben darauf zuzugreifen . Um es klar zu sagen: Dieses Argument gibt nicht das Verzeichnis an, in dem nach der Datei gesucht werden soll. Es ermöglicht Ihnen lediglich, das Verzeichnisobjekt wiederherzustellen, in dem die Datei gefunden wurde. Aber wenn wir eine Datei über ihren Pfad suchen, kennen wir bereits das übergeordnete Verzeichnis. Dieses zweite Argument ist absolut nicht wesentlich. Vielleicht können wir in einigen Fällen ein paar Zeilen Code gewinnen.
Seien Sie jedoch vorsichtig, wenn die Datei nicht existiert, setzt die Funktion Null in das zweite Argument. In meinem minimalen Beispiel kann getFileFromPath den eFolder leeren, indem er ihm Null zugewiesen wird, und den Rest zum Absturz bringen. Nun, das war nur ein Beispiel.