ECHTES kleines Demoprojekt...

[stahli]

Ich habe auch schon Fehler in der QC eingetragen (und diverse Fehlerberichte aus dem Logging gesendet).
In dem genannten Arbeitsumfeld sind sie jedoch so vielfältig, dass ich sie nicht ausreichend beschreiben kann (zumal nicht in englisch).
Sie werden aber auch für die Entwickler offensichtlich, wenn man ein kleines Projekt erstellt, das die formulierten (Mindest-)Anforderungen erfüllt.
Wenn Emba an einer Fehlerbereionigung interessiert ist, dann sollte das der schnellste Weg sein.

[hoika]

Hallo,

Wo ist das Problem,
den Fehler in leicht nachvollziehbaren Sätzen zu dokumentieren ?

Heiko

[stahli]

Zitat von hoika:

...den Fehler...

Da liegt das Mißverständnis. Es gibt nicht EINEN nachvollziehbaren Fehler sondern so viele unübersichtliche, dass eine detaillierte Beschreibung keinen Sinn macht.
Wenn das System mal grundsätzlich funktioniert und gelegentlich ein Fehler auftritt, dann gern.

[stahli]

Also Matthias hat mich an den Suppert verwiesen.
Ich werde mal versuchen, das in verständlichem Englisch zu erläutern...

PS:
Mich wundert ziemlich die ausbleibende Resonanz von Euch.
Würde Euch ein funktionsfähiges FM + LB nicht interessieren?
Eigentlich war das (evtl. in Verbindung mit DataSnap) der Grund, dass ich bei dem XE3-Upgrade zugeschlagen habe. Habe mich wohl zu leicht blenden lassen...

[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?

[Sir Rufo]

Nun meine Meinung zum Livebinding habe ich in anderen Threads schon kundgetan.
Warum sollte ich das hier noch wiederholen?

Hier geht es doch um ein Demo-Projekt und das kann ich nicht zeigen, weil das so im Moment nicht produktiv einsetzbar funktioniert.

Oder sollte das ein Thread werden, wo wir alle auf Emba immer feste drauf hauen?

Bitte nicht falsch verstehen, ich bin da völlig auf deiner Seite was die Livebindings und das Demo Projekt betrifft.

Allerdings hätte ich nicht ein abstraktes Projekt vorgeschlagen, sondern QualityCentral mit LiveBindings und ohne Zusatzkomponenten.
Das müsste doch suuuuper einfach gehen (aber bitte die Formatierung (rechtsbündig) nicht verändern, so wie es ist).

Die Antwort müsste lauten: "Derzeit nicht machbar mit Livebindings!"

[Bummi]

Ich schließe mich in diesem Punkt meinen Vorrednern an.