[Erledigt] Object in StringGrid mit TFPGObjectList

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
MacWomble
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: Object in StringGrid mit TFPGObjectList

Beitrag von MacWomble »

wp_xyz hat geschrieben:Dann wäre DBGrid genau das richtige.
MacWomble hat geschrieben: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 !
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

MacWomble
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: Object in StringGrid mit TFPGObjectList

Beitrag von MacWomble »

Michl hat geschrieben:+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 ! :idea: :!:
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

MacWomble
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: Object in StringGrid mit TFPGObjectList

Beitrag von 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?
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Object in StringGrid mit TFPGObjectList

Beitrag von af0815 »

MacWomble hat geschrieben: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.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

MacWomble
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: Object in StringGrid mit TFPGObjectList

Beitrag von 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ß.
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: [Erledigt] Object in StringGrid mit TFPGObjectList

Beitrag von 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
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: [Erledigt] Object in StringGrid mit TFPGObjectList

Beitrag von 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 :D )
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 :twisted:
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

MacWomble
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: [Erledigt] Object in StringGrid mit TFPGObjectList

Beitrag von 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?
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: Object in StringGrid mit TFPGObjectList

Beitrag von 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
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: Object in StringGrid mit TFPGObjectList

Beitrag von MacWomble »

-
Zuletzt geändert von MacWomble am Do 17. Jan 2019, 20:48, insgesamt 1-mal geändert.
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

MacWomble
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: Object in StringGrid mit TFPGObjectList

Beitrag von MacWomble »

Code: Alles auswählen

 
DrawGrid.RowCount := Count + DrawGrid.FixedRows 


Das war es :D Danke!
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Object in StringGrid mit TFPGObjectList

Beitrag von af0815 »

MacWomble hat geschrieben:@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. :mrgreen:

Ü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.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

sstvmaster
Beiträge: 575
Registriert: Sa 22. Okt 2016, 23:12
OS, Lazarus, FPC: W10, L 2.2.6
CPU-Target: 32+64bit
Wohnort: Dresden

Re: Object in StringGrid mit TFPGObjectList

Beitrag von sstvmaster »

Kurze Zwischenfrage, gilt das auch für SQLite?
af0815 hat geschrieben:Ü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.
LG Maik

Windows 10,
- Lazarus 2.2.6 (stable) + fpc 3.2.2 (stable)
- Lazarus 2.2.7 (fixes) + fpc 3.3.1 (main/trunk)

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Object in StringGrid mit TFPGObjectList

Beitrag von af0815 »

sstvmaster hat geschrieben:Kurze Zwischenfrage, gilt das auch für SQLite?
af0815 hat geschrieben:Ü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.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

MacWomble
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: Object in StringGrid mit TFPGObjectList

Beitrag von MacWomble »

af0815 hat geschrieben:Das ist aber schon ein bischen von dem System auf dem die persistenten Systeme wie Mormot oder tiOPF basieren. :mrgreen:

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 :twisted:

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.
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

Antworten