Textdatei auswählen, einlesen und in mehreren Ausgabe Boxen zur Bearbeitung zeigen

  • VB.NET

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

    Textdatei auswählen, einlesen und in mehreren Ausgabe Boxen zur Bearbeitung zeigen

    Hallo Ihr VB Profis,

    habe da eine Programmieraufgabe bekommen und brauche Unterstützung.
    Die Aufgabe:
    Ein Benutzer soll über OpenFileDialog in einem vorgegebenen Verzeichnis eine Textdatei auswählen können.
    (Ist bereits erledigt und funktioniert!)
    Die Datei hat folgende Striktur

    Kopfzeile (T1;T2;T3;T4;T5;T6;T7... CRLF)
    Positionszeile(n) (T1;T2;T3;T4;T5;T6;T7... CRLF)

    (optional)
    Kopfzeile2
    Positionszeile(N)
    .
    .
    ,

    Jetzt wird es schwierig. Die Kopfzeile(n) können (sollen) in einem Ausgabefeld (ich dachte an ein Listview oder DataGrid) zum weiteren Test dargestellt werden.
    Die Positionszeile(n) sollen pro Kopfzeile in ein eigenes Ausgabefeld ausgeben werden. Die einzelnen Felder der Zeile werden durch ein Semikolon getrennt und die Zeile durch ein CRLF beendet.
    Die einzelnen Felder müssen nachher durch einen Butten auf bestimmte Eigenschaften überprüft werden.
    Meine Fragen: Wie verteilt ich die Zeilen den Textdatei auf die verschiedenen Ausgabefelder. Welches Ausgabefeld eignet sich am besten für die anschließenden Prüfungen. (Fehler sollen in den Ausgabefelder markiert werden mittels anderer Textfarbe oder farblich unterlegt)

    Wäre schön, wenn mir jemand einen Tipp für mein weiteres Vorgehen geben kann oder einen Link auf eine Seite senden kann wo ein ähnliches Problem behandelt wird.

    Vielen Dank

    *Topic verschoben*
    Bilder
    • Programm.JPG

      116,42 kB, 1.109×636, 15 mal angesehen

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

    Willkommen in Forum.
    Kein ListView, nimm das DGV. Teile Deinen Dateitext in Zeilen einmal mittels IO.File.ReadAllLines(DeinDateiPfad) in einzelne Zeilen und teile dann jede Zeile mittels Zeile.Split(";"c) in die Datenbestandteile. Dann ins DGV damit.Schau erstmal, wie weit das funktioniert.

    Advanced: Statt direkt in ein DGV könnte es auch in eine vorbereitete DataTable, die dann an das DGV gebunden wird. Ist flexibler. Aber wer weiß schon, wie sehr das alles ausarten soll.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.
    Erstmal Vielen Dank für deine Antwort VaporiZed!
    ​Was mich aber brennend interessiert ist wie sieht die der Code aus, mit dem ich beim Einlesen entscheide in welches DGV die Zeile eingelesen wird. Wie bereits geschrieben gibt es ein DGV für die Kopfzeilen und jeweils eins für die Positionszeilen je Kopf. Wie hier die Abfrage aus, und wie stelle ich den Gruppenwechsel bei den Positionen fest. Soweit ich das verstehe, werden mit IO.File.ReadAllLines alle Zeilen eingelesen.
    ​Da ich kein Profi in Sachen Programmieren bin, kannst Du gerne korrigieren wenn ich hier falsch liege.
    ​Es wäre schön wenn Du mir hier weiterhelfen könntest.

    Viele Grüße

    RaHe schrieb:

    Wäre schön, wenn mir jemand einen Tipp für mein weiteres Vorgehen geben kann
    done

    RaHe schrieb:

    wie sieht die der Code aus, mit dem ich beim Einlesen entscheide in welches DGV die Zeile eingelesen wird
    Wieviele DGVs gibt's denn? Lies die Daten aus dem Array, welches Dir ReadAllLines gibt, bis zur 1. Leerzeile aus. aufgrund Deines Beispiels gehe ich davon aus, dass dort die Trennung zwischen den Datenblöcken ist. Aber wieviele Datenblöcke Du hast und somit DGVs brauchst, musst Du selber wissen. Der Switch in das nächste DGV erfolgt dann eben bei der Datenblockgrenze.

    öhm ... Moment mal. Sicher, dass die Kopfzeile in ein DGV soll und die Positionszeilen in ein anderes DGV? Ich weiß ja nicht, was da rauskommen soll, aber mir erscheint es logischer, wenn die Kopfzeilen in die Spalten-Header des DGVs kommen und die Positionszeilen in die eigentlichen Tabellenzellen des selben DGVs. Mach mal ein Bild von Rohdaten und Soll-Endausgabe.

    RaHe schrieb:

    Gruppenwechsel bei den Positionen
    Was denn für ein Gruppenwechsel? Davon war bisher nicht die Rede.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.
    Hallo VaporiZed,

    ​um das alles verständlicher zu machen, sollte ich vielleicht näher auf die Textdatei, die eingelesen wird, eingehen.
    ​Die Textdatei ist ein Elektronischer Lieferschein. Die Kopfzeilen enthalten keine Spaltenüberschriften. Die Spaltenüberschriften und die Formate, auch die Art des Inhalts kommen aus eine separaten Datensatzbeschreibung, die vorgibt was wie und mit welchem Inhalt in der Datei steht.
    ​Zu der Anzahl der DGV: Es gibt zwingend eines für den/die Kopfzeile, dann entsprechend der Anzahl der Kopfzeile je ein DGV für die Positionszeilen. Es gibt auch verschiedene Arten von Positionszeilen. An Hand eines Identifier wird festgelegt ob es eine "normale" Artikelzeile oder ob es sich um Zusatzinformationen für einen Artikel handelt. Wenn die DGVs gefüllt sind muss der Inhalt überprüft werden, ob er mit den Vorgaben in der Datensatzbeschreibung übereinstimmt oder nicht. Wenn nicht, muss Zelle hervorgehoben werden! Der Inhalt in einer anderen Farbe dargestellt oder die Hintergrundfarbe geändert werden. Um die verschiedenen Arten der Positionszeilen zu unterscheiden hatte ich an ein weiteres DVG gedacht (das war mit dem Gruppenwechsel gemeint) aber wieder verworfen. Zu unübersichtlich.
    ​Mit dieser Beschreibung kannst Du vielleicht besser verstehen was ich vorhabe.

    ​Viele Grüße

    RaHe schrieb:

    um das alles verständlicher zu machen

    VaporiZed schrieb:

    Mach mal ein Bild von Rohdaten und Soll-Endausgabe.
    Natürlich auch pseudonymisiert, ist ja schließlich wurscht, in welcher Branche Du Dich aufhältst. Nur: Ein Wort sagt mehr als 1000 Bilder. Oder so ähnlich. Beschreibungen sind eines. Vorher-nachher-Bilder zeigen meist viel besser, was Erklärungen nicht hinbekommen. Denn der Unwissende (also in dem Fall ich) hat bei Beschreibungen zweifellos andere Vorstellungen als Du. Und dann sind Erklärungen oder Codebeispiele meinerseits eh nix wert.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    Neu



    Hallo,
    leider war ich in den letzten Tagen beruflich stark
    eingebunden und kann mich erst heute wieder melden. Wie gewünscht habe ich zur
    besseren Übersicht einmal Demodaten und einen Screenshot (wie das Programm
    aussehen soll) besorgt.
    Hier ein Beispiel für eine Lieferschein Datei:

    HEAD;123456789;14879;01.08.2018;14.08.2018
    123456789;1;1234567890123;20;Erdkabel NYY-J mit Schutzleiter ;29,58;35,5;25;30;1791;ART
    123456789;1;;;Anzahl Adern 3;;;;;1791;SpeDat
    123456789;1;;;Ausfhrung3 x 1,5;;;;;;SpeDat
    123456789;2;1600001307862;21;Lapp PVC-Mantelleitung NYM;65,3;75,5;15;15;1791;ART
    123456789;2;;;Ausfhrung-J 4 G 1,5, auáen 9,2 mm, 100 m;;;;;;SpeDat
    HEAD;123456790;QPZV;01.10.2018;14.10.2018
    123456790;1;3589741235897;35;Busch-Jaeger Reflex SI alpinweiá ;AVFRS;3,25;100;100;1791;ART
    123456790;1;;;Ausfhrung: Einfach m. Beschr.;;;;;;SpeDat
    123456790;2;2589713698412;37;Busch-Jaeger Eins„tze fr Unterputz;8,75;9,25;100;100;1791;ART
    123456790;2;;;Ausfhrung: Aus- u. Wechselschaltung;;;;;;DASiDaw

    Die Datei enthält 2 Lieferscheine. Im ersten Lieferschein gibt es 2 Artikel Positionen. Der erste Artikel hat 2 der zweite Artikel 1
    Position mit Spezialdaten. Im zweiten Lieferschein gibt es 2 Artikelpositionen mit jeweils einer Position mit Spezialdaten.
    Im Screenshot wird das Programm gezeigt, wie es aussehen könnte. Im Karteireiter Select kann der Anwender mit einigen Auswahlkriterien
    über ein OpenFileDialog Fenster eine Lieferscheindatei auswählen. Diese wird im Karteireiter File Proof in DGVs dargestellt. (eine Lieferscheindatei mit zwei
    Lieferscheinen bedeutet: 3 DGVs. Eins für die Lieferscheinköpfe und jeweils eins für die Lieferschein Positionen) Über einen Proof Button werden die
    Inhalte der DGVs auf Richtigkeit überprüft. Fehler werden angezeigt, indem sich die Hintergrundfarbe ändert. Die Fehler müssen noch dokumentiert und in
    Papierform ausgegeben werden. Allerdings weiß ich noch nicht wie ich das lösen soll. Wenn Dir zum Design für die Ausgabe noch eine Idee kommt, bin immer für
    Anregungen offen.

    Viele Grüße

    Neu

    Imo benötigt man erstmal ein typisiertes Datenmodell, wo man die Dateien einlesen kann.
    An das Datenmodell kann man dann Datagridviews binden, zur Anzeige und Bearbeitung der Daten.
    Evtl. kann man auch son NestedDatagrid dran binden, aber das dürfte kompliziert werden, denn im Framework ist ein solches nicht vorhanden.

    Wiedemauchsei: Der versprochene Screenshot könnte vlt. helfen, klarer zu sehen, was eiglich gewünscht ist.

    Neu

    Hallo Dksksmm,

    wie binde ich denn ein Bild hier? Habe keine Anleitung gefunden, nur den Button Bild. Wenn ich hier den Datenpfad zum Screenshot eintrage passiert nichts.
    Bitte um kurz Anleitung. DANKE.

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

    Neu

    Hallo,
    habe das Menü gefunden und den Screen Shot hochgeladen. Leider ist der jetzt im ersten Eintrag gelandet. Also so könnte das Programm aussehen. Im Karteireiter File Proof werden die Köpfe und die Positionen dargestellt. Durch drücken des Proof Button werden die Einträge auf Richtigkeit überprüft und Fehler durch Änderung des Zellhintergrundes markiert. (Das ist der Zustand des Screen Shots) Wenn jemand eine bessere Idee zur Übersichtlichen Darstellung hat, nur zu! Im Design habe ich keine Vorgaben zu berücksichtigen. Nur im Ablauf bin ich gebunden.

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

    Neu

    Danke.

    Also das gezeigte Design ist eher unschön zu programmieren, und hat v.a. usertechnische Nachteile:
    Wenn nämlich eine Datei mal 10 Lieferscheine enthält wird der Platz für die 11 DGVs auffm Bildschirm nicht mehr ausreichen.

    Es gibt eine höchst elegante Lösung, mit einem Design, was mit nur 2 DGVs auskommt - der "Parent-Child-View".
    Das obere Dgv bleibt dasselbe, und statt der beiden unteren gibt es nur eines - und das zeigt jeweils die Artikel an, deren Lieferschein im oberen angewählt ist.

    Habich Tutorials mit Video zu gemacht: vier Views-Videos
    Such darin nach Parent-Child.

    Wie in post#9 bereits angemerkt: Die Sache steht und fällt mit dem Datenmodell.
    Welches in diesem Falle am besten als typisiertes Dataset ausgeführt wird.
    Das wird inne Vids auch kurz am Anfang gezeigt - probierma, ob du damit ein brauchbares TypDataset hinbekommst - wenn fertig, poste Screenshot dazu.

    Dassis erstmal das wichtigste: ein brauchbares tDS.
    Den Code, mit dem man es befüllt aus deiner Textdatei, kann man erst schreiben, wenn das tDS da ist.

    Neu

    Du beschreibst genau das selbe was ich schon in Post #8 schrieb.
    Allerdings sagte ich nichts vom Datenmodel / typisiertem Dataset gesagt, weil für mich ist das so fest gesetzt, dass ich es schon gar nicht mehr erwähne.
    Wenn es mehrplatzfähig werden soll würde ich aber doch eher gleich auf Datenbank und ORM gehen.

    Neu

    Hallo,
    ihr hab mir geschrieben, das ich ein typisiertes Dataset erstellen soll. Das ist professionell, logisch und wahrscheinlich sehr nützlich, stellt mich aber vor eine Dilemma. Es gibt da nämlich zwei Möglichkeiten.
    1. ​Die Dateibeschreibung
    Es gibt eine Datei mit mindestens einem oder mehreren Lieferscheinen
    Jeder Lieferschein enthält eine Kopfzeile und mindesten eine oder mehrere Positionszeilen
    ​ Die Positionszeilen können verschiedener Art sein

    ​ 2. Die Inhaltsbeschreibung
    Hier kommen die verschiedenen Arten der Positionen zum tragen.
    ​ (Die Anzahl der Kategorien würde sich hier vervielfachen)
    Ein Beispiel von 5 anderen möglichen Kategorien:
    ​ Ein Artikel ist einer Artikelgruppe zugeordnet (eine Artikelgruppe kann mehrere Artikel enthalten)
    Der Artikel kann eigene Spezialdaten (Positionen) haben oder auf Grund seiner Zuordnung zu einer Artikelgruppe Spezialdaten (falls solche existieren) zugeordnet bekommen.
    Die Information ob der Artikel wirklich zu der Artikelgruppe gehört oder die Artikelgruppe Spezialdaten besitzt kann ich auf Grund fehlender Informationen hier gar nicht überprüfen!

    ​Dies soll kein Einlese Programm für eine Warenwirtschaft werden. Ich soll nur überprüfen ob die Datei formal mit der vorhanden Schrittstellenbeschreibung übereinstimmt (Anzahl der vorhandenen Felder je nach Zeilenart) und ob die einzelnen Felder in Art; Länge; Format richtig sind. Außerdem ob beim Export eine Zeile "verrutscht" ist. Wenn die Zeile bspw. bis zur Hälfte richtig ist, der Rest der Zeile aber irgendwo in der nächsten Zeile fortgesetzt wird. Dann ist für das Einlese Programm ein zeilenweises Einlesen nicht mehr möglich!

    ​WIe soll ich hier vorgehen? Wie bekomme ich die verschiedenen Arten der Positionszeile abgebildet? Mir ist die Möglichkeit in den Sinn gekommen für die Struktur des Dataset eine Access DB einzubinden. Die einzelnen Tables bilden dann die Struktur der jeweiligen Zeilenart ab.
    Wäre das möglich?

    ​Viele Grüße

    Neu

    Verbessert mich gern, aber wenn es "nur" um ein Prüfprogramm geht, also Du die Dateistruktur checkst und und die inhaltlichen Daten überhaupt nicht weiter verarbeitest, dann brauchst Du kein tDS oder ne Datenbank. "Ein Wort sagt mehr als tausend Bilder.": Kannst Du mal ein paar Pseudodaten angeben, die vorliegen und daran festmachen, was Du wie haben willst?
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    Neu

    RaHe schrieb:

    für die Struktur des Dataset eine Access DB einzubinden.
    Was soll das bringen?
    Ich wüsste nicht, was Access in diesem Falle leisten könnte, was ein typDataset nicht kann.

    Und wenn Artikel-Verwaltung garnet der Sinn der Anwendung ist, sondern die Syntax-Überprüfung von Dateien, dann musste eben diese Syntax modellieren - was allerdings schwieriger ist, weil recht abstrakt.