Mitgliederverwaltung - Hilfe bei der Erstellung sauberen Codes

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

Es gibt 244 Antworten in diesem Thema. Der letzte Beitrag () ist von tragl.

    DerSmurf schrieb:

    Warum gibt es hier keine "GetMarkeRows"?
    Ähm GetMarkeRows() scheints ja zu geben - was es nicht gibt ist: GetArtikelRows() ( - oder?)

    Kann ich mir nur so erklären, dass die Tabelle Artikel früher einmal Marke hiess, und dann umbenannt wurde.
    Umbenennen von Tabellen im TypDataset funktioniert nicht richtig.
    Vermutlich kannst du im Dataset-DesignerCode noch allerlei Vorkommnisse von "Marke" finden, wo eiglich "Artikel" stehen müsste.

    Tja, doof. Mit viel Fingerspitzengefühl kann man versuchen, dass mit schrittweisem TextErsatz zu korrigieren, aber heikel.
    Weil da hängen ja auch noch Form-Databindings dran, die in Form-Designer-Dateien gesetzt sind.
    Das wird sehr hässlich, wenn ein DGV auch nur eine Spalte hat, die an etwas gebunden ist, was umbenannt wurde.
    Also wenn du da dran gehst: Backup machen, und nach jedem Schritt auch ordentlich durch-testen, dass alles(!) noch funktioniert.


    Es ist aber noch verworrener.
    Nach meim Dafürhalten müsste es eine Property LieferPosition.ArtikelRow geben. Also kein .GetArtikelRows() als Mehrzahl, sondern .ArtikelRow in einzahl.
    Weil jede LieferPosition ist mit genau einem Artikel verknüpft.
    Du solltest auch in deinem Code klarer Benamen. Dass man einzelne Rows von Row-Arrays unterscheiden kann.
    Ungefähr so:

    VB.NET-Quellcode

    1. Dim Lieferungrow = BSLieferung.At(Of LieferungRow)
    2. Dim Lieferpositionrows = Lieferungrow.GetLieferpositionRows
    3. For Each Lieferposition As LieferpositionRow In Lieferpositionrows
    4. ' hier weiss ich nicht: gibt es wirklich Lieferposition.GetMarkeRows, oder ist nicht Lieferposition.ArtikelRow gemeint?
    5. ' weil ersteres wäre Plural, letzteres singular
    6. Dim Artikels = Lieferposition.GetMarkeRows
    7. Dim Artikel = Lieferposition.ArtikelRow
    8. ' Oder heisst es gar:
    9. Dim Artikel = Lieferposition.MarkeRow '?
    10. Next
    nicht wahr: wenn ich das so angucke beschleicht mich wieder das gefühl, dass mir hier malwieder Phantasie-Code vorgesetzt wird, der bei dir so garnet existiert.
    Da kann ich mich dann dumm und dämlich drüber wundern und nachdenken...

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

    ErfinderDesRades schrieb:

    Nach meim Dafürhalten müsste es eine Property LieferPosition.ArtikelRow geben. Also kein .GetArtikelRows() als Mehrzahl, sondern .ArtikelRow in einzahl.

    Ja hiermit hast du absolut recht. Ist ja immer exakt eine Artikelrow. Wegen des umbennens der Table wird daraus Dim ArtikelRow = Lieferposition.MarkeRow und alles klappt.

    Zur Bennenung:

    VB.NET-Quellcode

    1. Dim Lieferungrow = BSLieferung.At(Of LieferungRow) 'EINE ROW
    2. If msgQuestionWarning($" Die Lieferung vom {Lieferungrow.Datum} wird gelöscht.{Environment.NewLine}Sind Sie sicher?") = DialogResult.Yes Then
    4. Dim LieferpositionRows = Lieferungrow.GetLieferpositionRows 'VIELE ROWS
    5. For Each Lieferposition As LieferpositionRow In LieferpositionRows ' EINE ROW IN VIELEN ROWS
    6. Dim ArtikelRow = Lieferposition.MarkeRow 'EINE ROW
    8. Next
    10. Lieferungrow.Delete()
    11. Dts.SaveDts()
    12. End If


    Aber hiermit hab ich ein Problem:

    ErfinderDesRades schrieb:

    wenn ich das so angucke beschleicht mich wieder das gefühl, dass mir hier malwieder Phantasie-Code vorgesetzt wird, der bei dir so garnet existiert.

    Hier verschleichst du dich gewaltig.
    Allerdings verstehe ich nicht, wie du auf den Gedanken kommst? Es mag sein, dass ich ab und zu (regelmäßig) komitschen Code produziere. Aber hier!?
    Ich suche letztlich alle Artikel, die in einer Lieferung enthalten sind. (DataSet Bild im letzten Post), um eine die Menge in Artikel.Lagermenge zu ändern.
    Also Lieferungrow --> Schleife durch alle Lieferpositionen --> für jede LieferpositionRow den Artikel

    Edit:
    Ich hau jetzt auch mal meine Solution ran (dann hast du den Beweis xD). Aber ich weiß nicht ob meine herangehensweise die richtige ist.
    Ich habe wie gesagt in der Artikel Table eine Column "Lagerbestand" hinzugefügt. Dieser wird beim Verkauf einer Marke entsprechend reduziert und beim Einkauf einer Marke (diese Funktion ist neu dazu gekommen) erhöht.
    Ebenso ist die frmEinkauf (ToolStrip Einkauf) hinzugekommen, um den Kauf (also meinen Kauf) von Margen zu speichern und den Lagerbestand entsprechend zu erhöhen.

    Aber letztlich kann ich den Lagerbestand ja auch errechnen (Liefermenge abzgl. der verkauften Marken) - ohne diese in einer DataColumn zu speichern.
    Bitte schau mal rüber, ob mein Ansatz so taugt, oder ob ich heir auf dem Holzweg bin,
    Dateien

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

    DerSmurf schrieb:

    Hier verschleichst du dich gewaltig.
    nö - ich lag genau richtig.
    In obigem Code postulierst du:

    DerSmurf schrieb:

    VB.NET-Quellcode

    1. Dim Artikel = Lieferposition.GetMarkeRows
    Und das hat nie in deim Code gestanden.
    In deim Code stand - wie ich jetzt nachlesen kann:

    DerSmurf schrieb:

    VB.NET-Quellcode

    1. Dim ArtikelRow = Lieferposition.MarkeRow
    (oder täuschige ich mich?)


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

    Du täuscht dich.
    Warum sollte ich fragen, warum mein Code nicht funktioniert (Dim Artikel = Lieferposition.GetMarkeRows), wenn ich selber auf die Lösung (Dim ArtikelRow = Lieferposition.MarkeRow) kommen würde?
    Und da ich auch deine Benennungskritik wahrgenommen habe, wird aus Artikel, eine ArtikelRow.
    Und dass ich meinen falschen Code, durch was korrektes ersetze und dabei eben die "Kritik" mit umsetze, sollte keines Kommentars bedürfen.

    So, da ja nun (hoffentlich) geklärt ist, dass ich dich nicht bitte, irgendwelchen ausgedachten Phantasiecode zu prüfen, versuche ich nochmal zum Thema zu kommen:

    DerSmurf schrieb:

    [...] ich weiß nicht ob meine herangehensweise die richtige ist.
    Ich habe wie gesagt in der Artikel Table eine Column "Lagerbestand" hinzugefügt. Dieser wird beim Verkauf einer Marke entsprechend reduziert und beim Einkauf einer Marke (diese Funktion ist neu dazu gekommen) erhöht.
    Ebenso ist die frmEinkauf (ToolStrip Einkauf) hinzugekommen, um den Kauf (also meinen Kauf) von Margen zu speichern und den Lagerbestand entsprechend zu erhöhen.

    Aber letztlich kann ich den Lagerbestand ja auch errechnen (Liefermenge abzgl. der verkauften Marken) - ohne diese in einer DataColumn zu speichern.
    Bitte schau mal rüber, ob mein Ansatz so taugt, oder ob ich heir auf dem Holzweg bin,


    Upload siehe Post 222

    Sorry, der VorPost ist mir entgangen.
    Zu der FRage, ob "Lagerbestand" im Artikel eine gute Idee ist - jo, ich glaub, hat Vor- und Nach-teile. Ist richtig, dass das eigentlich redundant ist, weil man ja alle Einkäufe und Verkäufe verrechnen kann.
    Aber das kommt mir iwie unheimlich vor, von jetzt bis in Ewigkeit sämtliche Ein- und Ver-käufe vorhalten zu müssen, weil sonst am Ende die Lagerbestände verrückt spielen.

    In die Anwendung guck ich demnächst mal rein, kann aber bis WE dauern.

    ErfinderDesRades schrieb:


    Zu der FRage, ob "Lagerbestand" im Artikel eine gute Idee ist - jo, ich glaub, hat Vor- und Nach-teile. Ist richtig, dass das eigentlich redundant ist, weil man ja alle Einkäufe und Verkäufe verrechnen kann.
    Aber das kommt mir iwie unheimlich vor, von jetzt bis in Ewigkeit sämtliche Ein- und Ver-käufe vorhalten zu müssen, weil sonst am Ende die Lagerbestände verrückt spielen.


    Ich werfe mal weitere Stichworte rein: Umfirmierung (Mandant ändert sich, in mir bekannten Warenwirtschaften muss der Mandant eingefroren werden und der "Betrieb" entsteht quasi aus einer Kopie der relevante Daten neu) oder Inventur, Lagerbestandskorrekturbuchungen. Gibt sicher noch mehr Gründe.

    ich würde den Artikelbestand mit einem Lagerort bzw. Standort verknüpfen - angenommen du machst nen 2. oder 3. Laden auf, dann kannste das Programm da sofort nutzen und hast alles sauber.
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    @Dksksm
    Mein Programm versteht sich nicht als Warenwirtschaftssystem.
    Hauptaufgabe des Programmes ist es die Kundendaten (also die Adressen der Angelmarkenkäufer) auf angenehmere Art zu speichern und verwalten, als das mit Zettel und Excel möglich ist. Außerdem will ich mir eben das abgetippelt von ein paar Hundert Adressen pro Jahr sparen.
    Das ganze Markeneinkauf - Markenverkauf, soll die Geschichte dann nur abrunden.
    Dient aber eher zu Kontrollzwecken, also um mal zu gucken ich hab 200 Marken bekommen 100 verkauft, dann müssen noch 100 da sein.
    Buchführungsrelevant ist das hier tatsächlich nicht, da ich mit den Angelmarken nichts verdiene.
    Dennoch ist

    Dksksm schrieb:

    Lagerbestandskorrekturbuchungen.
    ein gutes Stickwort.
    Kann ja mal ne Marke kaputt gehen oder so.

    @tragl Stand jetzt bin ich mir sicher, dass ich keinen weiteren Standort öffnen werde. Aber natürlich weiß ich nicht, wie ich das in 10 Jahren sehe. Sicher fest steht aber, dass ich an einem neuen Standort Angelmarken für einen anderen Verein, bzw. von einem anderen Amt kaufen werde.
    Ich könnte also in beiden Filialen das Programm jeweils eigenständig laufen lassen. Einen Lagerort einzupflegen tut also nicht Not.

    ... und dann willst du doch mal vom anneren Standort aus gucken, was bei dem ersten so los ist und schon geht das Gerenne los bzw. die Nachprogrammiererei.
    Dann mach's doch gleich richtig ;)
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Wie gesagt, ich kann natürlich nicht ausschließen, dass ich irgendwann einen weiteren Standort eröffne.
    Aber ich werde definitiv nicht von Standort 1 schauen wollen, oder müssen, wies bei Standort 2 aussieht.
    Also kann diese Funktion getrost weg gelassen werden, ohne dass ich Sorge haben muss, diese später implementieren zu müssen.

    Passt meine Idee mit dem Lagerbestand dann so, oder würdet ihr das anders angehen?

    DerSmurf schrieb:

    oder würdet ihr das anders angehen?

    jo, so wie ich gesagt hatte (egal ob du das mal brauchst oder nicht):

    - Tabelle Lagerort

    -ID
    -Bezeichnung oder Nummer
    -ArtikelID
    -Bestand

    ArtikelID darf dann pro Lagerort nur 1x vorkommen und fertig ist der Lack

    Ansonsten wenn du das gar nicht willst, dann in deine Artikel-Tabell ne Spalte mit "Bestand" einbauen und die muss eben bei jeder "Buchung" nen korrekten neuen Wert kriegen
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    So, nachdem ich ein paar Wochen nicht so recht weiter gekommen bin, mache ich mich nun wieder intensiver an die Fertigstellung dieses Programmes.
    Soweit ist auch erstmal alles klar, ich müsste jetzt ein gutes Stück Code alleine schaffen und präsentiere dann, wenns soweit ist, mein fertiges Ergebnis, damit ihr meckern könnt :o)

    Aber eine Frage ist noch offen.
    Die frmFinishOrder hat ein KeyDown und auch ein KeyPress Event (und KeyUp habe ich natürlich auch probiert).
    Diese Events werden jedoch nicht gefeuert.
    Wenn ich die Form nicht als MDIChild aufrufe - also mittels .showdialog - dann funktioniert das Event.
    Es liegt also an der MDI Geschichte, dass es nicht funkioniert.
    Hat hier jemand eine Lösung (oder sollte ich dafür mal einen separaten Thread eröffnen)?
    Edit: Der Upload des Programmes aus Post 222 ist noch aktuell.

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

    kann ich nicht nachvollziehen, bei mir (nutze ja auch Mdi) klappen die key-events.
    Allerdings auf den jeweiligen Childs. Wenn ich das richtig im Kopf hab, sollen die Events auf ein Control deiner frmMain reagieren oder?
    Dann würde ich vorschlagen, du registrierst das Control der frmMain bei Programmstart public, dann sollte das auch klappen
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Schon klar. Aber soll das Event nicht das Suchfeld steuern (welches sich nach meinem Wissen auf der Hauptform befindet)?
    Edit: Aah ganz vergessen. Me.KeyPreview = True beim Laden der Child - glaub' erst dann reagiert das ganze
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Nein. Das Event soll zur Eingabe von Zahlen dienen und es soll die Eingabe (wenn numerisch) in einem Label wiedergegeben werden.
    Aktuell ruft das Event aber nur eine messagebox auf, um zu testen, ob überhaupt was geht.

    VB.NET-Quellcode

    1. ​ Private Sub frmFinishOrder_Load(sender As Object, e As EventArgs) Handles MyBase.Load
    2. Me.KeyPreview = True
    3. [... ]

    ändert nix.

    VB.NET-Quellcode

    1. ​ Select Case True
    2. Case sender Is btnFinishOrder
    3. Me.KeyPreview = True
    4. FinishOrder()
    5. Case sender Is btnClearOrder : ClearOrder()
    6. End Select

    bringt auch nix.

    Wenn ich aber die Textbox, welche sich auf der besagten Form befindet anklicke, funktionieren beide KeyEvents.

Facebook
Telefonspende