Wie funktioniert Einbindung eines dynamischen VIs in eine EXE wirklich?

' schrieb:es kann auch vorkommen, das LV in der Entwicklungsumgebung deswegen rummeckert: ich hab aktuell gerade wieder ein Projekt, dass ich das letzte mal mit LV 8.2.1 angefasst habe auf LV 8.5.1 hochgezogen. Dabei habe ich die Ordner-Struktur im Project-Explorer neu aufgebaut und unter anderem "auto-populating-Folders" verwendet. Beim Deploy auf das RT Ziel meckert LV rum, dass es VIs gäbe, die bereits von einer anderen Position geladen sind und fragt nach, ob ich die Konflikte lösen will ...

Meine Bemerkung war nicht gemeint dass das Problem im Entwicklungssystem nicht auch passieren kann, sondern dass im Falle unseres LuaVIEW Toolkits dieses Problem auftrat sobald man eine damit gebaute Appliation als Executable distributieren wollte. Die im Hintergrund dynamisch geladenen Task VIs werden da ja schliesslich vom LuaVIEW Task Manager von einer spezifischen Stelle geladen. Wenn diese nicht übereinstimmt mit der wirklichen Stelle, dann ist im Setup der Applikation etwas verkehrt und da kann LabVIEW natürlich nichts mehr machen.

Um die Distribution eines Executables zu vereinfachen werden aber diese dynamischen VIs eben als dynamic VI in das Executable Build mitgenommen. Vor LabVIEW 8.5 war es kein Problem das die entsprechenden Open VI Reference Nodes einen Path mitbekamen da LabVIEW die VIs innerhalb des Executables finden konnte und einfach lud. In LabVIEW 8.5 mussten alle diese Stellen gepatcht werden wobei im Entwickelsystem ein Open VI Reference mit Path input benützt wird und in einer built Application eines mit String input. Das Ganze konnte aber leider nicht mit einem SubVI ersetzt werden, da die Open VI References mit verschiedenen Strict Typedefed VI References arbeiteten. Und die undokumentierten XNodes dafür bemühen schien uns noch unangenehmer dann jede dieser Stellen individuel mit einer entsprechenden Code Sequence zu ersetzen.

Rolf Kalbermatter