25.11.2010, 09:19
Danke - OK, ich muss das also vom übergeordneten VI aus machen.
>Frosch
ja, schmeckt aber in Essig und Öl ganz passabel :-)
Gottfried
>Frosch
ja, schmeckt aber in Essig und Öl ganz passabel :-)
Gottfried
Seiten: 1 2
25.11.2010, 09:19
25.11.2010, 11:56
@dimitri84
Das hast Du ja sehr schön gemacht:
[attachment=30856]
Ich habe auf die Status-Abfragen immer verzichtet und evtl. Fehlermeldungen gelöscht. Das funktioniert, aber man hat doch das ungute Gefühl, sich als Programmier-Rambo zu verhalten.
Was vielleicht nicht jeder weiß:
1.) man hat über diese Eigenschafts-/Methodenknoten auch direkten Zugriff auf jedes Bedien-und Anzeigeelement, und zwar unabhängig davon, ob diese auf dem FP nach außen hin Anschlüsse haben oder nicht. Also wenn das VI z.B. einen Stop-Knopf hat, kann man es auch damit beenden.
2.) Die so aufgerufenen VIs erscheinen weder in der Hierarchie, noch werden sie im Projekt-Manager unter "Abhängigkeiten" aufgelistet. Also Vorsicht bei Erstellung einer EXE. (Eine vielleicht wenig professionelle Methode das automatisch zu erreichen ist, das VI im Haupt-VI als isoliertes Ikon in einen Deaktivierungsrahmen zu setzen)
Das hast Du ja sehr schön gemacht:
[attachment=30856]
Ich habe auf die Status-Abfragen immer verzichtet und evtl. Fehlermeldungen gelöscht. Das funktioniert, aber man hat doch das ungute Gefühl, sich als Programmier-Rambo zu verhalten.
Was vielleicht nicht jeder weiß:
1.) man hat über diese Eigenschafts-/Methodenknoten auch direkten Zugriff auf jedes Bedien-und Anzeigeelement, und zwar unabhängig davon, ob diese auf dem FP nach außen hin Anschlüsse haben oder nicht. Also wenn das VI z.B. einen Stop-Knopf hat, kann man es auch damit beenden.
2.) Die so aufgerufenen VIs erscheinen weder in der Hierarchie, noch werden sie im Projekt-Manager unter "Abhängigkeiten" aufgelistet. Also Vorsicht bei Erstellung einer EXE. (Eine vielleicht wenig professionelle Methode das automatisch zu erreichen ist, das VI im Haupt-VI als isoliertes Ikon in einen Deaktivierungsrahmen zu setzen)
25.11.2010, 22:51
' schrieb:2.) Die so aufgerufenen VIs erscheinen weder in der Hierarchie, noch werden sie im Projekt-Manager unter "Abhängigkeiten" aufgelistet. Also Vorsicht bei Erstellung einer EXE. (Eine vielleicht wenig professionelle Methode das automatisch zu erreichen ist, das VI im Haupt-VI als isoliertes Ikon in einen Deaktivierungsrahmen zu setzen)
Da nehm ich einfach pauschal 'ne statische VI-Referenz - funzt immer. Siehe i2dx:
' schrieb:jau, genau darum mache ich das. Die erstellte Exe wird von der Runtime-Engine mehr oder weniger wie eine LLB behandelt und wenn du ein VI im Speicher hast, dann reicht für das Öffnen einer Referenz auch der (Datei-)Name des VIs ohne die Angabe des Pfades aus. Durch das Einbinden einer statischen VI-Referenz erzwingst du dass das VI in den Speicher geladen wird und wenn sich diese Referenz irgendwo in deinem Main VI befindet dann bleibt das referenzierte VI auch so lange im Speicher wie das Main VI läuft. Beim Erstellen einer Exe werden statisch referenzierte VIs genau so behandelt wie SubVIs, d.h. das VI und alle SubVIs seiner Hierarchie werden in die EXE eingebunden ...
26.11.2010, 09:59
' schrieb:Zusatzfrage: kann ich in einer VI dieser VI ebenfalls mitteilen, dass ab sofort niemand auf sie warten soll? Wenn ich nämlich das versuche und als VIRefernz "ThisVI" nehme bekomme ich einen Fehler 1000 "VI is nicht in einem Staus der das erlauben wpürde" .... meine freie Übersetzung
Danke
Gottfried
Ich bin mir jetzt nicht 100% sicher, aber vielleicht könnstest Du in dem SubVI eine Queue über ihren Namen referenzieren. Dann kannst Du damit Mitteilungen verbreiten, die das HauptVI lesen kann. Alternative kann man für diesen Zweck sich auch eine globale Variable gönnen, die sagt "wartet nicht". Wichtig hierbei ist, dass die globale Variable nur von dem SubVI gesetzt wird und sonst nur gelesen wird, damit es keine Racebedingung gibt.
Seiten: 1 2