+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Application Builder (/Forum-Application-Builder)
+---- Thema: Application Builder (/Thread-Application-Builder--16536)
Application Builder - Neuling - 10.01.2006 12:05
Hallo zusammen,
müssen alle Bibliotheken die ich in einem VI verwende und dieses mit dem LabVIEW Application Builder zu einer EXE kompiliere in die EXE hineinkompiliert werdenß
Kann ich also eine Bibliothek verwenden die nochnicht existierte als die EXE erstellt wurde?
Application Builder - didierj - 10.01.2006 13:15
Beim Application Builder hast du 2 Varianten:
1. sämtliche sub-vi's werden in die .exe gepackt
2. sämtliche sub-vi's werden in eine LLB gepackt.
Um eine "dynamische" Bibliothek zu erstellen, musst du die vi's dieser Bibliothek über vi-Server aufrufen. Dieser Link kann der App-builder nicht auflösen und packt damit die Bibliotheks-vi's nicht ins exe. Allerdings musst du den Pfad selber auflösen.
Fürs exe heisst dies: <pfad><exename>.exe<vi-name>.vi,
Für eine LLB : <pfad><llbname>.llbvi-name.vi
Allerdings bedeutet dies, dass das Exe schon entsprechend programmiert wurde. Sonst siehts schlecht aus. Über Umwege gibts schon Möglichkeiten, vi's in einem exe zu ersetzen, diese sind (meiner Meinung) jedoch nicht für den Alltagsgebrauch.
Didier
Application Builder - Neuling - 10.01.2006 14:42
also ist es nicht möglich ein mini vi in eine Exe zu kompilieren das nur andere VIs aufruft.
Denn dann fehlen die Bibliotheken?!
Application Builder - didierj - 11.01.2006 12:53
Doch, es ist schon möglich. Eben mit der vi-Server-Methode.
Du musst einfach diese Punkte berücksichtigen:
1. Pfadangaben zu den aufzurufenden vi's berücksichtigen
2. Die aufzurufenden VI's müssen sich auch dort aufhalten
3. Niemand (ausser dir) darf an den Bibliotheks-vi's pfuschen können.
4. Die Versionskontrolle (der Applikation und externen Bibliotheken) ist u.U. sehr schwierig.
Ich empfehle diesen Ansatz höchstens für firmeninterne Programme, wo der Anwenderkreis beschränkt und bekannt ist (und man dem fehlbaren Mitarbeiter mal "auf die Finger klopfen" kann).
Sonst kannst du schnell mal Probleme mit "Sichtbarkeit des Codes", "Haftung", "Funktionalität", usw. bekommen.
Didier