Fehler im DBGrid, Hilfe bei der Verifizierung benötigt.

[Michael Habbe]

Hallo Leute, Admin,

ich weiss, das dieses Crossposting nicht sehr gewünscht ist, aber ich um Beachtung des Beitrages: http://www.delphipraxis.net/internal...t.php?t=144690

Da es vielleicht viele DB-Entwickler betrifft, bitte einmal schauen und prüfen.


@admin
Dieser Beitrag kann meinetwegen geschlossen werden oder später auch gelöscht.


Danke schön


Michael

[ConstantGardener]

Hallo Michael,

das hört sich an wie dieses Problem http://www.delphipraxis.net/internal...nstantgardener

mfg

ConstantGardener

[Michael Habbe]

Hi,

schönen Dank für den Hinweis.
Da habe ich die Suche mit "DBGrid" verwendet und diesen Thread übersehen. :gruebel:

Habe es mal ausprobiert, wie Du es beschrieben hast. Aber ein CheckBrowseMode postet den Datensatz, welches ich nicht nicht gebrauchen kann.

Werde aber mal einen Vergleich der Sourcen von D7 und TD starten.


Michael

[Michael Habbe]

Ich habe mir jetzt mal die Quellen von D7 und TD vorgenommen.
Die Unterschiede sind nicht sehr groß. Zumindest was die dbgrids.pas angeht. Ob aber hier tatsächlich der Fehler liegt, das liegt ausserhalb meiner Zeit, dieses zu ermitteln.


So habe ich mir einen Workaround ausgeheckt.

Zuerst bin ich auf die neue Property OnMouseActivate gestossen, womit man das Setzen des Fokus eines Steuerelements unterbinden kann.
Z. B. in dieser Form:

Delphi-Quellcode:

procedure TForm1.DBGrid1MouseActivate(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y, HitTest: Integer;
  var MouseActivate: TMouseActivate);
begin
  if Table1.State in [dsEdit, dsInsert] then
    if HitTest = HTCLIENT then
      MouseActivate := maNoActivateAndEat;
end;

Dies ist aber sehr restriktiv, da man auch nicht mehr zu einem anderen Datensatz springen kann. Ich stellte mir schon das Telefon vor, wie es heissklingelt, weil die Kunden nicht mehr wie gewohnt ins Grid klicken können...
Eigentlich wollte ich aber nur verhindern, dass man nicht mehr darunter klicken kann. Das wird aber leider nicht unterschieden, ob man auf einen DS oder den Freiraum klickt.


Bin dann letzten Endes doch zu der Überlegung gekommen, dass es vielleicht doch am sinnvollsten ist, den Datensatz zu speichern, wenn das Grid angeklickt wird.

Delphi-Quellcode:

procedure TForm1.DBGrid1Enter(Sender: TObject);
begin
  if Table1.State in [dsEdit, dsInsert] then
    Table1.Post;
end;
procedure TForm1.Table1AfterEdit(DataSet: TDataSet);
begin
  DBEdit1.SetFocus;
end;

Das TableAfterEdit ist wichtig, da GridEnter ja nur ausgelöst wird, wenn man auch wirklich das Grid betritt.


Das ist meines Erachtens nicht die schönste Lösung, aber immer noch besser wie verlorene Daten.


Mal gucken, was Borland so als nächstes auf Lager bereithält. Hatte schon überlegt, auf Delphi 2009 upzugraden, ich glaube, damit warte ich noch ein wenig.



Gruß
Michael

[alzaimar]

Ich würde Dir empfehlen, ein anderes Grid zu verwenden, das auch hinsichtlich seiner Grundfunktionalität wesentlich mehr kann, als das doch sehr generische TDBGrid. Ich meine z.B. Filtern, Sortieren, Spalten verschieben, ein- und ausblenden, Zeilen unterschiedlich einfärben, in Excel exportieren, mehrzeilige Anzeige eines Datensatzes, Checkboxen als Boolean-Spalten usw.

Wenn Du GUI-lastige Anwendungen schreibst, würde ich auch an eine alternative Sammlung von Eingabefeldern verwenden, die dem Kunden die Arbeit erleichtern.

Ich habe mich vor etlichen Jahren mit den Komponenten von Developer Express angefreundet, sehr viel Geld ausgegegeben, und dieses Geld nach 14 Tagen wieder eingespielt, weil ich eine 'kleine' Anwendung damit erstellt und es einem Kunden vorgeführt habe. Der hat es sofort gekauft. Aber auch so hat sich die Sammlung schnell rentiert, weil einfach die Entwicklungszeit drastisch verkürzt wird.

Ich will DevExpress nicht unbedingt in den Vordergrund stellen, denn es gibt auch die freie 'TVirtualStringTree'-Komponente, die sehr weit verbreitet ist. Sie bringt zwar keinen extra Satz an Eingabefeldern mit, ist aber unglaublich flexibel.

Weitere Kandidaten sind TMS, JVCL usw.

[Michael Habbe]

Ich habe vor einigen Jahren mit den Quantumdingern gearbeitet.
Vollgepackt mit Funktionalität sind die natürlich erste Sahne.
Ich hatte aber glaube ich Probleme beim Filtersetzen (ja ich weiss...) auf eine große Tabelle (>300.000 DS), so dass ich das dann kurzerhand über Bord geworfen habe (war eh nur noch ein Grid).

Davon ab, müsste für diesen Fehler aber erstmal ermittelt werden, wo er überhaupt auftritt. Schließlich greifen auch Fremdkomponenten auf die VCL zurück.

Zitat:

alternative Sammlung von Eingabefeldern

Was hast Du denn da anzubieten?

Gruß
Michael

[alzaimar]

Die Grids implementieren ihre Funktionalität i.a. von Grund auf selbst. Hier sollte der Fehler also in der Form nicht auftreten. Das cxGrid von Developer Express z.B. verwendet die VCL überhaupt nicht. Die Editorensammlung ist hier zu begutachten.

Der Ansatz, 300.000 Datensätze zu filtern ist per se falsch. Wozu lädst Du so viele Daten in den Hauptspeicher? Die wird sich doch niemals jemand in Gänze anschauen. Zumal dauert das doch...

Natürlich sollte man Fehler dieser Art zunächst analysieren:
Der Fehler tritt auch beim Editieren eines Datensatzes auf. Klicke im Grid auf einen Datensatz, verändere unten irgendeinen Wertdie SpeciesNo und klicke anschließend auf den freien Bereich im Grid=> gleiches Phänomen.

Noch besser: Editiere Category im Grid, drücke Tab (oder klicke auf die Spalte 'Length (cm)' im gleichen Datensatz und anschließend auf den freien Bereich im Grid :shock: nun versucht das arme Grid, den Wert aus der 'Category' in das Feld 'Length' zu speichern, was eine Exception auslöst. Mir scheint, das Teil ist Schrott.