Unregister For Events Function

Hallo,
in der Hilfe bin ich nicht fündig geworden. Und zwar verwende ich für die Weitergabe der User Event Registration an mehrere SubVi-Event Cases eine Funktionale Globale Variable.
Eigentlich muss man ja zum Schluss am dynamic Terminal der event case die Registrierung o. Referenz schliessen/freigeben. Was aber in meinem Fall?
Ich kann diese Registrierung nur in dem main.vi ganz am Schluss auflösen, ansonsten komme ich ja Fehler... ist das eigentlich i.O. also unbedenklich?
Viele Grüsse

Kannst Du mal Dein(e) VI(s) hochladen?

Gruß Markus

Man kann es an diesem Bsp. erklären siehe die Vi`s.
Vi Global event management.vi wäre mein main.vi

Die Register For Events und Unregister For Events gehören immer zusammen und zwar jeweils zu einer spezifischen Eventstruktur.
D.h. insbesondere das man die "event registration refnum" nicht zwischen VI teilen sollte. Das funktioniert zwar auf den ersten Blick aber irgendwann steht dein Programm bzw. eine Schleife und du suchst dir 'nen Wolf. Außerdem ist ein "event reg refnum" sehr strikt typisiert, d.h. du könntest dich nicht in verschiedenen VIs auf verschiedene unterschiedliche dynamische Events registrieren.

Deshalb immer nur die "user event refnum" zwischen den Programmteilen austauschen. Da bietet sich häufig eine FGV an (einfachere Initialiserung (firstcall? oder isValiedRefnum?) und ggf. erweiterbar um Namesverwaltung damit man "Named User Events" bekommt).

Hi, also jetzt bin ich doch ein bischen irritiert.

Zitat:Die Register For Events und Unregister For Events gehören immer zusammen und zwar jeweils zu einer spezifischen Eventstruktur.

D.h. ich muss zwingend immer Unregister For Events an das dynamic Terminal anghängen? Aber ich verwende
doch im Bsp. eine FGV, d.h. es ist immer die gleiche "event registration refnum".

Zitat:D.h. insbesondere das man die "event registration refnum" nicht zwischen VI teilen sollte.

Also darf ich es nicht wie im Bsp. machen, aber das widerspricht sich doch mit der Aussage:

Zitat:...Da bietet sich häufig eine FGV an (einfachere Initialiserung (firstcall? oder isValiedRefnum?)

das wiederum mache ich doch bereits im Bsp.?

was bedeuted das:

Zitat:erweiterbar um Namesverwaltung damit man "Named User Events" bekommt

Zitat:Das funktioniert zwar auf den ersten Blick aber irgendwann steht dein Programm bzw. eine Schleife und du suchst dir 'nen Wolf.

Heisst dass, man darf grundsätzlich nie mehr als eine Event struktur laufen lassen egal ob im gleichen Vi oder in verschiedenen Vis?
Das in einem Vi nur eine Event Struktur laufen darf ist mir klar.

Zitat:d.h. du könntest dich nicht in verschiedenen VIs auf verschiedene unterschiedliche dynamische Events registrieren.

wenn ich es richtig verstanden habe, mache ich doch das im Bsp. gar nicht

Vielen Dank schonmal für Antworten

(07.02.2012 12:09 )GT123 schrieb:  Hi, also jetzt bin ich doch ein bischen irritiert.

Zitat:Die Register For Events und Unregister For Events gehören immer zusammen und zwar jeweils zu einer spezifischen Eventstruktur.

D.h. ich muss zwingend immer Unregister For Events an das dynamic Terminal anghängen? Aber ich verwende
doch im Bsp. eine FGV, d.h. es ist immer die gleiche "event registration refnum".

Jepp... in der FGV ist es die event registration ref, die solltest du aber nicht an verschiedene VIs bzw. deren Eventstrukturen verteilen/anschließen.

GT123 schrieb:

Zitat:D.h. insbesondere das man die "event registration refnum" nicht zwischen VI teilen sollte.

Also darf ich es nicht wie im Bsp. machen, aber das widerspricht sich doch mit der Aussage:

Zitat:...Da bietet sich häufig eine FGV an (einfachere Initialiserung (firstcall? oder isValiedRefnum?)

das wiederum mache ich doch bereits im Bsp.?

Die FGV sollte die User Event Ref speichern bzw. am besten gleich intern erzeugen (per firstcall oder per check ob die Ref gültig ist).
Damit hat die FGV nur noch einen Ausgang mit der User Event Ref und vl. noch einen Enum Eingang.

GT123 schrieb:was bedeuted das:

Zitat:erweiterbar um Namesverwaltung damit man "Named User Events" bekommt

Wenn du in der FGV mehrere User Events zur Verteilung in der Applikation verwalten willst, kannst du in der FGV eine Name<->Ref Mapping verwalten.
(Da es leider keine Named Userevents gibt, ist das auch das Standardbeispiel im LV Adv Arch. Kurs.)

GT123 schrieb:

Zitat:Das funktioniert zwar auf den ersten Blick aber irgendwann steht dein Programm bzw. eine Schleife und du suchst dir 'nen Wolf.

Heisst dass, man darf grundsätzlich nie mehr als eine Event struktur laufen lassen egal ob im gleichen Vi oder in verschiedenen Vis?
Das in einem Vi nur eine Event Struktur laufen darf ist mir klar.

Eine Event Struktur pro VI ist in 99% _immer_ das sinnvolle Maximum.
Aber es dürfen viele Eventstrukturen in der Anwendung verteilt laufen.

GT123 schrieb:

Zitat:d.h. du könntest dich nicht in verschiedenen VIs auf verschiedene unterschiedliche dynamische Events registrieren.

wenn ich es richtig verstanden habe, mache ich doch das im Bsp. gar nicht

Das machst du im Moment nicht... noch nicht.

GT123 schrieb:Vielen Dank schonmal für Antworten

Bitte schön.

Anzeige

(07.02.2012 18:14 )macmarvin schrieb:  

(07.02.2012 12:09 )GT123 schrieb:  Hi, also jetzt bin ich doch ein bischen irritiert.

Zitat:Die Register For Events und Unregister For Events gehören immer zusammen und zwar jeweils zu einer spezifischen Eventstruktur.

D.h. ich muss zwingend immer Unregister For Events an das dynamic Terminal anghängen? Aber ich verwende
doch im Bsp. eine FGV, d.h. es ist immer die gleiche "event registration refnum".

Jepp... in der FGV ist es die event registration ref, die solltest du aber nicht an verschiedene VIs bzw. deren Eventstrukturen verteilen/anschließen.
aha, denn es kann vorkommen das z.B. von 3 SubVis z.B. nur 2 auf den Event reagieren weil die andere gerade keine Lust o. Zeit hat? Soetwas in der Art habe ich bei mir in der App. beobachtet. Dann muss ich mir eine andere Kommunikation überlegen... was nehme ich dann am Besten (Queue?) um eine Kommunikation mit mehreren SubVis (in denen eigenen Prozesse ablaufen) zu realisieren

GT123 schrieb:

Zitat:D.h. insbesondere das man die "event registration refnum" nicht zwischen VI teilen sollte.

Also darf ich es nicht wie im Bsp. machen, aber das widerspricht sich doch mit der Aussage:

Zitat:...Da bietet sich häufig eine FGV an (einfachere Initialiserung (firstcall? oder isValiedRefnum?)

das wiederum mache ich doch bereits im Bsp.?

Die FGV sollte die User Event Ref speichern bzw. am besten gleich intern erzeugen (per firstcall oder per check ob die Ref gültig ist).
Damit hat die FGV nur noch einen Ausgang mit der User Event Ref und vl. noch einen Enum Eingang.
aha, d.h. es ist eleganter in der FGV zu initialisieren, funktinieren tut es anderst auch.

GT123 schrieb:was bedeuted das:

Zitat:erweiterbar um Namesverwaltung damit man "Named User Events" bekommt

Wenn du in der FGV mehrere User Events zur Verteilung in der Applikation verwalten willst, kannst du in der FGV eine Name<->Ref Mapping verwalten.
(Da es leider keine Named Userevents gibt, ist das auch das Standardbeispiel im LV Adv Arch. Kurs.)
gibt es hierfür ein Beispiel?

GT123 schrieb:

Zitat:Das funktioniert zwar auf den ersten Blick aber irgendwann steht dein Programm bzw. eine Schleife und du suchst dir 'nen Wolf.

Heisst dass, man darf grundsätzlich nie mehr als eine Event struktur laufen lassen egal ob im gleichen Vi oder in verschiedenen Vis?
Das in einem Vi nur eine Event Struktur laufen darf ist mir klar.

Eine Event Struktur pro VI ist in 99% _immer_ das sinnvolle Maximum.
Aber es dürfen viele Eventstrukturen in der Anwendung verteilt laufen.
ok, wenn ich in mehreren Vis auf das gleich event reagieren möchte, kann es vorkommen das ein Event nicht ausgeführt wird (wie oben bereits beschrieben)?

GT123 schrieb:

Zitat:d.h. du könntest dich nicht in verschiedenen VIs auf verschiedene unterschiedliche dynamische Events registrieren.

wenn ich es richtig verstanden habe, mache ich doch das im Bsp. gar nicht

Das machst du im Moment nicht... noch nicht.
in verschiedenen VIs auf verschiedene unterschiedliche dynamische Events... steh auf dem Schlauch, hmm