Hat Jemand eine Ahnung wie ich diese Datei in ein Stringgrid bekomme.

[p80286]

Vielleicht wäre es ganz hilfreich, erst einmal zu wissen welche Dateiformate für die Eingabe vorliegen.
Der nächste Schritt wäre, ein für die weitere Verarbeitung geeignetes Format zu definieren, in das alle Deine Eingaben überführt werden.
Da in der Beispieldatei etwas mehr als 2600 Einträge sind und es wohl mehrere EingabeDateien gibt, könnte man u.U an eine DB denken auch wenn das bei einer so einfachen Datenstruktur nach Overkill aussieht. Allerdings ist die Suche nach einem Wertepaar, dann relativ einfach zu lösen.
Also mach Dir erst einmal ein paar Gedanken zu Deinem Konzept.

Gruß
k-H

[Delphi.Narium]

Meiner Meinung nach kann man sowas nur sinnvoll und performant machen, wenn man eine "datenbankähnliche" Struktur nimmt.

Also entweder man packt die Dateien in eine Datenbank (wenn auch nur für die Zeit der Verarbeitung) oder nutzt direkt Komponenten, die mit dem Dateiformat umgehen können.

ClientDataSet, die ADO-Komponenten, bei älteren Delphis (wie's im Profil steht Delphi 6) gerne auch noch die BDE. Dort kann man auch Strukturdateien definieren, die den Aufbau von Textdateien enthalten. Mit der Kombination Textdatei und Strukturdatei kann man dann auf die Textdateien wie auf Datenbanktabellen zugreifen.

Man kann damit dann auch mit einfachem SQL auf Textdateien zugreifen.

So eine Strukturdatei kann so aussehen (Beispiel für eine alte Bankleitzahlendatei):

Code:

[BLZ0509PC]
FILETYPE = FIXED
CHARSET = china
DELIMITER = 
SEPARATOR = 
Field1  = BANKLEITZAHL,      CHAR,  8,0,  0
Field2  = EIGENEBANKLEITZAHL,CHAR,  1,0,  8
Field3  = LOESCHBANKLEITZAHL,CHAR,  8,0,  9
Field4  = LBZGIROKONTO,      CHAR,  1,0, 17
Field5  = LOESCHDATUM,       CHAR,  4,0, 18
Field6  = NACHFOLGEINSTITUT, CHAR,  5,0, 22
Field7  = NAMEKURZ,          CHAR, 58,0, 27
Field8  = KURZBEZEICHNUNG,   CHAR, 20,0, 85
Field9  = POSTLEITZAHL,      CHAR,  5,0,105
FIELD10 = ORT,               CHAR, 29,0,110
FIELD11 = BTX_EZU,           CHAR, 27,0,139
FIELD12 = PAN,               CHAR,  5,0,166
FIELD13 = VEROEFFENTLICHT,   CHAR,  1,0,171
FIELD14 = BIC,               CHAR,  9,0,172
FIELD15 = KENNZIFFER,        CHAR,  2,0,181
FIELD16 = LFDNR,             CHAR,  5,0,183

Im Programm könnte man hiermit dann z. B. per FieldByName('FIELD10').AsString auf den Ort zugreifen.

Aber 'ne eigene Schnittstelle für DBase-Dateien programmieren, würd' ich jetzt nicht unbedingt empfehlen. Wenn aber unbedingt doch, dann hier eine passende Beschreibung dessen, was man dann so vor sich hat: Data File Header Structure for the dBASE Version 7 Table File

[KodeZwerg]

[EDIT]
Diesen Code nicht benutzen da er anscheinend schlecht ist. Tut mir leid.
[/EDIT]

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, 
  Dialogs, DBTables, Db;

const
  WM_OPENDATASET = WM_USER + 1;
  WM_EXECUTESQL  = WM_USER + 2;

type
  TThreadDataSet = class(TThread)
  private
    procedure WMOpenDataSet(Msg: TMsg);
    procedure WMExecSQL(Msg: TMsg);
  protected
    procedure Execute; override;
  public
    procedure Open(DataSet: TDataSet);
    procedure ExecSQL(DataSet: TDataSet);
  end;

  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    FThread : TThreadDataSet;
  public
  end;

var
  Form1: TForm1;

implementation

{$R *.DFM}

procedure TThreadDataSet.ExecSQL(DataSet: TDataSet);
begin
  PostThreadMessage(ThreadID, WM_EXECUTESQL, Integer(DataSet), 0);
end;

procedure TThreadDataSet.Execute;
var
  Msg : TMsg;

begin
  FreeOnTerminate := True;
  PeekMessage(Msg, 0, WM_USER, WM_USER, PM_NOREMOVE);

  while not Terminated do begin
    if GetMessage(Msg, 0, 0, 0) then
       case Msg.Message of
         WM_OPENDATASET: WMOpenDataSet(Msg);
         WM_EXECUTESQL:  WMExecSQL(Msg);
       end;
  end;
end;

procedure TThreadDataSet.Open(DataSet: TDataSet);
begin
  PostThreadMessage(ThreadID, WM_OPENDATASET, Integer(DataSet), 0);
end;

procedure TThreadDataSet.WMExecSQL(Msg: TMsg);
var
  Qry : TQuery;

begin
  try
    Qry := TQuery(Msg.wParam);
    try
      Qry.Open;
    except
      Qry.ExecSQL;
    end;
  except
    On E: Exception do
       ShowMessage(E.Message);
  end;
end;

procedure TThreadDataSet.WMOpenDataSet(Msg: TMsg);
var
  Ds : TDataSet;

begin
  try
    Ds := TDataSet(Msg.wParam);
    Ds.Open;
  except
    On E: Exception do
       ShowMessage(E.Message);
  end;
end;

// MAIN PART

procedure TForm1.FormCreate(Sender: TObject);
begin
  FThread  := TThreadDataSet.Create(False);
  FThread.Open(Table1);   // Öffne ein DataSet (table oder query)
  FThread.ExecSQL(Query1);  // Execute die SQL
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  FThread.Terminate;
end;

end.

So könnte die ClientDataSet-Variante umgesetzt werden, in diesem Beispiel-Code gleich Threaded.
Um damit Sinnvoll umzugehen die Hilfe-Datei lesen.

[juergen]

Hallo,

Zitat von KodeZwerg:

[DELPHI]
So könnte die ClientDataSet-Variante umgesetzt werden...

ein ClientDataSet sehe ich in deinem Code aber nicht

[KodeZwerg]

Zitat von KodeZwerg:

FThread.Open(Table1); = Table1 = Control Komponente die man sich selbst konfigurieren muss
siehe:
Um damit Sinnvoll umzugehen die Hilfe-Datei lesen.

PS: Abschnitt ClientDataSet, um zu lernen wie man's Einrichtet, sprich: das was Du bemängelst was fehlt.
Dieser Code zeigt wie man es per Thread steuern könnte.
Das ist nur ein skelett auf das minimum reduziert nur um zu zeigen wie's per Thread gehen könnte, ich hatte an Performance gedacht, jeglicher Code der Table1 oder Query1 enthält ist bewusst entfernt da es aus meinem DataSet-Sample entspringt.

[haentschman]

Moin...

Zitat:

auf das minimum reduziert nur um zu zeigen wie's per Thread gehen könnte

In Anbetracht des Codes aus #3, ohne try finally, glaube ich nicht, das der TE damit was anfangen kann...mit Kanonen auf Spatzen geschossen!

Zitat:

kann ich direkt ins Stringgrid laden

Das erste Problem ist die Datenhaltung von der Visualisierung trennen! Über die Ausgabe der Darstellung kann man später reden.

[Fritzew]

Zitat:

Das erste Problem ist die Datenhaltung von der Visualisierung trennen! Über die Ausgabe Darstellung kann man später reden.

Da hast Du zu 100% recht!

Dann kommt noch dazu das der Code für die Threadnutzung vor Fehlern nur so wimmelt.
FreeOnTerminate true und
freigeben im Form Destroy. ---- >Aua

Davon Ausgehen dass der Thread schon Messages entgegen nehmen kann, ohne jede Synchronisierung . ---- Aua

Was ich damit meine:

Delphi-Quellcode:

FThread := TThreadDataSet.Create(False);
  FThread.Open(Table1); // Öffne ein DataSet (table oder query)

Es ist nicht! Sichergestellt das der Thread schon läuft, weshalb das PostThreadMessage im Open fehl schlagen kann.
Keinerlei Überprüfung der Rückgabe.
Beim beenden keine Synchronisierung

Das ist einfach nur Code den man so nicht zeigen sollte.
Und vor allem es geht komplett am Ursprungsthema vorbei!

[himitsu]

Zitat von KodeZwerg:

Dieser Code zeigt wie man es per Thread steuern könnte.
Das ist nur ein skelett auf das minimum reduziert nur um zu zeigen wie's per Thread gehen könnte,

Das DataSet hängt überlicher Weise an der GUI und da ist nichts threadsave.

Und warum macht Execute ein Open?

[KodeZwerg]

In einem meiner alten Delphi 7 Anwendungen hab ich die Class so in Benutzung, funktioniert tadellos, FormCreate/FormDestroy sollte lediglich zeigen wie man auf den Thread zugreifen könnte, hab's nun mit Warnung versehen und bin still.