OOP, My-Namespace frage zu my.Settings

  • VB.NET
  • .NET (FX) 4.5–4.8

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

    OOP, My-Namespace frage zu my.Settings

    Hi an alle,

    ich habe die letzten Tage viel hier im Forum gelesen und versuche meine Programmierart zu verbessern (Option Strict On, kein VB-Namespace, Vermeidung des My-Namespaces)
    jedoch bin ich aktuel auf ein Problemchen gestossen, und zwar :

    Wie greife ich denn auf meine Programmsettings zu ohne den My-Namespace ?

    Also als Beispiel habe ich in den Programmeinstellungen ein Setting das mir die festgelegte Fenstergröße beim schließen speichert, diese will ich beim Programmstart wieder laden das mache ich ja in dem ich
    die jeweilige Einstellung aus den Settings lade wie z.B. : My.Settings.JeweiligesSetting

    aber selbst mit googel konnte ich nicht herausfinden wie ich dies ohne den My-Namespace mache
    wie mach ich dies denn nun "Richtig" ?

    Greets
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    asusdk schrieb:

    Wie greife ich denn auf meine Programmsettings zu ohne den My-Namespace ?
    Die My.Settings bilden in VB eine Ausnahme, die werden explizit im My-Namespace angelegt.
    Auch wenn Du ein VB-Projekt ohne explizite VB-Framework-Unterstützung erstellst, werden die Settings im My-Namespace angelegt. So ist halt die Sprachdefinition für VB.
    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!

    asusdk schrieb:

    (Option Strict On, kein VB-Namespace, Vermeidung des My-Namespaces)
    Das ist bischen zu dogmatisch gedacht, weil es gibt Ausnahmen, und wenn man weiß, was man tut, spricht nichts dagegen, diese zu nutzen.
    • Option Strict On
      jo, auch hier gibts Fälle - etwa InterOp-Programmierung, wo - begrenzt auf eine Modul-Datei - durchaus sinnvoll ist, strict Off zu proggen
      Zwar nicht schön, aber hässlich. Aber bestimmte Zwecke (zB höhere Robustheit gegenüber verschiedenen Office-Versionen) lassen sich anders kaum erreichen
    • kein VB-Namespace
      geht garnet. Alles was geht ist, dass du den GeneralImport auf diesen Namespace aus deinen Projekteinstellungen rausnimmst.
      Der Namespace ist nachwievor vorhanden, nur ihn anzusprechen ist aufwändiger, und daher kommt man von selbst auf die sinnvolleren Vorgehensweisen des ,Net-Frameworks.
      Aber auch hier gibts Sachen, die durchaus nützlich sein können: Etwa eine einfache Texteingabe kann man gut mit Microsoft.VisualBasic.InputBox() machen - aber dann halt wie gezeigt vollqualifiziert angesprochen, und dann weiß man halt, was man tut.
    • Vermeidung des My-Namespaces
      Dieser ist hauptsächlich ein Sammelsurium von ShortCuts, und indem man die ShortCuts nutzt, bringt man sich um die Chance, zu verstehen, wo die Sachen eigentlich verortet sind. Vor allem dem ObjectBrowser ist der My-Inhalt verborgen, was natürlich absolut bescheuert ist, wenn man was nachgucken möchte. Kennst du den ObjectBrowser? (Wenn nicht, unbedingt dem Link folgen, wenn doch - trotzdem nochmal reingugge, finden sich oft noch nützliche, zuvor unbekannte Details)
      Daher lieber auf die ShortCuts verzichten, und die Sachen so ansprechen, dass auch nachvollziehbar ist, wo's herkommt.
      Nur wie gesagt mitte My.Settings geht das nicht

    ok, gut zu wissen das es da auch Ausnahmen geben kann, also ist es im Prinzip einfach besser die jeweiligen Funktionen komplet auszuschreiben ? oder gibt es da auch Ausnahmen ?
    @ErfinderDesRades Danke für den Link werd ich mir wenn ich später daheim bin direkt ansehen =)
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    Du musst halt das Namespace-Konzept verstehen:
    Unter einen Namespace sind ein Haufen Klassen und Module untergeordnet, sodass sie ohne Importe nur komplett ausgeschrieben addressierbar sind.
    Das führt zu sehr hässlichen und unübersichtlichen Code.
    Deshalb kann man Namespaces in eine Datei importieren, mit der Imports-Anweisung.
    Je nachdem, womit der Code einer Datei sich beschäftigt, ists sinnvoll, verschiedene Namespaces zu importieren, also wo du mit Controls bschäftigt, importiere System.Windows.Forms - wo du mit Dateioperationen hantierst, importiere System.IO, nicht selten brauhste auch beides, oder halt auch ganz annere Namespaces.

    Nu sind My und Microsoft.VisualBasic aber Namespaces, wo ziemlich viel Müll drinne steht.
    Die paar Ausnahmen in MVB, die du dennoch brauchen kannst, die schreib halt komplett aus - dann weiss man woran man ist.
    Im My-Namespace wüssete ich ausser den Settings grad garnix brauchbares, und die Settings ruft man ja per se vollqiualifiziert auf: My.Settings.XYZ

    Das verheerende an MVB ist, dasses als GeneralImport voreingestellt ist - diese "Kleinigkeit" gilt es abzustellen.
    GeneralImporte sind inne Projekteinstellungen festgelegt, und importieren den betreffenden Namespace per se für alle Dateien.
    Also wenn du den MVB-GeneralImport deaktivierst, dann kannste gleich paar weitere deaktivieren, weil was brauchst du System.Collections, System.Drawing, System.Threading.Task oder System.Xml.Linq als Generalimport in allen Dateien?
    Solch sollte man gezielt importieren in genau den CodeDateien, wo man den Kram daraus auch braucht.

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

Facebook
Telefonspende