Infofenster bei Applikationsstart

ok danke für deine Variante.
Was noch unschön ist, der Fortschrittsbalken pausiert recht lange, vermutlich wenn die main.vi Ref. geöffnet wird. Erst dann läuft er ganz kurz weiter u. dann ist das main.vi aber auch schon geladen...
Wie kann ich das pausieren beheben?

(14.03.2012 07:36 )GT123 schrieb:  Was noch unschön ist, der Fortschrittsbalken pausiert recht lange, vermutlich wenn die main.vi Ref. geöffnet wird. Erst dann läuft er ganz kurz weiter u. dann ist das main.vi aber auch schon geladen...

Hm...ja, kenne ich, aber ganz ehrlich: Das interessiert doch niemand...

Bei mir ist es meist so: Im Verhältnis zur Gesamtlaufzeit, in der ich häufig HW-Initialisierungen mache (z.B. Reset eines externen Geräts inkl. Einlesen von diveresen Rückmeldungen des Geräts, etc.) ist die Pause marginal.

A.

Ok danke mal, habs jetzt so ähnlich wie bei dir gelöst.
Das pausieren ist zwar noch recht lange... aber was solls, dachte jemand
hat das genau so schon hinbekommen. In diesem Sinne - Danke.

Hallo allerseits,
habe nun noch eine andere Lösung damit es einwandfrei laufen sollte:
-eine SplashScreen.exe starten welche die main.exe startet und die Fortschrittsleiste sollte flüssig laufen
-in der aufgestarteten main.exe dann die SplashScreen.exe stoppen und schliessen

Nun noch eine Frag: Wie kann ich eine exe stoppen und schliessen?
Zum starten verwende ich SystemExec.vi

(12.06.2012 08:11 )GT123 schrieb:  Hallo allerseits,
habe nun noch eine andere Lösung damit es einwandfrei laufen sollte:
-eine SplashScreen.exe starten welche die main.exe startet und die Fortschrittsleiste sollte flüssig laufen
-in der aufgestarteten main.exe dann die SplashScreen.exe stoppen und schliessen

Nun noch eine Frag: Wie kann ich eine exe stoppen und schliessen?
Zum starten verwende ich SystemExec.vi

Das mit der ersten Problematik ist zwar zu lösen aber erfordert einiges an Arbeit und ist es eigentlich nie wert. Man muss beim Builden der Applikation die ganze Hierarchy der Main.vi ermitteln und dann in umgekehrter Reihenfolge in ein Textfile schreiben. Umgekehrte Reihenfolge meint hier, dass man die Ganze Hierarchy (subVI und subVI vom subVI, und so weiter) abläuft bis man keine SubVIs mehr findet und dann diese in aufsteigender Folge irgendwie in ein Konfigurationsfile schreibt. Dieses Konfigurationsfile nimmt man in den Applikationsbuild mit und wird vom Splash Screen.vi gelesen und dann wird jedes dieser VIs der Reihe nach geöffnet bis man am Schluss beim Main ankommt. Danach kann man alle VI Referenzen ausser der MainVI schliessen. Dies ist aber für den Effekt meines Erachtens viel zu viel Arbeit.

Ansonsten mache ich es so, dass mein Splashscreen VI das Main VI öffnet (in den Speicher lädt) und dann startet (Run Methode). Danach wartet es in einer Schleife bis das Panel des Main VIs geöffnet ist und schliesst dann die Main VI Referenz. Das funktioniert gut, da ein offenes VI Frontpanel seine eigene VI Referenz unterhält, so dass die VI Referenz im Splash Screen VI nicht mehr nötig ist. Zudem synchronisiert das auf perfekte Weise die Beendigung des Splash Screen VIs mit der Ausführbarkeit des Main VIs, ohne dass man dazu noch eine extra Global nötig hätte. Wann das Main VI sein Frontpanel öffnet ist ihm selber überlassen. Typischerweise tue ich das, nachdem das Main VI die Konfigurationsdateien gelesen und alle Hardware initialisiert hat.

Zum Stoppen eines Exes ist zu sagen, dass ein Exe sich immer selber stoppen sollte. Entweder ist es eine GUI Applikation die durch den Benützer explizit gestopt wird, oder es ist ein Kommandlinetool das nach der Abarbeitung seiner Task sich einfach beendet. Eine LabVIEW Applikation wird beendet indem man die Loop verlässt und als letzte Aktion das Frontpanel schliesst. In dem Moment wo kein Frontpanel mehr vorhanden ist, wird eine LabVIEW Applikation abgebrochen, selbst wenn Du in einer Loop bist und gerade die Daten eines zigtausend Euro teuren Experiments misst. Deshalb ist es eine gute Idee um zimindest im Hauptfenster Deiner LabVIEW Applikation das Frontpanel Closed Event abzufangen und in eine entsprechende Eventbehandlung in Deiner eigentlichen Consumerloop zu gehen wo Du feststellen kannst ob die Applikation im Moment wirklich gestopt werden darf. Der User kann ansonsten durch einen einfachen Klick auf die Box rechts oben im Fenster die Applikation "abschiessen".

Hallo rolfk,
vielen Dank für deine Erläuterung.
Also grundsätzlich kommt es mir nur darauf an, dass die laufende Fortschrittsleiste nicht hängt wenn das Main.vi startet.
Und das tut es momentan. Siehe Bild vom momentanen starten des main.vi aus dem splashscreen.vi

Zitat:Ansonsten mache ich es so, dass mein Splashscreen VI das Main VI öffnet (in den Speicher lädt) und dann startet (Run Methode). Danach wartet es in einer Schleife bis das Panel des Main VIs geöffnet ist und schliesst dann die Main VI Referenz. Das funktioniert gut, da ein offenes VI Frontpanel seine eigene VI Referenz unterhält, so dass die VI Referenz im Splash Screen VI nicht mehr nötig ist. Zudem synchronisiert das auf perfekte Weise die Beendigung des Splash Screen VIs mit der Ausführbarkeit des Main VIs, ohne dass man dazu noch eine extra Global nötig hätte. Wann das Main VI sein Frontpanel öffnet ist ihm selber überlassen. Typischerweise tue ich das, nachdem das Main VI die Konfigurationsdateien gelesen und alle Hardware initialisiert hat.

D.h. in meinem Fall kein FP open=F und State=?, dann run Vi.
Was bezeichnest du als "warten bis das Panel des Main.vi geöffnet ist"? Das FP oder Blockdiagramm?
Könntest du mir bitte ein screenshot des Teils des SplashScreen BD anhängen, dann sehe ich gleich wie es gemeint ist.
Natürlich nur wenn du es möchtest.

Vermutlich hängt beim mir die Fortschrittsleiste weil es nicht mehr aktualisiert wird, da das FP des main.vi "darüber liegt".

Schon jetzt besten Dank

Anzeige

(13.06.2012 11:45 )GT123 schrieb:  D.h. in meinem Fall kein FP open=F und State=?, dann run Vi.
Was bezeichnest du als "warten bis das Panel des Main.vi geöffnet ist"? Das FP oder Blockdiagramm?
Könntest du mir bitte ein screenshot des Teils des SplashScreen BD anhängen, dann sehe ich gleich wie es gemeint ist.
Natürlich nur wenn du es möchtest.

Screenshot ist etwas lästig. Aber grundsätzlich hat mein Splashscreen VI direct nach der Open VI Reference die Run VI Methode. Danach geht es in eine Schleife in der es darauf wartet dass das Main VI irgendwann mal hoffentlich das Frontpanel öffnet. Deine Property Node vor der Run Methode ist bei mir also nach der Run Methode und in einer Schlaufe, und ich setze den Open Status nicht sondern lese ihn, und breche die Loop ab, sobald dieser True wird, oder ein Timeout abgelaufen ist, da dann wohl etwas gut schiefgelaufen ist. Die Blockierung des UI Threads beim Öffnen des Main VIs ist nur zu kaschieren, indem man das Laden des Main VIs in mehrere Operationen aufteilt wobei man erst kleinere Unterteile einzeln in den Speicher lädt indem man eine Referenz dazu öffnet, bevor man das Main VI lädt. Selber habe ich mal viel Zeit darin investiert um das soweit zu automatisieren und sogar eine Fortschrittsanzeige zu zeigen, aber das habe ich schon lange sein lassen. Es ist meiner Ansicht die Mühe nicht wert.

Angehängtes VI ist im wesentlichen was ich in meinem Splashscreen aufrufe.

Da kann ich nur Zustimmen, meiner Erfahrung lohnt der Aufwand nicht. Wenn dann noch LVOOP Klassenhierarchien geladen werden sollen, müsstest du die jeweils von Oben-Nach-Unten laden.
Zusätzlich werden die Buildeinstellungen ggf. deutlich komplizierter und beim Applicationbuilder bin ich manchmal nur froh, wenn er komplexere Programme überhaupt erfolgreich baut.

Eine eigene Starter.exe die die eigentlichen Exe aufruft ist wohl das kleinste Übel, mir wäre es trotzdem zu viel (bzw. meist unbezahltes Features).

Hallo anbei besten Dank Euch beiden,
eigentlich denke ich das ich die Thematik verstehe, aber im splashscreen hängt die Fortschrittsleiste beim main.vi laden immer noch.
Anbei meine BD. Was ist denn da nicht i.O.???

(13.06.2012 14:15 )GT123 schrieb:  ... splashscreen hängt die Fortschrittsleiste beim main.vi laden immer noch.

Das ist gerade das Problem. Wenn du versuchst das main.vi zu laden, ohne vorher alle SubVIs davon in umgekehrter Reihenfolge zu laden, führt der Ladevorgang, der ja jetzt alle SubVIs mitladen muss, zum Hängen des _kompletten_ UI Threads währenddessen.