[Erledigt] Object in StringGrid mit TFPGObjectList

[MacWomble]

Dann wäre DBGrid genau das richtige.

in der von dir geäußerten Kritik[...]

Ich will niemanden "kritisieren"...

Zur Aufklärung:
1. Das Projekt läuft bereits mit DB-Komponenten, aber das will ich nicht. Ich möchte das aus diversen Gründen mit Objekten realisieren und die Datenbank von den Formularen fern halten.
2. Mein Projekt arbeitet derzeit mit 78 Querys und Datasourcen, das ist nicht zumutbar und absolut unübersichtlich, obwohl diese in Datamodules ausgelagert sind.
3. Mein Projekt ist modular, aber ich muss immer die komplette DB liefern, auch wenn nur ein Teil des Programms geliefert wird (OK, das könnte ich beheben, liegt an den Datamodules - da ist einiges durcheinander)
4. Hast du nicht mich sondern meine Arbeit kritisiert, was ich grundsätzlich positiv auffasse. Insbesondere, wenn die Kritik so fundiert ist wie bei dir. Nur hierdurch kann ich lernen!

Deine Demo macht es genau so, wie ich mir das vorstelle !

[MacWomble]

+1 zu wp seinem Hinweis!!

PS: Ich würde statt P einen Bezeichner wie ArtikelPreis, AArtikelPreis oder LArtikelPreis wählen.

Beidem kann ich nur zustimmen - Danke !

@wp_xyz
Ich bin der überzeugten Meinung, dass dein Demoprojekt in die Beispielprogramme von Lazarus gehört. Absolut Klasse !

[MacWomble]

@wp_xyz
Ich benötige dies nicht, aber es ist mir eben aufgefallen:

Was passiert, wenn ich das Grid umsortieren lasse?
Damit stimmen doch dann die Inidzes nicht mehr mit der Preisliste überein. Oder darf man das einfach nicht tun?

[af0815]

Was passiert, wenn ich das Grid umsortieren lasse?

Wenn man umsortieren will (DBGrid), so ist das in der ziehenden Menge zu machen und das ist die SQL-Menge. Also die richtig sortiert abfragen und die Anzeige baut sich richtig auf.

Anders kann man nur die direkte Zuordnung von Dataset zur Anzeige auseinander brechen und sich selbst um alles kümmern.

[MacWomble]

Es geht zwar um TDrawGrid aber das ist egal.
Bei DBGrid geht es ohnehin, da dies das über die Datasource macht. Aber ich will keine DB-gebundenen Controls mehr verwenden, deswegen DrawGrid.
Wie ich schon schrieb, brauche ich es nicht (eben weil die Daten aus SQL-Abfragen kommen.)

Anders kann man nur die direkte Zuordnung von Dataset zur Anzeige auseinander brechen und sich selbst um alles kümmern.

Genau das mache ich gerade.

@af0815 Grüße aus Deuschlands Süden!
Wie du siehst, haben meine Bemühungen mit tiOPF keine Früchte getragen, weswegen ich mir das was ich brauche versuche selbst zu stricken.
Das ist bereits sehr weit gediehen (Dank dieses Forums) und macht - auch Aufgrund des Verstehens - unheimlich viel Spaß.

[wp_xyz]

Also deine Abneigung gegen datengebundene Controls kann ich nicht nachempfinden. So musst du mit DrawGrid das neu erfinden, was DBGrid schon kann. Und wenn du 78 Datasets verwendest und die alle irgendwie anzeigen willst, dann wirst du mit DrawGrid 78mal das Rad neu erfinden müssen. Wenn dir das eine Datamodule mit 78 Datasets und DataSources zu unübersichtlich ist: es ist nicht verboten, mehrere Datamodule zu verwenden, für jedes Formular oder jede logische Gruppe von Formularen ein eigenes ist keine Sünde, und du kannst auch die Query direkt mit auf's Formular setzen. Bloß weil irgendwo steht, dass man DataModule verwenden soll, sagt nicht, dass das die optimale Lösung für deine Fragestellung ist.

[MacWomble]

Das ist schon klar. Es gibt viele Gründe, warum ich dies ändern möchte:

Extrem wichtig
1. Modularität meiner Hauptapplikation
2. Wiederverwendbarkeit meiner Forms in neuen/anderen Projekten
3. Formularvarianten einfach austauschbar
4. Bessere Testmöglichkeiten
5. Unabhängigkeit von der Speicherart (DB, Text or whatever)
6. Online- und Offlinebetrieb
7. Flexibilität bei der Zusammenstellung unterschiedlicher Forms
Wichtig

Ich habe ja fast was ich brauche. Damit kann ich dann alles realisieren, was ich benötige und alle 'Teile' sind 'wiederverwertbar' (Nein bin kein Öko )
Das ist mir dieser einmalige Aufwand wert.

Ich entwickle seit etwa 30 Jahren Geschäftssoftware, aber die ganze Zeit muss ich mich mit den starren Vorgaben der DB-Controls abfinden.
Der Aufwand, eine Form in verschiedenen Variationen zu haben ist enorm und durch die Datenbindung ein Horror.
Glaube mir, ich weiss wo ich hin will und dass dies der richtige Weg ist - auch für mich, wenn ich es verstanden habe

[MacWomble]

@wp_xyz

Ich habe mein Programm nach deinem Demoprogramm umgestellt. Allerdings lese ich die Daten zunächst aus der Datenbank. Komischerweise erhalte ich eine Indexfehler in GetCellText, wenn ich nicht zuerst ein leeres Objekt erzeuge (Allerdings ist das dann logischerweise auch in der Liste und wird im Grid angezeigt):

Code: Alles auswählen

procedure TArtikelPreisListe.ReadListData(Query: string);
var
  TempObj: TArtikelPreis;
begin
  debugln('TArtikelPreisListe.ReadListData: ' + Query);
  with dtmBasis.qrySQL do
  begin
    try
      SQL.Text := Query;
      Open;
      debugln('  Gefunden: ' + IntToStr(RecordCount));
      if RecordCount > 0 then
      begin
        First;
 
        // Diese Procedur funktioniert nur, wenn ich ein leeres Objekt am Anfang erzeuge. 
        TempObj := TArtikelPreis.Create;
        Self.add(TempObj);
 
        while not EOF do
        begin
          TempObj := TArtikelPreis.Create;
 
          TempObj.ID := FieldByName('idartikelpreis').AsInteger;
          TempObj.IDArtikel := FieldByName('fk_artikel').AsInteger;
          TempObj.IDPreisgruppe := FieldByName('fk_preisgruppe').AsInteger;
          TempObj.Staffel := FieldByName('prs_staffel').AsString;
          TempObj.IDMengeneinheit := FieldByName('fk_mengeneinheit').AsInteger;
          TempObj.IDSteuersatz := FieldByName('fk_steuersatz').AsInteger;
          TempObj.Zeit := FieldByName('prs_zeit').AsFloat;
          TempObj.Lohn := FieldByName('prs_lohn').AsFloat;
          TempObj.Service := FieldByName('prs_service').AsFloat;
          TempObj.Material := FieldByName('prs_material').AsFloat;
          TempObj.Geraet := FieldByName('prs_geraet').AsFloat;
          TempObj.Fremdleistung := FieldByName('prs_fremdleistung').AsFloat;
          TempObj.VKNetto := FieldByName('prs_netto_vk').AsFloat;
          TempObj.VKBrutto := FieldByName('prs_brutto_vk').AsFloat;
          TempObj.BezPreisgruppe := FieldByName('p').AsString;
          TempObj.BezMengeneinheit := FieldByName('m').AsString;
          TempObj.BezSteuersatz := FieldByName('s').AsString;
 
          Self.add(TempObj);
 
          Next;
        end;
      end;
      Close;
    except
      On E: Exception do
        debugln(' ' + E.Message)
    end;
  end;
end;  

Hast du dazu eine Idee?

[wp_xyz]

Stimmt die Anzahl der Spalten? Wenn ich mich nicht verzählt habe, hat TempObj 17 Felder, also brauchst du 17 Spalten - oder 18, falls du auch die FixedCol angezeigt haben willst, am besten: DrawGrid.ColCount := 17 + DrawGrid.FixedCols. Die case-Anweisung, die den Zellen den Text zuweist, darf sich nur in diesem Indexbereich bewegen

Genauso mit den Zeilen - das ist die Listenanzahl + fixedRows: DrawGrid.RowCount := Count + DrawGrid.FixedRows.

[MacWomble]

-

[MacWomble]

Code: Alles auswählen

 
DrawGrid.RowCount := Count + DrawGrid.FixedRows  

Das war es Danke!

[af0815]

@af0815 Grüße aus Deuschlands Süden!
Wie du siehst, haben meine Bemühungen mit tiOPF keine Früchte getragen, weswegen ich mir das was ich brauche versuche selbst zu stricken.
Das ist bereits sehr weit gediehen (Dank dieses Forums) und macht - auch Aufgrund des Verstehens - unheimlich viel Spaß.

Das mit tiOPF glaube ich dir aufs Wort und kann es absolut verstehen.

Wenn du die Verbindung zwischen Datenmenge und der Anzeige aufbrichst, so ist das kein Beinbruch solange du den PK der Datenmenge mitführst. Ausserdem muss du dir merken, was wurde eingefügt, gelöscht oder geändert. Damit kannst du das wieder in die Datenmenge rollen, zu einem Zeitpunkt wo du es willst.

Das ist aber schon ein bischen von dem System auf dem die persistenten Systeme wie Mormot oder tiOPF basieren.

Übrigends würde ich mich auf Recordcount bei SQL-Datenmengen nicht verlassen. Ich verwende stattdessen Query.BOF und Query.EOF. Sind beide nicht zugleich da so sind Daten vorhanden, weil nur wenn BOF = Begin OF und EOF = End OF da sind, ist klar das die Menge 0 ist. Recordcount kann die nämlich auch nur anzeigen wieviele Datensätze wurden vom Server übertragen, das muss aber nicht mit der tatsächlichen Menge zu tun haben. Ist eine Eigenheit der SQL-Server Welt. Bei kleinen Datensetmengen fällt es nicht auf. Wenn die Ergebnismengen aber größer sind, so kann es sein das nur aktuell benötigte Fenster übertragen werden. ZB. nur die Menge die gerade im DBGrid angezeigt wird. Ist noch dazu sehr stark von den DB-Treibern und Servern abhängig. Kann amn aber bei machen Servern mit den entsprechenden Diagnosetools zum Beispiel mitsehen, was wirklich an Statements und Daten übertragen werden. Der MS-Sqlserver hat da sehr gute Tools dabei, wo man sowas sich ansehen kann. BTW. den gibt es auch für Linux, genaugenommen für Ubuntu 16.x. Läuft übrigends genauso wie der Windowspedant und es gibt auch eine kleine kostelose Version davon (zum Testen).

Ein echtes recordcount kannst du nur machen, wenn du ein count direkt am Server als SQL-Statement absetzt.

[sstvmaster]

Kurze Zwischenfrage, gilt das auch für SQLite?

Übrigends würde ich mich auf Recordcount bei SQL-Datenmengen nicht verlassen. Ich verwende stattdessen Query.BOF und Query.EOF. Sind beide nicht zugleich da so sind Daten vorhanden, weil nur wenn BOF = Begin OF und EOF = End OF da sind, ist klar das die Menge 0 ist. Recordcount kann die nämlich auch nur anzeigen wieviele Datensätze wurden vom Server übertragen, das muss aber nicht mit der tatsächlichen Menge zu tun haben. Ist eine Eigenheit der SQL-Server Welt. Bei kleinen Datensetmengen fällt es nicht auf. Wenn die Ergebnismengen aber größer sind, so kann es sein das nur aktuell benötigte Fenster übertragen werden. ZB. nur die Menge die gerade im DBGrid angezeigt wird. Ist noch dazu sehr stark von den DB-Treibern und Servern abhängig. Kann amn aber bei machen Servern mit den entsprechenden Diagnosetools zum Beispiel mitsehen, was wirklich an Statements und Daten übertragen werden. Der MS-Sqlserver hat da sehr gute Tools dabei, wo man sowas sich ansehen kann. BTW. den gibt es auch für Linux, genaugenommen für Ubuntu 16.x. Läuft übrigends genauso wie der Windowspedant und es gibt auch eine kleine kostelose Version davon (zum Testen).

Ein echtes recordcount kannst du nur machen, wenn du ein count direkt am Server als SQL-Statement absetzt.

[af0815]

Kurze Zwischenfrage, gilt das auch für SQLite?

Übrigends würde ich mich auf Recordcount bei SQL-Datenmengen nicht verlassen.

Ganz einfach: Gehe nicht davon aus, das es dir bei SQL-Servern garantiert wird. Genaugenommen ist das ein Relikt aus den Desktopdatenbanken. Garantiert wird es dir nur dann wenn es entsprechend Dokumentiert ist

Umgekehrt Frage, wozu brauchst du die Information ?! Wenn ich mit Mengen arbeite, so ist es mir relativ egal, den Sonderfall ob die Menge leer ist kann ich mit BOF/EOF bestimmen. Das einzige was ich überlegen muss, ist ob meine WHERE Klausel richtig ist.

[MacWomble]

Das ist aber schon ein bischen von dem System auf dem die persistenten Systeme wie Mormot oder tiOPF basieren.

Dessen bin ich mir bewusst. Aber der Weg den ich nun gehe, setzt voraus, dass ich auch alles verstanden habe. Ich bräuchte von tiOPF ohnehin nur einen Bruchteil, warum soll ich mich dann mit dem ganzen Framework herumschlagen. Und die notwendige Lernkurve von tiOPF kennst du ja auch.
Mit Mormot habe ich mich nicht so intensiv befasst, da ich die Entscheidung zum Selbermachen bereits gefällt hatte. Teilweise ist dies aber auch den bereits vorhandenen Datenbanken geschuldet, welche ich nicht unbedingt auf ein Framework anpassen wollte. Außerdem gehe ich teilweise auch etwas andere Wege bei der DB-Programmierung. So gibt es bei mir keine fest verknüpften Tabellen, alles kann dynamisch kombiniert werden, so wie es eben für die Anwendung gebraucht wird.
Hintergrund: Software, welche dem Anwender vorgibt wie er zu arbeiten habe gibt es genug am Markt

Ich benötige ja nicht wirklich viel. Neben der Trennung von Formularen und Datenverarbeitung sind dies nur:

- Anzeigen von Grids (jetzt TDrawGrid)
- TEdit, TCombobox und einen Kalender
- Lesen und Schreiben der Daten wohin auch immer
- Reportdesigner
- Testmöglichkeiten
- Flexibilität bei den Formularen (Kundenanpassungen)
- leichte Anpassbarkeit der Datenbanken

Damit ist eigentlich alles abzudecken, was ich für meine Applikationen benötige. Bis auf ein paar Feinheiten ist das so weit auch schon realisiert, der Rest ist dann Fleißarbeit, d.h. Form für Form an die neue Technik anpassen und die Datenklassen schreiben. Dank dem Demoprogramm von wp_xyz ist letzteres aber auch deutlich einfacher bzw weniger aufwändig, als ich es begonnen habe.