Welche Konsequenzen zieht ihr aus den Features für XE2?

[Stevie]

Zitat:

Zitat von mquadrat (Beitrag 1117978)

Jep, so hat es DevExpress ja auch geschrieben. Das Problem ist nur das ohne sinnvolles Grid FireMonkey zum Scheitern verurteilt ist. Es muss ja nicht dermaßen überfrachtet sein, wie manche der Third-Party-Grids, aber mehr als das VCL StringGrid braucht es schon.

Wenn also alle so wie DevExpress reagieren haben wir die Situation, dass keiner FireMonkey einsetzt, weil ein Grid fehlt und es kein Grid gibt weil keiner FireMonkey benutzt ;)

Aber warten wir erstmal ab, bis wir die ersten FireMonkey Programme am laufen haben

Wenn man mit nem Listview oder einer Listbox sowas machen kann wie in WPF braucht kein Mensch ein Grid.

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1118016)

Wenn man mit nem Listview oder einer Listbox sowas machen kann wie in WPF braucht kein Mensch ein Grid.

Denke ich auch. Ob die Komponenten nun Grid oder ListView oder "WundercontroldasAllesKann" heißt ist eigentlich egal. Solange es was gibt mit dem man Daten tabelarisch/als List Anzeigen kann und genügend Schalter für die eigene Bedürfnisse gibt ist es gut. Und wenns noch List + Baum kann (wie Kompos von LMD/TMS oder VST) dann braucht man auch kein eigene Treeview-Komponente.

[jaenicke]

Zitat:

Zitat von mquadrat (Beitrag 1117975)

Denn so wie sich das Statement liest, scheint FireMonkey im Moment nicht über ein sinnvolles Grid zu verfügen.

Ich weiß nicht welches Statement du genau meinst, aber die Kommentare zu den Grids beziehen sich nur auf Grids von DevExpress. Deshalb interpretiere da nichts hinein, was da gar nicht steht. ;-)

[cookie22]

Ich halte es für mehr als weit hergeholt, dass der Erfolg von Fire Monkey von einer Komponente abhängen sollte.

[Florian Hämmerle]

Zitat:

Zitat von cookie22 (Beitrag 1118058)

Ich halte es für mehr als weit hergeholt, dass der Erfolg von Fire Monkey von einer Komponente abhängen sollte.

Wenn die Component Library von FireMonkey allerdings gegenüber der normalen VCL Vorteile bietet, ist die Chance größer, das FM gut aufgenommen wird.

[cookie22]

Das aber an einem Grid fest zu machen, ist für mich nicht nachvollziehbar.

Ausserdem wird schon jemand eines schreiben ob nun Commercial oder Freeware, geben tut es das ganz sicher. Um sowas würde ich mir gar keinen Kopf machen. Hauptsache das ganze läuft von Anfang an stabil, sowas seh ich als viel wichtiger an.

[Florian Hämmerle]

Das ist ganz klar. Ich sehe Firemonkey auch als Chance, Altlasten los zu werden. Wenn man nur mal bedenkt, wie alt manche Komponenten schon sind und was man damals noch gar nicht bedacht hat, heute aber verlangt wird. Da können einige schöne Projekte draus werden :)

[DSCHUCH]

Hoi,

Kann mir eigentlich mal jemand verraten was der unterschied zwischen dem neuen "databindings-feature" und dem bestehenden DataSet-DataSource-Funktionen ist?

[Phoenix]

Mit dem Datasource-quatsch ist es z.B. nicht möglich, ein Objekt mit belieben Properties (z.B. Text, Enabled, Action) and einen Button zu binden, wobei sich die Caption vom Button ändern wenn ich den Text des Objektes ändert und der Button-state sich ändert wenn ich Enabled auf dem Objekt umstelle.

[Stevie]

Zitat:

Zitat von DSCHUCH (Beitrag 1118079)

Hoi,

Kann mir eigentlich mal jemand verraten was der unterschied zwischen dem neuen "databindings-feature" und dem bestehenden DataSet-DataSource-Funktionen ist?

Bestehende DataSet-DataSource-Funktion basiert darauf, dass deine Daten in einem TDataSet (oder davon abgeleitet) vorliegen und die nötigen Dinge in den Controls implementiert sind (auf TDataSource Events reagieren, etc). In der Theorie kannst du bei den LiveBindings ein TColorBox.Selected and dein Form1.Color binden und damit die Farbe wechseln. Oder du kannst aus einem TCustomer Object die Property LastName und FirstName an 2 Edits binden. Oder die property PaymentMethod an eine TComboBox, in der du die möglichen Werte auswählen kannst. Mehr zu DataBinding und Delphi siehe meine Sig ;)