Mitgliederverwaltung - Hilfe bei der Erstellung sauberen Codes

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.

mach einfach so: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.

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.

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


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..

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.

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.

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

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.

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.

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)

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.

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