Mitgliederverwaltung - Hilfe bei der Erstellung sauberen Codes

  • VB.NET
  • .NET 4.5

Es gibt 139 Antworten in diesem Thema. Der letzte Beitrag () ist von DerSmurf.

    Ich sehe, dass für das tDS gemeldet wird: HasChanges = False. Den Grund werd ich aber wohl nicht (so schnell?) ermitteln. tDS existiert bei mir nicht mehr und die Helpers hab ich nie verwendet.
    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.
    Ja, du hast Recht.
    Das Form Closing Event in meinen Helpers sieht folgendermaßen aus:

    VB.NET-Quellcode

    1. Private Sub _HandleFormClosing(sender As Object, e As CancelEventArgs)
    2. If e.Cancel Then Return
    3. Dim frm = DirectCast(sender, Form)
    4. If Not HasChanges.Invoke() Then Return
    5. Save(frm, False)
    6. e.Cancel = False
    7. End Sub

    Wenn ich Zeile 4 auskommentiere, If Not HasChanges.Invoke() Then Return wird alles gespeichert wie es soll.
    @ErfinderDesRades ich glaube du müsstest uns aufklären, was ich hier falsche mache. Also warum mit meiner Prozedur HasChanges = False ist, obwohl mein Code an sich ja richtig zu sein scheint.

    VaporiZed schrieb:

    tDS existiert bei mir nicht mehr

    Du hast mir bei meinen Anfangsprojekten sehr im Umgang mit tDs geholfen. Also vermute ich mal, dass du dich lange damit befasst hast.
    Warum bist du davon ab?

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

    Neu

    mach einfach so:

    VB.NET-Quellcode

    1. Private Sub BTNSaveOwnData_Click(sender As Object, e As EventArgs) Handles BTNSaveOwnData.Click
    2. BSeigeneDaten.EndEdit()
    3. End Sub
    Problem war, dass die BindingSource im EditModus verblieb.
    Wird über eine BindingSource ein Datensatz verändert, so geht die bs automatisch in den EditModus. Also sie nimmt Daten entgegen, leitet die Änderungen aber noch nicht an die zugrundeliegende DataRow weiter.
    Das deshalb, damit man die Möglichkeit hat, eine Eingabe zu canceln.
    Erst wenn auf einen anderen Datensatz gewechselt wird, committet die BindingSource die Änderungen in die DataRow.
    Dieser Wechsel des Datensatzes findet auf dem Form aber nicht statt - daher wie gesagt: die bs blieb im EditMode und transferierte keine Änderungen in die DataRow.

    Zweiter Denkfehler ist, dass du bei gebundenen Controls noch Code schreibst, um Werte aus den Controls in den Datensatz zu bringen.
    Die sind - dank des Bindings - ja schon längst da.
    Ist dir das nicht aufgefallen, beim Debuggen - etwa beim Angucken der ownaddress-Properties im Lokal-Fenster?



    Wobei ich mich jetzt aber auch wunder, dass die Daten eben doch schon im Datensatz sind, wo ich doch dachte, die würden erst bei EndEdit übernommen.
    Also ist der EditMode-Vorgang wohl anders: Die Änderungen werden übernommen, nur der Rowstate wird nicht auf RowState.Changed gesetzt.



    Lustigerweise habe ich in der Save-Routine eine Schleife, die für alle BindingSources .EndEdit() aufruft.
    Das ist wohl für diesen Anwendungsfall ein Fehl-Design, weil die Save-Methode wird so ja garnet erst aufgerufen.
    Ich bastel das mal ein bischen um.

    Neu

    Huhu und willkommen zurück :o)
    Nein, die Sinnlosigkeit meines Codes ist mir nicht aufgefallen.
    Ich war beim Debuggen wahrscheinlich zu sehr darauf bedacht herauszufinden, warum der Hund meine Änderungen nicht speichert. Da habe ich das offensichtliche übersehen.

    Ich habe derweil mal ein wenig weitergemacht. Die Settings wären dann fertig.
    Wie findet ihr das optisch und den Code dahinter?
    Edit: Bitte daran denken, dass das ganze sowohl per Maus/Tastatur, als auch Touch bedienbar sein soll.
    Dateien
    • Angelmarken02.zip

      (324,29 kB, 6 mal heruntergeladen, zuletzt: )

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

    Neu

    DerSmurf schrieb:

    Wie findet ihr das optisch
    Ich hab lieber, wenn auf Buttons draufsteht, was passiert, wnn man drückt.
    ZB beim Start-Screen das Icon mit dem Buch mit dem @ - wenigstens ein Tooltipp wäre mir hilfreich.
    Wenn man bei letztgenannten (mutig) draufdrückt, kriegt man eine Tabelle mit Addressen zu sehen - aha, und was soll ich mit dene?
    Und wieder mir tw. unklare Buttons:
    + kann (sogar ich!) mir denken: eine Addresse zufügen
    Der nächste Button unklar: soll ich der gewählten Addresse eine Mail schreiben, oder - ah! - ich soll sie vermutlich bearbeiten!
    Weil - nächster Button sieht noch viel mehr aus, als solle ich der Addresse eine Mail schreiben.
    Dann kommt ein - - vermutlich wird die angewählte Addresse dann irgendwie kleiner - oder?
    Dann kommt eine Textbox - aha.
    Zuguterletzt ein x - Button - das lässt mich vermuten, die Textbox sei eine Filter-Eingabe.

    Der Einkauf-Tab ist noch unfertig.

    Das Icon mit dem Einkauf-Korb scheint mal "Einkauf" zu bedeuten, mal "Artikel".

    Also insgesamt ist mir an vielen Stellen unklar, wo ich bin, und was ich grad bearbeite. Für mich wirkt sich das Verbergen der TabReiter also sehr negativ aus.
    Aber vermutlich wird man sich schnell einfinden, wenn man damit produktiv arbeitet.
    Idee: Vielleicht den Text des aktuellen Tabreiters einfach als Form-Text setzen

    Ich würd übrigens empfehlen, anzufangen, UserControls einzusetzen.
    Einer meiner Best-Practices ist: Pro TabPage ein UserControl.
    Musste jetzt nicht alles für umbauen, sondern kannste so lassen, aber für den Verkauf-Tab scheint mir ein ucl doch sehr angebracht.
    Weil der wird vermutlich recht komplex werden, und mit verknüpften BindingSources und Gui-Logik und Kram - das will man vlt. nicht alles im MainForm rumfahren haben.

    Ansonsten würde ich vmtl. sämtliche button-Klickse des MainForms in eine Methode stopfen, mit einem Select Case.
    Und einzeilige Anweisungen auch gleich im Case abhandeln, mehrzeiliges in Methoden-Aufrufe, wie du sie ja schon hast.
    So liesse sich der Main-Form-Code wohl auf 100 Zeilen zusammen-drücken.

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

    Neu

    Ich hab gestern noch "schnell" drübergeschaut - Hauptsächlich den Code.
    Mir ist dabei aufgefallen, dass du den betätigten Button umständlich abfängst.
    Einfacher ginge das mit

    VB.NET-Quellcode

    1. Select Case True
    2. Case sender is btnXY : mach was
    3. Case sender is btnYZ : mach was anderes
    4. End Select


    Ich setz mich die Tage mal hin und kürz' das mal zusammen, lade ich dann hier hoch, wenn fertig.
    Ggf. würde sich hier auch ein Mdi anbieten, dann hätte man quasi alles auf der Main-Form rumfliegen - den Code aber auf der jeweiligen Form..
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Neu

    ErfinderDesRades schrieb:

    Ich hab lieber, wenn auf Buttons draufsteht, was passiert, wnn man drückt.

    Ich persönlich finde die Icons auf den Buttons deutlich schöner als den Text.
    Aber du hast schon recht. Für mich ist logisch, welches Icon was anzeigt / macht. Aber das liegt wohl ausschließlich daran, dass ich die auf die Buttons gezaubert habe.
    Wenn ich dran denke, dass auch meine Leute mit dem Programm arbeiten sollen, macht wohl eine eindeutige Bezeichnung mit Namen den meisten Sinn.
    Den Rest (TabReiter anzeigen, aktuelle TabPage als Form-Text anzeigen), lasse ich dann weg - also keine Tab Reiter, kein Form-Text - denn dann sollte die Button Navigation ja Problemlos funktionieren)

    ErfinderDesRades schrieb:

    Der Einkauf-Tab ist noch unfertig.

    Hier habe ich noch garnicht angefangen. Das kommt jetzt als nächstes.
    Aber ich dachte mir Schritt für Schritt ist für euch einfacher nachvollziehbar, bzw. kontrollierbar. Ist dann nicht so viel auf einmal und eben immer nur ein Punkt (bzw. eine TabPage / ein Thema)

    ErfinderDesRades schrieb:

    Ich würd übrigens empfehlen, anzufangen, UserControls einzusetzen.

    Ich habe noch niemal nicht mit UserControls gearbeitet. Hast du hier evtl. einen Link?
    Also wenn ich danach Google finde ich zwar mehr als genug Einträge, aber ich kann die schlechten nur sehr schwierig von den guten Unterscheiden.

    ErfinderDesRades schrieb:

    Ansonsten würde ich vmtl. sämtliche button-Klickse des MainForms in eine Methode stopfen, mit einem Select Case.

    Das meinst du so?:

    VB.NET-Quellcode

    1. 'Private Sub BTNShowownSupplier_Click(sender As Object, e As EventArgs) Handles BTNShowSupplier.Click
    2. ' Me.TCSettings.SelectedTab = TPSupplier
    3. 'End Sub
    4. 'Private Sub BTNAddSupplier_Click(sender As Object, e As EventArgs) Handles BTNAddSupplier.Click
    5. ' BSLieferant.EditNew(Of frmEditSupplier)
    6. 'End Sub
    7. 'Private Sub BTNEditSupplier_Click(sender As Object, e As EventArgs) Handles BTNEditSupplier.Click
    8. ' BSLieferant.EditCurrent(Of frmEditSupplier)
    9. 'End Sub
    10. 'Private Sub BTNDelSupplier_Click(sender As Object, e As EventArgs) Handles BTNDelSupplier.Click
    11. ' DeleteSupplier()
    12. 'End Sub
    13. Private Sub BTNClickEvents(sender As Object, e As EventArgs) Handles BTNShowSupplier.Click, BTNAddSupplier.Click, BTNEditSupplier.Click, BTNDelSupplier.Click
    14. Select Case True
    15. Case sender Is BTNShowSupplier : Me.TCSettings.SelectedTab = TPSupplier
    16. Case sender Is BTNAddSupplier : BSLieferant.EditNew(Of frmEditSupplier)
    17. Case sender Is BTNEditSupplier : BSLieferant.EditCurrent(Of frmEditSupplier)
    18. Case sender Is BTNDelSupplier : DeleteSupplier()
    19. End Select
    20. End Sub

    Also so wie auch @Trade angemerkt hat.
    Und dann wirklich eine Sub für alle Click Events auf der ganzen Form?
    Wird das nicht ganz schön unübersichtlich?

    Neu

    DerSmurf schrieb:

    Wird das nicht ganz schön unübersichtlich?

    Ich hab dein Projekt mal überarbeitet. Es gibt nen Ordner "TraglVariante", da liegt alles drin - ich hab in den Projekteigenschaften umgestellt auf "frmMain", dann nimmt er nur meine Forms etc.
    Außerdem hab ich (glaube ich) deinen Code ansonsten unberührt gelassen).
    Jo, ich find das so gelungen - musst die Größen der Schriften und Boxen noch anpassen (hat der beim Kopieren nicht mit übernommen) - ansonsten ist der Code nun aufgeräumt und kurz gehalten, und vor allem:
    Jede Form hat jetzt ihren eigenen Code (kannst dir die UCL's quasi sparen).

    Probier mal durch, das was ich jetzt testen konnte hat geklappt. Kommentare hab ich wo nötig dazu getickert.
    Dateien
    • Angelmarken01.zip

      (352,06 kB, 4 mal heruntergeladen, zuletzt: )
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

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

    Neu

    Da grad kein anneres Sample zur Hand habichmal den Verkauf-Tab in ein Ucl verlagert.
    War super-einfach, weil keinerlei dahintersteckende Logik mit umzuziehen war.
    Bei den anderen Tabs müsste man bisserl mehr denken.

    DerSmurf schrieb:

    Und dann wirklich eine Sub für alle Click Events auf der ganzen Form?
    Wird das nicht ganz schön unübersichtlich?
    Jo, bischen.
    Liegt genau daran, dass du bislang ohne ucls oder Tragls Patent-Mdi-Childs arbeitest.
    Da sind nun 17 Buttons aus verschiedenen Programm-Bereichen (Home, Personen, Artikel, Lieferanten, eigeneDaten) zusammengeworfen.
    Wie gesagt, ich finde, das geeeht noch - der MainForm-Code liegt noch gut unter 300 Zeilen.
    Aber wie gesagt, wenn du schön haben willst, könntest du die Bereiche mittels ucls auch designerisch und code-technisch differenzieren.
    Und innerhalb eines Bereiches ist eine Sammel-Button-Click - Methode übersichtlicher als viele einzelne EventHandler.
    Weil die Buttons gehören dann ja auch thematisch zusammen.

    "Einstellungen" finde ich übrigens einen komischen Namen für das, wasses da gibt.
    In meiner Welt hiesse das "StammDaten" (und hätte natürlich sein eigenes Ucl).

    Ansonsten verläuft deine Entwicklung recht ähnlich, wie ich immer vorgehe:
    Anfangen mit Stammdaten - die bekommen ein sehr plumpes GUI, nur für Add/Remove/Edit.
    Gui-technisch anspruchsvollere Dinge wie PersonenVerwaltung oder gar Verkauf auf eigene Tabs auslagern.
    Evtl. steht auch mal ein uclLieferung an, könnte ich mir vorstellen.
    Dateien

    Neu

    Danke für die Mühe @tragl
    So unübersichtlich finde ich alle Click Events in einer Sub dann doch nicht :)
    Und danke für die Codeverbesserungen!

    Ich bin mir aber nicht sicher, ob mir die Mdi Variante gefällt. Zumindest für dieses Projekt.
    Ich glaube die einzelnen MDIChilds und deren Sichtbarkeit am oberen Rand des Programmes verwirrt den ein oder anderen.
    Da ist glaube ich die ucl Variante einfacher in der Bedienung - allerdings lege ich mir die MDI GEschichte mal auf Seite. Das werde ich sicherlich mal brauchen.
    Wenn ich euch richtig verstanden habe, geht es aber (egal ob nun mit tragls mdi Idee, oder mittels UserControl) nur darum, den Code aufzuteilen.
    In jede meiner TabPages stellt eine Einheit dar, daher sollte der Code auch entsprechend separiert werden und nicht einfach auf die MainForm geklatscht werden. Stimmt das so?
    Es ist bei meinem Projekt nicht unbedingt notwendig, weil die Übersichtlichkeit durch die überschaubare Menge an Code noch da ist, aber bei größeren Projekten wirds sonst wuselig im Code.
    Warum kann ich hierfür nicht Regions verwenden? Das separiert mir doch den Code auch irgendwie?

    ErfinderDesRades schrieb:

    "Einstellungen" finde ich übrigens einen komischen Namen für das, wasses da gibt.

    Da hast du recht. Stammdaten ist logischer.

    Edit: Kann ich eigentlich innerhalb meiner Solution in VS Ordner anlegen und da rein kopieren, wie ich will?
    Für jede Form einen eigenen Ordner, z.B.? Bastelt VS mir das beim kompilieren alles immer schön zusammen, oder muss ich auf irgendwas achten?

    Neu

    DerSmurf schrieb:

    Ich glaube die einzelnen MDIChilds und deren Sichtbarkeit am oberen Rand des Programmes verwirrt den ein oder anderen.

    naja, die "Tabs" kann man sicher ausblenden. Dann haste das gleiche wie bei dir, nur sauber gelöst und ohne UCL.
    Der Vorteil ist, du kannst jede Form dafür nutzen und brauchst nicht extra ein UCL anlegen (ist bestimmt genauso einfach / schwierig) aber ich finde forms sinnvoller irgendwie. Ein UCL würde sich in meinen Augen eher anbieten, wenn du die gleichen Controls
    oder die gleiche Ansammlung an Controls (z.B. Edit-Dialog) an vielen Stellen nutzen willst - ach wobei, auch das kann ja eine Form ...
    ach jetzt fällt's mir wieder ein: Wenn du einen Edit-Dialog z.B. auf mehreren mit einbinden willst, dann würde ich ein UCL als Edit-Dialog anstatt einer Form nutzen (wenn's an mehreren Stellen passiert).
    Das UCL kannste dann auf deine Form(s) ziehen und da benutzen.
    Ich hab z.B. einen Twain-Dialog zum Scannen gebaut, da nutze ich ein UCL als Platzhalter für die Thumbnails
    der gescannten Images. Das UCL wird dann codeseitig vervielfacht und positioniert.

    DerSmurf schrieb:

    Code auch entsprechend separiert werden und nicht einfach auf die MainForm geklatscht werden. Stimmt das so?

    ja

    DerSmurf schrieb:

    Kann ich eigentlich innerhalb meiner Solution in VS Ordner anlegen und da rein kopieren, wie ich will?

    ja
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

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

    Neu

    tragl schrieb:

    Der Vorteil ist, du kannst jede Form dafür nutzen und brauchst nicht extra ein UCL anlegen (ist bestimmt genauso einfach / schwierig) aber ich finde forms sinnvoller irgendwie. Ein UCL würde sich in meinen Augen eher anbieten, wenn du die gleichen Controls
    oder die gleiche Ansammlung an Controls (z.B. Edit-Dialog) an vielen Stellen nutzen willst - ach wobei, auch das kann ja eine Form ...

    Ich verstehe nicht den Unterschied, ob ich nun ein UCL anlege, oder eine Form.
    Ist doch letztlich (auch während des Programmierens) dasselbe?
    Ich erstelle eine Form / ein UCL, klatsch da zwei Buttons drauf, mache Code dahinter.
    Dann ziehe ich die UCL auf die Form, oder teile meiner MDI Variante mit, dass es die Form anzeigen soll.

    Neu

    Kannst beides machen. Beim mdi wär's weniger sinnvoll, weil du forms direkt darüber ansprechen kannst.
    Und wie gesagt - der Nutzen von UCL (in meinen Augen): ein von dir erstelltes UserControl an jeder Ecke deiner Anwendung nutzbar (auch auf Forms).
    Forms kannst du nicht auf Forms nutzen - höchstens als Dialog oder eben als Child.
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Neu

    Kannst machen, wie Du willst. Aber ein Form ist nun mal … ein Formular. Wie eines in ner Behörde: Eine Ansammlung von Controls, um bestimmte Daten einzugeben und diese dann simpel oder komplex weiterzuverarbeiten. Ein UC ist eher dafür gedacht, dass man bestimmte Dinge, die ein einzelnes Control nicht allein hinbekommt, zusammenfasst und dieses mit mindestens 2 Instanzen (ggf. können diese 2 Instanzen auch in unterschiedlichen Programmen zum Einsatz kommen) nutzt. Ein UC mit nur einer Instanz geht m.E. am Sinn des Erfinders (und damit meine ich nicht EdR!) vorbei. Klar, so kann man auch die Nutzung eines Forms umgehen. Aber gedacht war es dafür m.E. nicht.

    DerSmurf schrieb:

    Ich weiß immer nicht, was ich tun soll, wenn zwei Menschen mir was unterschiedliches raten
    Ausprobieren und eine Lösung für Dich selbst finden. Ich springe bei mir dauernd von Form zu (Sub)Form. Oder ich hab TabControls.
    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 schrieb:

    Ausprobieren und eine Lösung für Dich selbst finden.

    @DerSmurf: richtig, ich habe dir mit meiner Änderung nur aufzeigen wollen, dass es auch ganz ohne UCL geht und der Code dennoch sauber getrennt ist.

    So wie du das vor hattest (funktioniert ja auch!) wäre der gesamte (oder fast) Anwendungscode auf deiner Haupt-Form gewesen. Wenn das Teil dann doch mal wächst, weil du mit der Zeit ggf.(bzw. bestimmt sogar) noch das ein oder andere
    dazuprogrammierst, dann wird's irgendwann richtig unübersichtlich. UNd mit getrenntem Code wüsstest du: Beim Lieferant geht was nicht richtig -> ich muss also auf frmLieferant nachschauen und anders programmieren.
    Also mach, was dir am besten gefällt und was für dich am einfachsten zu handhaben und zu warten ist. Hast ja nu 3 Varianten:

    - deine eigene
    - UCL
    - Forms (mit Mdi)
    :thumbup:
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Neu

    Naja, ich habe nur zwei varianten.
    Dass meine eigene nichts (oder mit zunehmenden Code nicht lange) taugt, habe ich eingesehen.

    VaporiZed schrieb:

    Oder ich hab TabControls.

    TabControls habe ich ja hier in meinem Projekt auch. Aber es geht ja um die saubere Trennung des Codes.
    Also siehst du es auch so, Mdi macht hier mehr Sinn. Aber MDI funktioniert ja nicht gescheit mit TabControls, denn es macht ja keinen Sinn in die einzelnen TabPages ein MDIChild reinzuschmeßen - dann brauch ich ja das TabControl nicht.
    Den Sinn von UserControls siehst du eher darin, wenn ich diese in meinem Programm öfters als einmal verwende.

    Neu

    TabControls habe ich, wenn ich wenig Code, aber viele Controls habe, die ich entweder thematisch gruppieren will oder Eingaben Schritt-für-Schritt tätigen will.
    Forms kommen bei mir zum Einsatz, wenn ich Dinge trennen will: Datensatz anlegen, Daten buchen, Statistiken erstellen.
    MDI nutze ich gar nicht, da bei mir Forms immer SubForms anderer sind (außer natürlich das MainForm). Ich habe ein Hauptmenü, von dort gehe ich - falls notwendig - in SubForms.
    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

    DerSmurf schrieb:

    Aber MDI funktioniert ja nicht gescheit mit TabControls

    Das Mdi läuft über ein TabControl. Denn damit schaltest du zwischen den Childs um... die kannst du aber wie gesagt bestimmt auch ausblenden. Das sind die Buttons, die oben erscheinen wenn du ein Child öffnest. Schau mal auf der frmMain genau nach ;)
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Neu

    Stimmt.
    Es wird mir auf der MainForm im übrigen das ToolStrip nicht angezeigt.
    Ich sehe da ein großes dunkelgraues Feld (unten). Das kleine tabMdi und MenuStrip1.
    Das große graue Feld kann ich aber nicht anklicken. Was ist das?
    Und ich musste, bevor dein Projekt lauffähig ist, aus der Resx Datei dei RessourcenBilder entfernen, weil diese nicht gefunden wurden.
    Und dann natürlich die entsprechende Zugriffe auskommentieren.

    Also nochmal zum Verständniss. Ich komme nicht so recht hinterher.
    @VaporiZed macht halt für alles was ausgelagert gehört eine eigene Form. Dann würde sich aber bei mir hier z.B. ein neues Fenster öffnen, wenn ich die Einstellungen anzeigen lasse.
    Oder doch nicht unbedingt?

    VaporiZed schrieb:

    MDI nutze ich gar nicht, da bei mir Forms immer SubForms anderer sind (außer natürlich das MainForm)

    Was bedeutet das hier? Eben doch nicht das "normale" ​Dim Settings as new frmSettings / Settings.showdialog?

    Und bei MDI habe ich auch für alles was ausgelagert gehört eine eigene Form, zeige diese aber als MDIChild in meiner Hauptform, bzw. derm MDIParent an?