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.