DBGrid vs. ListView

[Bernhard Geyer]

Zitat von jbg:

Zitat von Bernhard Geyer:

TElTreeStringGrid/TElDBTreeStringGrid

Die ElDOS Komponenten sind echt die besten . Heute habe ich da wieder zwei gravierende Programmierfehler in TElDBTree ausbessern dürfen.

Zum TElDBTree kann ich nicht sagen. Verwende keine DB-Controls.
Und außerdem bin ich noch aktuell bei der 3.2er-Version. Werde die 4er auslassen und gleich bei der 5er wieder einsteigen.

Zitat von jbg:

Und der Support ist auch gut: "Vererben sie halt ihre Formulare nicht, dann tritt der Fehler nicht auf". Danke.

Wer macht den sowas. Wir verwenden das TFrames-Prinzip - blos ohne Frames. Nehmen normale TForms und lassen den Inhalt "rüberschnappen". Problemlos auch bei 1 Mio. Quellzeilen.

Zitat von jbg:

Zudem sollte man das gesamte ElDOS Paket nicht mit FastMM4 und WinXP Theming kompilieren. Die vielen Speicherlecks kann man nicht derzählen ( >4000). Und zudem bekommt man da so eine tolle Exception von FastMM4, die einem Erzählt dass auf bereits freigegeben Speicher zugegriffen wird. Und da die beiden Komponenten von TElCustomDBTree abgeleitet sind, teilen skie sich die Bugs.

Da muß wohl alle Bugs im DBTree versammelt sein. Ich selbst verwende ElPack mit FastMM4 (davor MemCheck) und (Windows, not native XP-Theming) und bekomme keine Speicherlücken. ElPack 5 (Beta) hat noch ein paar aber auch nicht die Welt.

Zitat von jbg:

Wenn die Komponenten nicht schon so oft in dem Projekt verwendet würden, hätte ich sie schon lange durch JVCL Komponenten ersetzt.

Na ja. Ob die all das Können. Ist die Jedi nicht immer noch darüber die ganzen gespendeten Komponenten zu verdauen? Und ohne Unicode geht gar nichts.

Zitat von jbg:

Ein Beispiel:
FDataFields := Value; // wie war das nochmal mit Settern für StringListen, wenn man sie selbst verwaltet?

Wie schon gesagt. Muß wohl alles im DBGrid versammelt sein.
Meldest du auch diese Bugs das sie behoben werden können? Ich kann mich jedenfalls nicht beschweren. Die Fehler die ich gefunden hatte waren meist komplexerer Art.