(13.06.2012 14:15 )GT123 schrieb: 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.???
Es ist äusserst unschön dass Du in Deinem Main VI eine Referenz zum Splashscreen Vi öffnest um dieses zu aborten. Der Umstand dass Du das Main VI Frontpanel öffnest signalisiert dem Splashscreen VI ja bereits, dass Du jetzt soweit bist um die eigentliche Arbeit selber weiterzuführen und damit kann sich das Splashscreen VI ganz einfach selber beenden. Und nein dazu braucht es kein Abort, einfach alles aufräumen was noch aufzuräumen ist und dann das eigene Frontpanel schliessen et voila!
Wie macmarvin ja schon erläuterte führt das Open VI Reference VI alle Arbeit im UI Thread aus. Das ist derselbe Thread der auch für das UI Update benützt wird. Solange eine Open VI Reference also beschäftigt ist, macht LabVIEW keine UI Updates. Das ist manchmal lästig aber eben einfach nicht anders. Alternativen um Open VI Reference nicht im UI Thread auszuführen wurden oft gefordert und die LabVIEW Entwickler haben sicher schon öfters nach Möglichkeiten dazu gesucht, aber das Laden einer VI Hierarchie ist eine delikate Angelegenheit die nicht einfach durch andere Operationen beliebig unterbrochen werden darf da LabVIEW während dem Laden unzählige globale Tabellen konstant updaten muss, und wenn es dass nicht in einem exclusiven Thread tut der durch jemanden anderen jederzeit unterbrochen werden kann, dann würdest Du kein einziges komplexes Programm mehr in den Speicher laden können ohne dass LabVIEW sich früher oder später mit einer Exception verabschiedet. Natürlich könnte LabVIEW dazu auch eine Critical Section bemühen aber das Problem ist dass diese globalen Tabellen and mehreren Stellen in LabVIEW angesprochen werden die teilweise wieder andere kritische Abhängikeiten haben, und die Kombination von mehreren Critical Sections hat eine grosse Gefahr eines sogenannten Priority Invresion Locks, wo zwei Teile sich gegenseitig blockieren weil jeder darauf wartet dass der andere die Resource wieder freigibt.
