ECHTES kleines Demoprojekt...

[Robotiker]

Zitat von stahli:

PS:
Mich wundert ziemlich die ausbleibende Resonanz von Euch.

Also ich lese hier zumindest mit.

Unter den mir bekannten Delphi- oder C++-Benutzern in anderen Firmen habe ich aber bisher niemanden kennen gelernt, der aktiv mit FireMonkey arbeitet. Die einhellige Meinung unter allen ist, das ist sowas wie Kylix und der C++ BuilderX, verschwindet also sowieso bald wieder in der Versenkung.

Ich bleibe derzeit bei XE2 (C++), weil in XE3 der neue Compiler erst später nachgereicht werden soll. Alles was bisher in dieser Weise nachgereicht wurde (z.B. C++ Builder 2006) hatte eine Qualität, dass man eh besser bis zu nächsten regulären Version warten konnte.

[Nersgatt]

Ich lese hier auch fleißig mit. Und ehrlich gesagt sind es Berichte wie diese, die mich momentan noch davon abhalten FM produktiv einzusetzen. Einsetzen würde ich es eigentlich sehr gern. Ich hab aber Angst, mir einen Haufen Probleme einzuhandeln, die ich nicht einschätzen kann.

[Union]

Zitat von Robotiker:

Zitat von stahli:

PS:
Mich wundert ziemlich die ausbleibende Resonanz von Euch.

Die einhellige Meinung unter allen ist, das ist sowas wie Kylix und der C++ BuilderX, verschwindet also sowieso bald wieder in der Versenkung.

Word! Wie auch Quickreport, RBuilder, Rave uvm. Vor einem jahr, als ich meine ersten Zwangskontakte zur FM(α} hatte wurde ich ja als Nörgler angesehen. Und jetzt gibt es ja FM2, das ist bestenfalls β-Stadium. Und wer einmal sich die Mühe gemacht hat die LiveBindings von innen anzusehen wird sich über Performance nicht mehr wundern - da werden mehrere 10k Source pro Aufruf abgearbeitet.

[Stevie]

Zitat von Union:

Vor einem jahr, als ich meine ersten Zwangskontakte zur FM(α} hatte wurde ich ja als Nörgler angesehen. Und jetzt gibt es ja FM2, das ist bestenfalls β-Stadium. Und wer einmal sich die Mühe gemacht hat die LiveBindings von innen anzusehen wird sich über Performance nicht mehr wundern - da werden mehrere 10k Source pro Aufruf abgearbeitet.

Zumindest bei einfachen LiveBindings (Edit, Checkbox, etc) kann ich über keine Performance Probleme klagen (bei Grids und großen Datenmengen sieht das schon anders aus, daher auch in DSharp an dieser Stelle ein anderes Konzept über Datatemplates).

Ob das primär an der Menge an durchlaufenen Code liegt, mag stimmen. Primär ist jedoch die zugrunde liegende Reflection/RTTI mangels direkter Sprachunterstützung verantwortlich zu machen.

Zitat von Union:

Das kommt raus wenn man den Praktikanten ein Framework entwerfen lässt

Wenn es so wäre, wär es ja wenigstens noch eine Entschuldigung...

Hauptproblem bei der Entwicklung war mal wieder, das ganze nur mit Fishfacts und Co zu testen - ich hab das selbst schon gemerkt mit DSharp, alles super in nem kleinen Demo und dann lassen abertausende Einträge in ner Liste das Ding komplett zusammenbrechen

Ein weiterer Fehler war, für FM keine Datensensitiven Controls bzw Adapter zu bauen, da man das ja dort über LB machen kann. Dazu baut man dann einen Adapter für eine DataSource, welche dann für die Felder des DS Properties simuliert, welche dann über die LB an Controls gebunden werden... merkt ihr was?

[stahli]

Es war wie befürchtet...

Wenn das mein erster VLB-Kontakt gewesen wäre, wäre ich begeistert gewesen.
Da man aber inzwischen weiß, dass nur die strahlend weiße Spitze des Eisbergs gezeigt wird, bleibt die Begeisterung leider aus.
Irgendwie wirkt das ganze wie eine Hochglanz-Autopräsentation mit hübschen Damen, aber der Motor funktioniert noch nicht.

Schön war die Erklärung: "Man kann die LiveBindings verwenden, man muss es aber nicht." Na dann ist ja gut!

Ich bleibe dennoch (noch) optimistisch und hoffe auf eine Fehlerbereinigung in absehbarer Zeit. David I habe ich angefragt, ob seine Zusage noch gilt.


PS @Stevie: Den Grundsatz, einfache Controls an Daten zubinden (anstatt DB-Controls zu verwenden) finde ich eigentlich nicht falsch. Aber an der Umsetzung hapert es eben zu stark.

[Stevie]

Zitat von stahli:

PS @Stevie: Den Grundsatz, einfache Controls an Daten zubinden (anstatt DB-Controls zu verwenden) finde ich eigentlich nicht falsch. Aber an der Umsetzung hapert es eben zu stark.

Wenn ich mich richtig erinnere, ist es atm so, dass ich nicht einfach ein binding zwischen nem TEdit und nem Dataset/Field herstellen kann, sondern erst son TBindSourceDB Gerät benötige, welches intern die Fields auf Property "Fakes" mapped, mit denen die LB funktionieren.

[stahli]

Nächstes Problem:

Ich habe mal 100.000 Datensätze angelegt. Ein Feld ist mit Text gefüllt - also nix dramatisches.

Mit FM und der VCL braucht die IDE und die Exe bei Verwendung einer BindSourceDB ca. 2 Minuten bis die Daten angezeigt werden (hatte immer erst gedacht, die IDE hätte sich aufgehängt).

Bei Verwendung einer BindSourceDBX geht das zwar sehr fix, aber es werden immer nur 200 Records geladen (ich konnte nicht herausfinden warum das so ist).

Mit einer klassischen VCL-DB-Anwendung läuft es auf den ersten Blick erst mal korrekt.
Ob DBExpress aber sinnvoll ist wage ich inzwischen auch zu bezeifeln. Man braucht 5 Komponenten zur Verbindung an ein Gitter.

Ich denke nicht, dass Emba selbst ein ernsthaftes Projekt mit seinen eigenen Frameworks erstellen würde.

[jaenicke]

Zitat von stahli:

Mit einer klassischen VCL-DB-Anwendung läuft es auf den ersten Blick erst mal korrekt.
Ob DBExpress aber sinnvoll ist wage ich inzwischen auch zu bezeifeln. Man braucht 5 Komponenten zur Verbindung an ein Gitter.

Ich denke nicht, dass Emba selbst ein ernsthaftes Projekt mit seinen eigenen Frameworks erstellen würde.

Also was dbExpress angeht:
Das nutzen wir in Kombination mit Firebird, MS SQL und ClientDataSets sowie DataSnap immer mehr und es funktioniert auch gut soweit.