Wrapper DLL zum dynamischen Laden

Hallo,

ich habe eine Anwendung, bei der ich während der Runtime entscheide, welche DLL ich laden will. (Kompliziertere Geschichte, Gerätetreiber + SPS).

Klassisch würde ich den Aufrufknoten verwenden; mit dynamischen Laden - das funktioniert leider wegen einem Bug in diesem Fall nicht (Der Support ist dran, aber es sind sensible Daten). Deshalb wollte ich, wie klassisch vor LV 8.? (6?2?) eine Wrapper-DLL verwenden - einfach den Pfad übergeben ...

Ist natürlich nicht schwer zu schreiben, aber trotzdem wollte ich fragen, ob einer von euch zufällig noch so einen C/C++-Code rumliegen hat?

Danke,
Birgit

(17.04.2012 10:44 )b.p schrieb:  Hallo,

ich habe eine Anwendung, bei der ich während der Runtime entscheide, welche DLL ich laden will. (Kompliziertere Geschichte, Gerätetreiber + SPS).

Klassisch würde ich den Aufrufknoten verwenden; mit dynamischen Laden - das funktioniert leider wegen einem Bug in diesem Fall nicht (Der Support ist dran, aber es sind sensible Daten). Deshalb wollte ich, wie klassisch vor LV 8.? (6?2?) eine Wrapper-DLL verwenden - einfach den Pfad übergeben ...

Ist natürlich nicht schwer zu schreiben, aber trotzdem wollte ich fragen, ob einer von euch zufällig noch so einen C/C++-Code rumliegen hat?

Danke,
Birgit

Was für ein Bug in der Call Library Node?

Das mit der Wrapper DLL ist nur mit sinnvollem Aufwand zu tun wenn der Funktionsprototyp immer derselbe bleibt. Aber!!!

Um wieviele Funktionen geht es per DLL? Eine Variante bei nicht zu vielen Funktionen wäre um eine Funktionelle Globale Variable (FGV) per DLL zu erstellen, wo jede Funktion als eine Methode verfügbar ist. Dann lädtst Du die jeweilige FGV mit VI Server in den Speicher und rufst sie mit Call By Reference auf. Habe ich schon öfter für DLLs oder ActiveX Controls getan die manchmal nicht auf einem Computer vorhanden sein können. Wenn man das auf diese Weise dynamisch macht kann man die Komponente zu laden versuchen und wenn das fehlschlägt alle Funktionalität die davon Gebrauch macht einfach disablen ohne dass LabVIEW nicht gestartet werden kann, wenn die entsprechende Komponente nicht auf dem PC vorhanden ist.

Hallo,

der Bug ist, dass beim Laden der dynamischen dlls in 2 bestimmten, kritischen Fällen ein Pfad falsch gelesen wird - und blöderweise kann ich nicht verschieben/umbenennen, weil wir ein Mehrkomponentensystem haben. Wir haben schon "alles" probiert, was einfach/sinnvoll war, und jetzt ist halt die Idee, dass wir den ganzen Aufruf in LV so umgehen.

Der Funktionsprototyp bleibt - zumindest in den Fällen, wo ich das einsetze - immer derselbe.

Die FGV-Variante gefällt mir (geht dann wohl auch schon in Richtung Action Engine) aber auch ganz gut - mal schauen.

Danke.

(17.04.2012 12:06 )b.p schrieb:  Hallo,

der Bug ist, dass beim Laden der dynamischen dlls in 2 bestimmten, kritischen Fällen ein Pfad falsch gelesen wird - und blöderweise kann ich nicht verschieben/umbenennen, weil wir ein Mehrkomponentensystem haben. Wir haben schon "alles" probiert, was einfach/sinnvoll war, und jetzt ist halt die Idee, dass wir den ganzen Aufruf in LV so umgehen.

Der Funktionsprototyp bleibt - zumindest in den Fällen, wo ich das einsetze - immer derselbe.

Die FGV-Variante gefällt mir (geht dann wohl auch schon in Richtung Action Engine) aber auch ganz gut - mal schauen.

Danke.

Ja im Prinzip ist es eine Action Engine, wenngleich in diesem Fall nicht unbedingt mit einer Loop mit Uninitialized Shift Register.

FGV == Action Engine sind eigentlich synonyme Begriffe für ein und dasselbe.