Settings richtig verwenden + an Settings binden

    • VB.NET

    Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

      Settings richtig verwenden + an Settings binden

      Settings werden sehr häufig suboptimal eingesetzt, vmtl. weil einige Eigenschaften dieses Features nicht hinlänglich bekannt sind.

      Also folgende Settings habe ich mal in den Projekteinstellungen angelegt:


      Und dieses ist mein Form:


      Dann habe ich die Textboxen an die Settings gebunden:

      Um an ein Settings zu binden, erweitere man den Knoten "(ApplicationSettings)", und darin klickse man "(PropertyBindings)" - das öffnet den gezeigten Dialog.

      Und - besonders schnucklig: Ich habe auch die Groupbox gebunden - ihren Text band ich an "TextboxText", und ihre BackColor an "aColor":


      Natürlich band ich auch ColorDialog1.Color an "aColor":


      Code schrieb ich nur, um den ColorDialog aufzurufen:

      VB.NET-Quellcode

      1. Private Sub btChangeColor_Click(ByVal sender As Object, ByVal e As EventArgs) Handles btChangeColor.Click
      2. ColorDialog1.ShowDialog()
      3. End Sub
      Weil ich dachte, wenn die Color gebunden ist, wird das schon flutschen - ebensoschön, wies ja mitm "TextboxText" flutscht.

      Das war ein Irrtum, und ein Blick in den DesignerCode des Forms zeigt auch warum:

      VB.NET-Quellcode

      1. '...
      2. '
      3. 'ColorDialog1
      4. '
      5. Me.ColorDialog1.Color = Global.SettingsBinding.My.MySettings.Default.aColor
      6. Me.ColorDialog1.FullOpen = True
      7. '
      8. 'TextBox1
      9. '
      10. Me.TextBox1.DataBindings.Add(New System.Windows.Forms.Binding("Text", _
      11. Global.SettingsBinding.My.MySettings.Default, "TextboxText", True, _
      12. System.Windows.Forms.DataSourceUpdateMode.OnPropertyChanged))
      13. '...
      Wie man sieht, generiert der Designer für die Textbox ein korrektes Binding, hingegen beim ColorDialog wird nur das Setting ausgelesen - kein Binding wird gesetzt.

      Daher übernimmt der ColorDialog beim StartUp zwar die Color, aber es gibt keine weitere Kommunikation mittm Setting, und auch der neue Zustand wird nicht persistiert für den nächsten Startup (bei TextboxText funzt beides like a charm)

      Aber das ist auch garnet schlecht, denn einen Dialog will man ja auch canceln können, und da könnte man nicht brauchen, wenn sich die getätigten Einstellungen bereits via Bindings in der ganzen Anwendung verbreitet hätten.

      Also beim ColorDialog guten alten Code schreiben, was bei den Textboxen sich erübrigt:

      VB.NET-Quellcode

      1. Private Sub btChangeColor_Click(ByVal sender As Object, ByVal e As EventArgs) Handles btChangeColor.Click
      2. With ColorDialog1
      3. If .ShowDialog() <> Windows.Forms.DialogResult.OK Then Return
      4. My.Settings.aColor = .Color
      5. End With
      6. End Sub
      Das wars - den Rest erledigen richtige Bindings :)

      Ergebnis:

      Merkpunkte:
      Settings.Load(), Settings.Save() ist Crap - da kann man das AnwendungsFramework getrost seinen Job machen lassen.

      @Spaceyx' YouTube-Video
      Da wird ganz basic-mäßig einfach Textbox.Text gebunden, aber man siehts halt, und auch die Bindings in Aktion, wofür man hier ja den Sample-Code downloaden müsste (uff, uff!) ;).
      Man muss aber genau gucken, denn @SpaceyX ist von der schnellen Truppe ;) Das Settings anlegen findet im Video von 00:40 - 01:00 statt, und das Binden von Textbox-Texten daran erfolgt anschließend.
      Dateien

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

      Hi

      Hallo erstmal, ich bin neu hier... habe mich Hobbymäßig in verschiedenen Programmiersprachen versucht und jetzt hierzu eine Frage.

      Kann es sein, dass das My.Settings.Save() doch kein "Crap" ist?
      Habe ein seltsames Phänomen.
      Wenn mein Programm beim Herunterfahren von Windows beendet wird, dann werden die Einstellungen nicht gespeichert, kann das sein?

      Sonst tolle Sache, danke für den Hilfreichen Beitrag ;)

      Willkommen im Forum. :thumbup:

      Merinto schrieb:

      kann das sein?
      Sieh mal in Deinen Projekteigenschaften nach, da gibt es einen Haken, der, wenn er gesetzt ist, dafür sorgt, dass die Settings automatisch gespeichert werden.
      Projekt -> Eigenschaften -> Anwendung
      Dies gilt für VB.NET.
      Wenn Du in C# programmierst, musst Du Dich darum selbst kümmern.
      Bilder

      • Settings.png

        18,11 kB, 487×452, 1.471 mal angesehen
      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!

      Sollte in der Projekteinstellungen änderbar sein, sodass die beim Herunterfahren gespeichert werden.
      #define for for(int z=0;z<2;++z)for // Have fun!
      Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

      Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

      Ich denke, @Merinto meint das Problem, dass wenn das Prog beendet wird, weil Windows runterfährt - dass dann die Settings nicht gespeichert werden.
      Jo, um dem zu begegnen ist glaub wirklich am einfachsten, gelegentlich ein Settings.Save aufzurufen.
      Andernfalls müsste man vergleichsweise aufwändig eine Art Listener basteln, der auf die WM_ENDSESSION-WindowMessage lauscht: msdn.microsoft.com/de-de/libra…a376889%28v=vs.85%29.aspx

      Andererseits wäre so ein Listener ja vlt. generell wünschenswert, um überhaupt jede Art von in Bearbeitung befindlichen Daten sichern zu können.

      Es mag ja schick und modern wirken, wenn man sich die Bindings im Designer zusammenklickst.
      Ich schreibe jedoch immer guten alten Code (notfalls klau ich den aus der Designer-Klasse raus),
      so dass man beim Initialisieren eines Formulars sieht, was man da initialisiert. Ein Möchtegern-Profi
      fügt dann auch noch eine Zeile Kommentar hinzu, warum und wofür das Binding jetzt gerade nötig ist.
      Und Hand aufs Herz - so viele Bindings werden es nie sein, das kann man gerade noch runterschreiben.
      Vorteil: jeder Anfänger sieht, das da was mit den Bindings gemacht wird und kann das nachvollziehen.
      Wenn man die Bindings im Designer versteckt, dann sucht er sich einen Wolf. Oder er löscht die Textbox
      und legt sie neu an - und weg ist der ganze Binding-Zirkus. Also gerade für Demo-Zwecke finde ich es optimal,
      den Code hinzuschreiben, insbesondere wenn es sich um seltener eingesetzte und damit nicht so bekannte
      Bindings handelt (das war ja auch der Aufhänger dieses Artikels).
      An manchen Tagen gibt es zu allem Überfluss auch noch Ärger!

      (sorry für die späte Antwort, aber ist ja eiglich egal)
      Tja, das kann jetzt schnell ausufern in Grundsatzdiskussionen, zu 2 Themen. Ich nenne nur die Standpunkte, steige aber nicht in die Diskussion ein:
      1. Databinding als konsistentes Konzept, um Daten und Oberfläche zu trennen
        Es gibt Leute, die Databinding ablehnen, und die auch die Trennung von Daten und Oberfläche für nicht weiter wichtig halten.
        Dieses Tut jedenfalls zeigt, dass das Konzept Databinding auch auf Settings-Daten anwendbar ist.
      2. Nutzung von Designern, um BoilerPlate-Code zu reduzieren
        Viele Leute ziehen vor, ihren Code mit BoilerPlate-Code zu belasten, bzw. empfinden das gar nicht als Belastung.
        Dieses Tut jedenfalls zeigt, wie man BoilerPlate im Zusammenhang mit Settings ggfs. stark reduzieren kann, und es zeigt auch - beim Color-Dialog - eine Beschränkung davon
      Mit "Settings richtig verwenden" ist übrigens nicht ausgesagt, es sei falsch, wenn man Settings ohne Databinding verwendet (deshalb das " + an Settings binden").
      Mit Falsch meinte ich, bei jeder Settings-Zuweisung gleich ein Settings.Save nachzuschießen - weil halt sich das Anwendungsframework doch selbst darum kümmert.
      Das muss ich allerdings relativieren wegen des Punktes "Programm-Abschuss durch Windows-Runterfahren", weil in dem Fall kümmert es sich dummerweise nicht.

      Aber ich halte es für unbedingt nützlich, das Settings-Feature zu kennen, und zwar inklusive des Settings-Databinding-Features.

    Facebook
    Telefonspende