Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich meine, mich zu erinnern, dass es in LV 7 oder schon 6 die Möglichkeit gab, durch die Namensgebung eines Sub-VIs festzulegen, dass das Panel dieses VIs beim Erstellen einer Applikation von LV automatisch als Startpanel verwendet wird.
So würde, wie in vielen großen komerziellen Applikationen wie z.B. Office-Anwendungen noch bevor die eigentliche Applikation gestartet wird, eben dieses Fenster eingeblendet, auf dem man z.B. eine Grafik oder irgend einen Text ablegen könnte.
Ist das nur Wunschdenken von mir, oder habe ich das womöglich richtig in Erinnerung und wenn ja, wie bekommt man ein Sub-VI dazu, zu so einem Start-Panel zu werden?
das nennt man "Splash screen". Ich mach das immer so:
Ein VI nach Wunsch gestalten und als "Startup VI" im Application Builder definieren. In diesem Splash screen VI wird dann das eigentliche Haupt-VI meiner Applikation per VI Server aufgerufen.
Gruß
Achim
"Is there some mightier sage, of whom we have yet to learn?"
"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Vielen Dank für die schnelle Antwort.
Ich habe früher (in LV 8.0) auch immer ein kleines VI im ApplBuilder als Start-VI definiert und darin dann das eigentliche Haupt-VI, das sich in einer DLL befand aufgerufen. Den Aufruf habe ich mit der Funktion VI-Referenz öffnen realisiert, wobei ich als Pfad den Pfad der DLL mit dem darin befindlichen Sub-VI angegeben habe. (Die DLL habe ich darin wie einen Ordner behandelt)
Nun bin ich auf LV2011 umgestiegen und da geht das leider nicht mehr so. Jetzt müsste ich den Aufruf des Haupt-VIs aus der DLL über den Knoten Aufruf externer Bibliotheken machen. Dann bleibt aber das aufrufende VI, also mein Startpanel solange an dem Aufrufknoten stehen, bis ich das aufgerufene VI, also mein Haupt-VI wieder schließe.
Hi,
sorry, da kann ich nicht weiterhelfen. Ich hab noch nie ne LV-Applikation in ne DLL gewandelt. Das war noch nie notwendig, somit hab ich das auch noch nie aufrufen müssen. Ich erzeuge immer Exe-Files.
Ginge es evtl., dass du die komplette LV-Seite, also Splash screen + eigentliche Applikation in ne DLL packst? Dann könntest du auf LV-Ebene per VI-Server so wie von mir oben beschrieben arbeiten, und von außerhalb rufst du dann einfach die DLL auf...wär halt nur ein Workaround...keine Ahnung ob man das machen kann.
Gruß
Achim
"Is there some mightier sage, of whom we have yet to learn?"
"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Vielen Dank für die schnelle Antwort.
Ich habe früher (in LV 8.0) auch immer ein kleines VI im ApplBuilder als Start-VI definiert und darin dann das eigentliche Haupt-VI, das sich in einer DLL befand aufgerufen. Den Aufruf habe ich mit der Funktion VI-Referenz öffnen realisiert, wobei ich als Pfad den Pfad der DLL mit dem darin befindlichen Sub-VI angegeben habe. (Die DLL habe ich darin wie einen Ordner behandelt)
Nun bin ich auf LV2011 umgestiegen und da geht das leider nicht mehr so. Jetzt müsste ich den Aufruf des Haupt-VIs aus der DLL über den Knoten Aufruf externer Bibliotheken machen. Dann bleibt aber das aufrufende VI, also mein Startpanel solange an dem Aufrufknoten stehen, bis ich das aufgerufene VI, also mein Haupt-VI wieder schließe.
Hast Du da eventuell noch eine Idee?
Meinst Du vielleicht eine LLB? Bei einer DLL erwarte ich nicht, dass ich eine Funktion daraus über eine VI-Referenz starten kann. Eine DLL müsste ja auch von anderen Compilern verwendbar sein und daher keine VIs mehr enthalten.
Ja, ich meine eine DLL,
ich hätte früher auch nicht erwartet, aus einer DLL über den VI-Referenz-Aufruf ein VI starten zu können, aber in LV 8.0 ging es genauso. Deshalb hab ich ein relativ großes Projekt auf diese Weise aufgebaut. Nun bin ich aber bei LV 2011, und es gab, wie bei jeder LV-Versionsumstellung mal wieder Probleme, in der Hinsicht, dass irgendwas, was schon mal ging, nun eben nicht mehr geht.
Einige DLLs beim Kunden abzuliefern sah ich als deutlich professioneller an, als ein Sack voll VIs dort irgendwo auf´m Kundenrechner zu parken auch in LLB-Form. Die verschiedenen DLLs habe ich in ihre Aufgabenbereiche unterteilt. Inzwischen habe ich zwar gelernt, wie man VIs mit dem VI-Referenz-Aufruf aus einee Exe aufruft, aber dann müsste ich eine Exe an den Kunden ausliefern, die immer alles enthält, und das können dann inzwischen bis zu 20MB sein.
(29.11.2011 21:30 )Trinitatis schrieb: ..Inzwischen habe ich zwar gelernt, wie man VIs mit dem VI-Referenz-Aufruf aus einee Exe aufruft, ..
Aha. Und wie geht das?
Ich hätte auch gerne eine Möglichkeit, nicht die gesamte Exe sondern nur die geänderten VIs automatisiert auf das Kundensystem hochzuladen. Ich hätte nichts dagegen, wenn VIs in einem Unterordner der EXE auf dem Kundensystem durch einen Installer installiert werden. Hauptsache das Programm funzt danach ohne Probleme.
(29.11.2011 21:30 )Trinitatis schrieb: ..Inzwischen habe ich zwar gelernt, wie man VIs mit dem VI-Referenz-Aufruf aus einee Exe aufruft, ..
Ich hätte auch gerne eine Möglichkeit, nicht die gesamte Exe sondern nur die geänderten VIs automatisiert auf das Kundensystem hochzuladen. Ich hätte nichts dagegen, wenn VIs in einem Unterordner der EXE auf dem Kundensystem durch einen Installer installiert werden. Hauptsache das Programm funzt danach ohne Probleme.
Hallo unicorn,
Alternative z.B bei modularem Aufruf:
Stichwort PackedLibrary (.lvlibp) - besteht immer aus einer lvlib - beinhaltet alle sub-vi´s (Versionsstand zum Zeitpunkt des builden) und kann mittels Version´s Information auf aktualität geprüft werden.
Tipp: Logfile beim builden mit erstellen (Inhalt alle Source Files Pfade-Datum-Version, und output files Informationen)
