NumericUpDown Valuechanged zündet vor Shown

  • VB.NET

Es gibt 23 Antworten in diesem Thema. Der letzte Beitrag () ist von JLH.

    NumericUpDown Valuechanged zündet vor Shown

    Neu

    Hallo,
    ich belege ein Numericupdown bereits in den Eigenschaften mit Min, Max, Inkrement, Dezimalstellen und Value. Jetzt zündet "valuechanged" gleich nach Programmstart obwohl sich der Wert ja eigentlich nicht geändert hat (kann man sich jetzt streiten). Ich würde das gerne mit "RemoveHhandler" abfangen aber wo muß das rein?

    Neu

    @JLH Wahrscheinlich liegt die primäre Value-Property außerhalb Deiner neuen Grenzen (Min .. Max).
    Da wird Value in den möglichen Bereich gezwungen.
    Wenn Du mit Handles NUD.ValueChanged arbeitest, geht .RemoveHandler nicht, da musst Du es mit einem Flag abfangen.
    Ansonsten nimm das Handles NUD.ValueChanged weg und verwende .AddHandler, nachdem Du Deine Initialwerte gesetzt hast.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Neu

    Wenn es daram läge, dass die Value-Property außerhalb des Bereichs liegt, reicht es dann doch einen Wert innerhalb des Bereichs festzulegen im Designer.

    Ne, vielmehr ist der Value zum Start Nothing, was bei einem Decimal 0 bedeutet. Das heißt das Event zündet immer wenn die Value-Property im Designer nicht auf 0 festgelegt nicht.
    @JLH Aber auch da sollte der Handler eigentlich funktionieren, welches Problem verursacht denn dann die Ereignisbehandlung?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Haudruferzappeltnoch“ ()

    Neu

    Die relevante Abarbeitungsreihenfolge hier ist:
    1. Aufruf von Sub New (Konstruktor des Forms) -> darin: Aufruf von InitializeComponents - da wird der NUD-Wert gesetzt (wenn ungleich 0, da dies nicht der Default-Value ist, was man auch in der Fettschrift des Values im Eigenschaftenfenster des Designers sieht) und somit das ValueChanged-Ereignis ausgelöst
    2. FormLoad-EventHandler
    3. …

    von daher: alles erwartbar.
    Und mit einem Flag - wie bereits in einem Vorpost erwähnt - handelbar: Im FormLoad-EventHandler ein Flag (z.B. namens FormWasLoaded) auf True setzen und im NUD-ValueChanged-EventHandler: If Not FormWasLoaded Then Return
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Neu

    @Haudruferzappeltnoch Es ist tatsächlich das Setzen auf einen anderen Wert als "0".

    Die Werte sind natürlich alle im Bereich. Ich verwende mehrere NUD und habe immer dieses Problem. Ich hab die Initializierung im Load-Event. Da Schalte ich die Handler ab, setze die Werte und mach sie wieder an. Frag mich nur was das soll, dachte ich mach was falsch. Wenn man den Initialwert in den Eigenschaften setzt, dann ist das der Initialwert. Wenn dieser sich ändert sollte das Event ausgelöst werden, nicht wenn der definiert wird.

    VB.NET-Quellcode

    1. RemoveHandler NumericUpDown_AnzKombi.ValueChanged, AddressOf NumericUpDown_AnzKombi_ValueChanged
    2. NumericUpDown_AnzKombi.Minimum = 8
    3. NumericUpDown_AnzKombi.Maximum = 17
    4. NumericUpDown_AnzKombi.Value = AzKombi
    5. AddHandler NumericUpDown_AnzKombi.ValueChanged, AddressOf NumericUpDown_AnzKombi_ValueChanged


    Wozu gibt es eigentlich den Designer? :sleeping:

    Neu

    Wie geschrieben, die Reihenfolge inkl. Auslöser ergeben schon Sinn. Default-Wert und Initialwert sind zwei Paar Gummistiefel, eine Änderung des Defaultwertes (der in der NUD-IKlasse nunmal mit 0 festgelegt ist) feuert eben das ValueChanged-Event und der ValueChanged-EH reagiert.
    Alternativ kannst Du es auch so machen, dass Du die Handles-Klausel weglässt und im FormLoad-EH AddHandler einbaust, dann kannst Du auch den Designer wieder normal verwenden, also die NUD-Werte dort setzen.

    VB.NET-Quellcode

    1. Private Sub FrmMain_Load(sender As Object, e As EventArgs) Handles MyBase.Load
    2. AddHandler NumericUpDown_AnzKombi.ValueChanged, AddressOf NumericUpDown_AnzKombi_ValueChanged
    3. End Sub
    5. Private Sub NumericUpDown_AnzKombi_ValueChanged(sender As Object, e As EventArgs) 'Handles NumericUpDown_AnzKombi.ValueChanged
    6. '…

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Neu

    @VaporiZed Nunja... ich sagte ja bereits "kann man sich streiten"... Ich setze eben durch das Ändern der NUD Werte dazugehörige Flags und setze danach ein und die selbe Reihe von Berechnungen in Gang die dann völlig falsche Werte liefert weil Flags gesetzt sind die nicht gesetzt sein sollten. Diesen "Fehler" müßte man jetzt nicht suchen wenn der Programmierer die Defaultwerte in den Eigenschaften setzen könnte. Oder gibt es einen Grund dafür den Defaultwert und den Initialwert zu unterscheiden? Ich sage nein. Ich setze die Messlatte im Designer und der EH soll sich nach den neuen Werten richten :)

    ABER... Ich habe wieder was gelernt :) Gehe ich Recht in der Annahme, daß man den Handler adden kann wo man möchte und dann bei Aufruf den "Handles...." wie oben dann nicht braucht? (Paßt wieder)
    Ich wußte nicht, daß man die Handles weglassen kann. Danke!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „JLH“ ()

    Neu

    JLH schrieb:

    Gehe ich Recht in der Annahme
    korrekt. Die Handles-Klausel ersetzt die AddHandler-Codezeile.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Neu

    JLH schrieb:

    Gehe ich Recht in der Annahme, daß man den Handler adden kann wo man möchte und dann bei Aufruf den "Handles...." wie oben dann nicht braucht?
    Ja.
    Die Handles-Clause ist nur eine Bequemlichkeitsschreibweise von VB.Net.
    In C# beispielsweise musst du immer mit AddHandler arbeiten.

    Edit: too late
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Neu

    JLH schrieb:

    Frag mich nur was das soll, dachte ich mach was falsch. Wenn man den Initialwert in den Eigenschaften setzt, dann ist das der Initialwert. Wenn dieser sich ändert sollte das Event ausgelöst werden, nicht wenn der definiert wird.
    Wenn kein Code läuft, dann gibt es auch keine Werte im Arbeitsspeicher für diesen Code. Das sollte wohl erstmal einleuchten.
    Nun musst du dich mit Werttypen auseinandersetzen. Kein Wert ist bei einem Werttyp doch ein Wert. Was bei Referenztypen gesondert Nothing heißt, hat bei Werttypen einen tatsächlichen Wert. Bei Decimal ist das die 0.

    Dementsprechend wenn du 0 im Designer einträgst, muss der Designer bei Programmstart nichts machen. Kein Wert bleibt kein Wert sozusagen. Wenn du da eine andere Zahl rein fummelst, muss der Designer das bei Programmstart umsetzen.

    Aus meiner Sicht würde ich deswegen sagen, dass du doch etwas falsch machst: Der ValueChanged Handler sollte immer fahren dürfen, egal welcher Wert reingeschrieben wird. Wenn du dadrin Dinge machst, die bei manchen Werten nicht hinhauen, bist du mit diesen Dingen im falschen Event unterwegs.
    Für so etwas habe ich noch nie einen Handler deaktiviert.

    Neu

    Haudruferzappeltnoch schrieb:

    Der ValueChanged Handler sollte immer fahren dürfen, egal welcher Wert reingeschrieben wird.
    Das Problem ist ja oft nicht unbedingt der Wert, sondern der Zeitpunkt.
    Wenn das Event mit der Handles-Klausel abonniert wurden, dann feuert es ggfs bereits in der InitializeComponents-Methode, und das ist für manche Verarbeitungen zu früh.
    Daher habich oft, bei kniffligen Initialisierungen, dassich mit AddHandler abonniere, zu einem Zeitpunkt, wo InitializeComponents() bereits durchgelaufen ist.
    Aber halt mit Augenmass: Die Handles-Klausel bevorzuge ich, weil ist schneller gecodet und leserlicher. Aber wenns halt nicht geht, muss AddHandler ran.

    Neu

    Ich regle das bei meinem Projekt so, dass ich eine globale Variable "IsLoadFinished = false" habe.
    im Load-Handler initialisiere ich meine NUDs.
    In der letzten Zeile m Load-Hander wird diese Variable dann auf "IsLoadFinished = true" gesetzt.

    In den ValueChanged-Ereignissen meiner NUDs habe ich die Befehle von

    If IsLoadFinished = true
    ...
    end if

    umrandet.

    Dasselbe auch in den Changed-Ereignissen anderer Controls, welche das gleiche Verhalten aufweisen.

    Funktioniert perfekt.

    Neu

    Hi @ErfinderDesRades
    Danke Dir :)
    Ich weiss nur nicht, wie man Events im Load-Handler anhängt.
    Ich erstelle Projekt und dessen Controls ja im Designer.
    Da werden die Events gleich beim Erstellen in die entsprechende .vb gepackt.
    Geht das nachträgliche Anhängen der Events nur bei scripterzeugten Objekten oder auch im Designer?

    Neu

    gugge dies, das müsste alle Unklarheiten beseitigen:
    Alles über Events (die zuletzt vorgeführte Variante).


    Geht das nachträgliche Anhängen der Events nur bei scripterzeugten Objekten oder auch im Designer?
    Für das Anhängen ists ganz egal, ob das Control "scripterzeugt" ist oder im Designer.

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Neu

    @Haudruferzappeltnoch Ich entnehme dem Thread, daß noch mehr Leute mit dieser Logic ein Problem haben. Ich habe schon einige andere Events zur Prüfung versucht und der Beste war eben ValueChanged bis ich über dieses Thema gestolpert bin. Und nein, der Handler sollte nicht immer fahren dürfen. Ich programmiere eine Grafische Oberfläche für eine Berechnung. Die NUMs sind Eingabe und Ausgabe zugleich. Dh ändert man in einem NUM den Wert so werden die Werte der anderen NUMs neu berechnet. Nehmen wir ein Rad... es hat einen Umfang, eine Drehzahl und somit eine Geschwindigkeit. Also 3 NUMs die alle Auswirkung auf die anderen haben. Der User schraubt an einem der 3 Werte und (der Einfachheithalber) ändert sich einer der anderen zwei. Es ändern sich nicht nur die Werte, sondern auch die MAx/Mins. Der User löst durch die Eingabe ein Event aus welcher die Berechnung startet. Das Anzeigen des Ergebnisses in einem der anderen NUMs soll das eben nicht. Wenn ich jetzt da was falsch mache bin ich für alles offen wie man diese Events auswerten könnte.

    Und ich sag's nochmal... erst wenn die Werte initialisiert sind sollte das Vergleichen losgehen und nicht shon beim initialisieren. Und das passiert nicht beim Programmstart sondern wenn der User die Randbedingungen eingibt.

    Neu

    Wenn der User überall 0 reinschreibt, was passiert dann?
    Denn nichts anderes tut der Programmstart.

    Und zum Sachverhalt: Du schreibst im ValueChanged Handler andere Werte an andere NUDs, die widerum dasselbe tun?
    Dann feuern die Events doch durchgehend, weil der eine den anderen anstößt.

    Ich sags auch nochmal, mir ist das alles nicht geheuer.

    Neu

    Hi @ErfinderDesRades,
    Danke Dir. :)
    Da bin ich wieder mal auf dem Feuerwehrschlauch gestanden. :D
    Also Controls im Designer erstellen, aber dort eben keine Ereignis-Handler automatisch generieren lassen.
    Dann am Ende des Load-Handlers die Subs für die Befehlsausführung der Controls mit AddHandler den Eigenschaften der Controls zuweisen.
    Eigentlich ganz einfach - wenn man vom Schlauch runtersteigt. ;)

    Neu

    @Haudruferzappeltnoch Ich sagte ja, man kann sich streiten... Ist aber wie ich jetzt weiß generell so. Daß ein ValueChanged Event zündet wenn sich was ändert ist ja völlig klar. Ich bin eben der Meinung er sollte sich auch eben nur dann ändern und nicht wenn man ihn initialisiert.

    Und zum Sachverhalt: Du schreibst im ValueChanged Handler andere Werte an andere NUDs, die widerum dasselbe tun?

    Eben nicht. Es kann ja immer nur ein Wert vom User geändert werden und ich weiß ja welche Werte sich dadurch ändern. Und genau für die schalte ich den Handler ab und dann wieder an. In meinem Beispiel, ändert der User den Umfang (Radius) des Rades dann erhöht sich bei gleicher Drehzahl die Geschwindigkeit. Also schalte ich den Handler für die NUD der Geschwindigkeit ab und nach dem Ändern wieder an. Ändert er dann die Drehzahl ändert sich wieder entsprechend die Geschwindigkeit. Ändert der User die Geschwindikeit machen wir ein anderes mal :) Ich kann jeden dieser Events kontrollieren. Jetzt wo ich es weiß, auch den beim Initialisieren.

    Da es aber keine Räder mit Umfang "0" gibt muß ich ein Anfangsradius angeben. Und das ist in meinen Augen keine Änderung :D