28.04.2013, 11:12
Beitrag #3
|
gerln
LVF-Grünschnabel
Beiträge: 13
Registriert seit: Jul 2011
10
2010
DE
Deutschland
|
RE: unterschiedliche Anzahl nummerischer Eingabeelemente?
Vielen Dank,
ich denk mal das ist der Ansatz den ich weiter verfolgen werde.
Ich frage mich langsam ob meine geistige Umnachtung wirklich schon soweit vorangeschritten ist, dass ich nicht selber auf so etwas komme.
Nur noch kurz:
Kann mir vielleicht jemand auf die Schnelle sagen, ob ich in einer Event-Struktur(Wertänderung) den Wert im Array sehen kann, der sich geändert hat oder nur das sich das Array geändert hat .
Mfg
|
|
|
28.04.2013, 11:37
Beitrag #4
|
|
|
28.04.2013, 12:26
Beitrag #5
|
gerln
LVF-Grünschnabel
Beiträge: 13
Registriert seit: Jul 2011
10
2010
DE
Deutschland
|
RE: unterschiedliche Anzahl nummerischer Eingabeelemente?
OK,
hatte ich schon so vermutet, aber hätte ja sein können..
Trotzdem Danke.
Mfg
|
|
|
28.04.2013, 14:44
(Dieser Beitrag wurde zuletzt bearbeitet: 29.04.2013 08:07 von Lucki.)
Beitrag #6
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
RE: unterschiedliche Anzahl nummerischer Eingabeelemente?
(28.04.2013 11:12 )gerln schrieb: Kann mir vielleicht jemand auf die Schnelle sagen, ob ich in einer Event-Struktur(Wertänderung) den Wert im Array sehen kann, der sich geändert hat oder nur das sich das Array geändert hat .
In Deinem Satz steckt implizit die Ausssage, dass ein Ereignis der Kategorie "Weränderung" immer nur bei Wertänderungen stattfindet. Logisch ist das eigentlich selbstverständlich, solange man der Benennung "Wertänderung" überhaupt trauen kann. Dem ist aber nicht so. Das gilt nämlich nur für Bedienereignisse.
Man kann aber das Ereignis "Wertänderung" auch mit dem Eigenschaftsknoten "Wert, signalisierend" auslösen, und hiefür genügt allein das Lesen des Knotens. Wenn sich der Wert nicht geändert hat - das Ereignis findet trotzdem statt.
|
|
|
28.04.2013, 17:57
Beitrag #7
|
|
|
29.04.2013, 07:43
Beitrag #8
|
Kiesch
LVF-Stammgast
Beiträge: 412
Registriert seit: Mar 2009
2019, 2018, 2016
2009
DE
04519
Deutschland
|
RE: unterschiedliche Anzahl nummerischer Eingabeelemente?
Na ja... und dann wären da noch die Fälle wo der Nutzer den gleichen Wert nochmal einträgt... Dann kriegt man auch nen Ereignis aber findet nix (händisch) was man geändert hat.
Bottom Line:
In der Variante musst du alle Fälle bei denen sich trotz Ereignis "Wertänderung" nichts ändert also separat behandeln (wird vermutlich auf "nichts tun" hinauslaufen).
Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
|
|
|
29.04.2013, 08:33
Beitrag #9
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
RE: unterschiedliche Anzahl nummerischer Eingabeelemente?
Entschuldigung, Fehler von mir: Bei "Wert, signalisierend" gibt es ja nur Schreibzugriff.
Es stimmt aber nicht, dass man bei fehlender Wertänderung im Ereignisknoten immer nur "nichts" tun muss.
Es kommt häufig vor, dass man den Ereignisknoten aus 2 Gründen aufrufen möchte:
1. Ein einziges Mal bei der Initialisierung das Programms
2. Ansonsten bei Wertänderung durch Bedienung.
Punkt 1 löse ich so, dass ich im Initialisierungsteil eine lokale Veriable des Bedienelementes an den Eigenschaftsknoten "Wert, signalisierend" anschließe. Es findet damit garantiert keine Wertänderung satt, aber der Ereignisknoten wird wie gewünscht aufgerufen.
Mir ist aber inzwischen klar, das das nicht die eleganteste Methode ist, das Initialisierungsproblem zu lösen. Besser ist die "Queue driven" Ereignisstrukur: In den Ereigniscases selbst steht kein Code, sondern es werden nur Kommandos in eine Queue geschickt. Der eigentliche Code wird dann in einer State-Machine-Struktur abgearbeitet. Auf den Code in der State-Machine kann man auch ohne den Umweg über ein Ereignis zugreifen - also z.B bei der Initialisierung.
|
|
|
| |