Delphi XE3?

[MEissing]

Zitat von Peter666:

@MEissing: Ich weiß das ist sicher der falsche Thread, aber ich versuch es dennoch: Das große Problem bei FMX ist wohl die Performance. Ich denke, nachdem ich den FMX Code überflogen habe (mehr als überfliegen ist aufgrund des Umfangs eh nicht drin) ist das Grundproblem die Tatsache das da alle Komponenten über das Canvas gerendert werden. An und für sich mache ich das bei unseren (DirectX) Anwendungen auch, aber ich verstehe die unterirdische Performance nicht. Es ist absolut ein Unding, dass eine simple Listbox bei einem Scrollvorgang dermaßen horrende CPU Auslastungen verursacht. Ein Kernproblem (zumindest bei MacOS) liegt im Rendern von Text. Ohne einen Rasterizer wird das sicherlich nicht besser werden. Ist denn in Zukunft geplant etwas an der Geschwindigkeit zu verbessern?

Wir haben an der Performance von FM/FM2 deutlich geschraubt. Schick mir ein Testprogramm (vllt mit Tickcounts) und ich lass es mal unter XE2 und XE3 laufen...

[MEissing]

Zitat von Bernhard Geyer:

WOW. 2 Fehlende Events bedeuten völlig inkompatibel.

WEnn du allein schon bei solchen Kleinigkeiten scheiterst ist m.E. der Beruf eines SW-Ingenieurs/Entwicklers eine falsche Wahl.

Solche Änderung ist doch gut. Endlich hat man eine einheitliche Bezeichung für so ein Element und muss bei generischer Implementierung nicht Ständig zwischen Caption/Text und wer weiß sonst noch unterscheiden. Und man muss nicht jedesmal umstellen wenn man auch mit der .NET oder Java-Welt zu tun hat.

+1

(Wobei die Form immer noch eine .Caption hat

[greenmile]

Zitat von MEissing:

Wir haben an der Performance von FM/FM2 deutlich geschraubt. Schick mir ein Testprogramm (vllt mit Tickcounts) und ich lass es mal unter XE2 und XE3 laufen...

Danke, damit wäre eine für mich wichtige Frage geklärt. Hast Du eine Info, wie es mit den anderen "Dingen" aussieht, wie Drag&Drop (im Detail bei der TListBox) unter Mac etc.?

[Robotiker]

Abseits dieser .Text oder .Caption Niedlichkeiten habe ich ganz andere Bauchschmerzen mit der Kompatibilität in XE3, nämlich was die C++ Personality angeht.

Wenn ich die aktuelle Nachrichtenlage richtig deute, wird der aktuelle 32-Bit C++ Compiler, der noch aus einer Entwicklungslinie stammt, die 1995 mit Borland C++ begann, in beibehalten. D.h. weiterhin nicht neues in Sachen ISO-Standard und man hängt an einer Boost-Version fest, die mittlerweile zwölf (!) Versionen zurückhängt.

Was den 64-Bit Compiler angeht, ist mein Informationsstand, dass nur eine Beta-Version im XE3 Release enthalten sein wird und diese später im Rahmen eines Updates zur Vollversion mutieren soll. Grund für diese Verzögerungen dürfte sein, das man VCL/Firemonkey und Compiler erstmal so "hinbiegen" muss, damit beide Compilerarchitekturen damit klarkommen.

Wenn ich aber nur daran denke, wie die parallel Entwicklung von 32- und 64-Bit Anwendungen mit so einer gespaltenen Toolchain aussehen soll, dann sträuben sich mir die Nackenhaare.

Nun sind wir in der glücklichen Lage, mittlerweile fast vollständig auf Visual Studio umgestiegen zu sein. Noch leiste ich mir aber regelmäßig eine C++ Builder Professional Lizenz, um immer mal wieder zu schauen, ob man nicht mal etwas machen könnte ...

Im Moment tendiere ich aber eher dazu zu sagen, "Warten wir mal 3-4 Jahre ab, dann kann man mal schauen, ob sie was brauchbares hingekriegt haben". Die Erfahrungen mit Kylix für C++ und dem C++ BuilderX wirken da noch nach.

[bernau]

Zitat von Bernhard Geyer:

Ist das nicht mittlerweile irrelevant? Vor allem auf Windows ist das doch mittlerweile sch*** egal. Viele erfolgreiche Programme sind deshalb so erfolgreich weil sie sich nicht strikt an (sich alle 2 Jahre ändernde) GUI-Styleguids halten. Mittlerweile brechen doch praktisch 100% alle Webbrowser z.B. dem dem Styleguid bezüglich Menu/TabControl-Layout.

Jep. Das sehe ich auch so. Möchte nicht wissen, wie viele Delphi-Entwickler Skin-Komponenten einsetzen, damit die Software "anders" aussieht.

Zu OSX sage ich mir: Lieber ein Programm, welches nicht 100% Native aussieht (mit FMX), als kein Programm. Anderes als Delphi kann und will ich nicht nutzen.

[Darlo]

Zitat von bernau:

Jep. Das sehe ich auch so. Möchte nicht wissen, wie viele Delphi-Entwickler Skin-Komponenten einsetzen, damit die Software "anders" aussieht.
Zu OSX sage ich mir: Lieber ein Programm, welches nicht 100% Native aussieht (mit FMX), als kein Programm.

Schließe ich mich an. Gerade individual Software wird ja oft anders als "Nativ-Look" gefordert.

[greenmile]

Zitat von bernau:

Zu OSX sage ich mir: Lieber ein Programm, welches nicht 100% Native aussieht (mit FMX), als kein Programm. Anderes als Delphi kann und will ich nicht nutzen.

Unterschrieben.

[bernau]

Zitat von Insider2004:

Und EMBA rennt wieder Microsoft hinterher. Anstatt endlich mal ein eigenes leistungsfähiges Cross-Framework a la Qt für Delphi anzubieten (ich möchte da an das erfolgreiche Delphi for .Net 2007 erinnern!).

Die integration von QT fand ich schon damals nicht optimal. Eine Software, die von Borland lizensiert wurde, Borland aber nicht gehörte. Was, wenn QT verkauft werden würde? (was ja letztendlich auch passiert ist). Ne, dann lieber Firemonkey unter den Fittichen von Emba.

Ich kann es nur immer wieder sagen: FM ist das besste was Delphi passieren konnte. Noch nicht 100% ausgereift, aber die richtige Richtung.

[Darlo]

Zitat von bernau:

Ich kann es nur immer wieder sagen: FM ist das besste was Delphi passieren konnte. Noch nicht 100% ausgereift, aber die richtige Richtung.

Und damit ist Delphi das Beste was mir passieren konnte. Wenn das Mobile Studio gut wird , wird das uns Aufschwung verschaffen.

[Darlo]

Hat jemand Infos darüber ob FastReport definitiv auch im Mobile Studio enthalten und unterstützt wird?

Gruß