Delphi XE3?

[Uwe Raabe]

Zitat:

Zitat von Insider2004 (Beitrag 1179854)

WinRT, MobileStudio, etc. sind mal wieder richtig schöne restriktive Technologien, die total verrammelt sind.

Woher hast du dein Wissen über MobileStudio, aus dem du diese Schlussfolgerung ziehen kannst? Ich kann zur Zeit noch nicht einmal nachvollziehen, wie man MobileStudio als Technologie bezeichnen kann.

[mkinzler]

MobileStudio ist ja eine IDE inkl. (ARM)Compiler und die jeweiliegen FM2 Versionen für iOS und Android. Wenn Restriktionen bestehen liegen sie nicht an Mobile Studio, sondern an der Zielpplatfoem; genauso wie an WinRT.

[Insider2004]

http://www.heise.de/developer/artike...artikelseite=4

"Das ist schon die dritte Kehrtwende bei Windows-Anwendungen in den letzten zehn Jahren. 2002 wurde Windows Forms eingeführt, 2006 die Windows Presentation Foundation, jetzt die WinRT."

"Auch ist zweifelhaft, ob sich typische Geschäftsanwendungen komplett in Metro abbilden lassen."

"Es gibt also durchaus berechtigte Zweifel daran, dass die neue Windows Runtime in der derzeitigen Form ein Erfolg werden wird. "

noch Fragen?

[mkinzler]

Zitat:

Zitat von Insider2004 (Beitrag 1179928)

http://www.heise.de/developer/artike...artikelseite=4

"Das ist schon die dritte Kehrtwende bei Windows-Anwendungen in den letzten zehn Jahren. 2002 wurde Windows Forms eingeführt,

Windows Forms war von Anfang an als Übergangstechnologie geplant.

Zitat:

2006 die Windows Presentation Foundation,

Diese war von Anfang an geplant.

Zitat:

jetzt die WinRT."

WinRT ist eine abgespeckte Version von SilverLight, was eine abgespeckte Version von WPF war. Deshalb ist es also keine neue Technologie. Ich würde hier eher eine Lenkung Microsoft zu managed Anwendungen sehen, da jetzt auch "native" Anwendungen mit einer "managed" API verbunden sind.

Zitat:

"Auch ist zweifelhaft, ob sich typische Geschäftsanwendungen komplett in Metro abbilden lassen."

Da habe ich auch meine Zweifel, aber vielleicht kommt ja eine Win9 UI, die wieder mehr "windows" ist.

Zitat:

"Es gibt also durchaus berechtigte Zweifel daran, dass die neue Windows Runtime in der derzeitigen Form ein Erfolg werden wird. "

Mal Sehen. In der jetzigen Form kann ich mich jedenfalls nicht anfreunden.

[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!).

[MEissing]

Zitat:

Zitat von Insider2004 (Beitrag 1179930)

Und EMBA rennt wieder wie eine läufige Hündin Microsoft hinterher. Anstatt endlich mal ein eigenes leistungsfähiges Cross-Framework a la Qt für Delphi anzubieten [...]

FireMonkey ist genau das....

[Insider2004]

Leider laufen VCLs nicht in FMX. Das Interface ist unnötigerweise völlig inkompatibel.

[MEissing]

Zitat:

Zitat von Insider2004 (Beitrag 1179934)

Leider laufen VCLs nicht in FMX. Das Interface ist unnötigerweise völlig inkompatibel.

Unnötigerweise?

Die VCL ist seit Delphi 1 nur und ausschliesslich auf Windows optimiert/lauffähig/fixiert.... Versuche von CLX und VCL.Net unterstützen retrospektiv diese Aussage. :-D

Controls, Messages, Events.... das ist durch-und-durch Windows (bei der VCL). Die Notwendigkeit etwas Anderes zu machen, was den normalen Delphientwickler aber dennoch recht schnell produktiv arbeiten lässt (sooo groß ist der Unterschied zwischen VCL und FireMonkey auch nicht. MonkeyGroomer, Mida etc zeigen ja auch, das man es (weitgehend) automatisiert konvertieren kann), gleichzeitig verlangst Du ("so wie QT") aber weitgehende Kompatibilität?

[mkinzler]

Zitat:

Leider laufen VCLs nicht in FMX. Das Interface ist unnötigerweise völlig inkompatibel.

Man soll also nicht MS hinterherlaufen, aber dabei MS weiterhin hinterherlaufen.

Du widersprichst dir selbst. VCL ist nun mal eine Technologie, die währrend ihrer Entwicklung stark mit dem Windowsbetriebssystem verbunden wurde. Diese wieder zu Trennen wäre unnötig kompliziert ( obwohl es für das Scheitern der CLX/VCL.Net auch andere Gründe gab). Ich erhoffe mir ja für FireMonkey eine Mischung der Konzepte von SWT/Qt und VGScene (FMX/I), nähmlich die Integration von nativeb Bestandsteilen wo möglich ( wie in fm2 mobile)

[Insider2004]

Zitat:

Zitat von MEissing (Beitrag 1179939)

Zitat:

Zitat von Insider2004 (Beitrag 1179934)

Leider laufen VCLs nicht in FMX. Das Interface ist unnötigerweise völlig inkompatibel.

Unnötigerweise?

Die VCL ist seit Delphi 1 nur und ausschliesslich auf Windows optimiert/lauffähig/fixiert.... Versuche von CLX und VCL.Net unterstützen retrospektiv diese Aussage. :-D

Controls, Messages, Events.... das ist durch-und-durch Windows (bei der VCL). Die Notwendigkeit etwas Anderes zu machen, was den normalen Delphientwickler aber dennoch recht schnell produktiv arbeiten lässt (sooo groß ist der Unterschied zwischen VCL und FireMonkey auch nicht. MonkeyGroomer, Mida etc zeigen ja auch, das man es (weitgehend) automatisiert konvertieren kann), gleichzeitig verlangst Du ("so wie QT") aber weitgehende Kompatibilität?

Das ist mir alles bekannt. Was ich meine ist, das teilweise OnShow oder OnClick events fehlen bei manchen Komponenten. Es ist unmöglich seinen VCL code da irgendwie zu portieren. Das muss doch nicht sein. Ich hoffe, irgendwer bei EMBA erbarmt sich noch und macht die Interfaces wenigstens gleich zu VCL.

Ein anderes Beispiel ist z.b. dass aus .Caption plötzlich .Text wurde. Man hat nur einen Haufen Arbeit damit.

[jaenicke]

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Ein anderes Beispiel ist z.b. dass aus .Caption plötzlich .Text wurde. Man hat nur einen Haufen Arbeit damit.

In den meisten Anwendungen dürfte der GUI-Layer den kleinsten Teil des Codes ausmachen. Und wenn dort dann etwas angepasst werden muss, betrifft dies ja nicht den restlichen Code. Sofern man die GUI nicht zu stark verdrahtet hat.
Und, sorry, aber wer das macht, der ist selbst schuld.

[cookie22]

Das Problem an FMX ist einfach, dass die Programme weder unter Windows noch unter OS X aussehen wie native Programme.

Zweitens weiß man leider, wie schnell hochgelobte Technologienen bei Delphi wieder abgeschossen werden. Das haben wir einfach schon viel zu oft erlebt.

Mit FMX wäre ich mehr als Vorsichtig.

Beruhen die sogenannten Metrostyle Apps von XE 3 auf FMX? Oder wie hab ich mir das vorzustellen?

[jaenicke]

Zitat:

Zitat von cookie22 (Beitrag 1179952)

Das Problem an FMX ist einfach, dass die Programme weder unter Windows noch unter OS X aussehen wie native Programme.

Das hat Java ja auch nicht wirklich geschadet...
Wobei das bei OS X mit den Designjüngern natürlich schon noch etwas anders ist als bei Linux oder Windows.

[MEissing]

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Das ist mir alles bekannt.

Dann ist ja gut.

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Was ich meine ist, das teilweise OnShow oder OnClick events fehlen bei manchen Komponenten. Es ist unmöglich seinen VCL code da irgendwie zu portieren. Das muss doch nicht sein. Ich hoffe, irgendwer bei EMBA erbarmt sich noch und macht die Interfaces wenigstens gleich zu VCL.

Konkret? Was fehlt? Und wo?

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Ein anderes Beispiel ist z.b. dass aus .Caption plötzlich .Text wurde. Man hat nur einen Haufen Arbeit damit.

Haufen Arbeit?

Wenn die GUI *Dein* Hauptproblem ist......

[jaenicke]

Zitat:

Zitat von MEissing (Beitrag 1179956)

Konkret? Was fehlt? Und wo?

Mir fehlen (wie bei der VCL) Eingriffsmöglichkeiten, ganz allgemein gesagt. Sei es das gerade hier im Forum diskutierte Problem zu verhindern, dass sich der Fokus ändert, wenn bei der Eingabe ein Fehler aufgetreten ist (aber SetFocusControl ist nicht virtuell --> ich komme nicht heran). Oder sei es auch an anderen Stellen, dass ich an viele Sachen nicht herankomme oder sie nicht (sinnvoll) ändern kann, weil ein Feld privat ist oder weil eine Methode nicht virtuell.
Das Nachschlagen in der VMT kostet sicher auch ein paar Takte, aber Flexibilität halte ich für wichtiger als Geschwindigkeitsunterschiede in diesen geringen Dimensionen.

Ich musste schon z.B. Klassen aus Generics.Collections fast komplett identisch erneut implementieren, einfach weil sie sehr starr und nur für den einen Zweck programmiert sind.

Weitere konkrete Beispiele müsste ich heraussuchen, wenn ich wieder aus dem Urlaub bin, hier am Laptop fehlen mir viele meiner Quelltexte.

Mit Firemonkey werde ich erst mit XE3 produktiv arbeiten, wenn/falls wir das Upgrade gekauft haben werden. Insofern hatte ich bisher nicht so viele Möglichkeiten mich damit zu beschäftigen. (Auf einen Wartungsvertrag hatten wir aufgrund der spärlichen Informationen im Hinblick auf Roadmaps verzichtet. Und so müssen wir über ein Upgrade auf XE3 erst noch entscheiden.)
Und da ist mir in der Hinsicht auch schon ein wenig aufgefallen. Trotzdem kann man sehr gut damit arbeiten, da bin ich mir sicher, aber mehr Flexibilität und Eingriffsmöglichkeiten wären schon wünschenswert.

[Insider2004]

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Was ich meine ist, das teilweise OnShow oder OnClick events fehlen bei manchen Komponenten. Es ist unmöglich seinen VCL code da irgendwie zu portieren. Das muss doch nicht sein. Ich hoffe, irgendwer bei EMBA erbarmt sich noch und macht die Interfaces wenigstens gleich zu VCL.

Konkret? Was fehlt? Und wo?

[/QUOTE]

Das mit der Caption bekommt man mit einem ifdef noch gebacken. Wenn aber z.B. eine Combobox kein OnSelect hat wird es haarig! Das ist jetzt nur ein Fehler von vielen, der mir jetzt einfällt. FMX ist zur Zeit für mich nicht zu nutzen. Selbst der Mida-Konverter konnte vieles nicht konvertieren, weil es in FMX keine Zielfunktion gab.

[Insider2004]

Zitat:

Zitat von jaenicke (Beitrag 1179950)

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Ein anderes Beispiel ist z.b. dass aus .Caption plötzlich .Text wurde. Man hat nur einen Haufen Arbeit damit.

In den meisten Anwendungen dürfte der GUI-Layer den kleinsten Teil des Codes ausmachen. Und wenn dort dann etwas angepasst werden muss, betrifft dies ja nicht den restlichen Code. Sofern man die GUI nicht zu stark verdrahtet hat.
Und, sorry, aber wer das macht, der ist selbst schuld.

Das ganze Delphi-Konzept beruht darauf, dass GUI und Code stark verdrahtet sind. Deine Betrachtung ist rein theoretisch und mit Delphi nicht zu vereinbaren. Das geht vielleicht in der MFC von MS.

[Darlo]

Zitat:

Zitat von MEissing (Beitrag 1179956)

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Was ich meine ist, das teilweise OnShow oder OnClick events fehlen bei manchen Komponenten. Es ist unmöglich seinen VCL code da irgendwie zu portieren. Das muss doch nicht sein. Ich hoffe, irgendwer bei EMBA erbarmt sich noch und macht die Interfaces wenigstens gleich zu VCL.

Konkret? Was fehlt? Und wo?

Was mich jetzt wirklich Zeit und nerven gekostet hat:

Code:

showmessage('{6AFF0DB2-89AB-4F13-8AD6-3BB61870AF4E}');

Das Ergebnis ist "{6AFF0DB2-89AB-4F13-8AD6-" :wall:

Gruß

[jaenicke]

Zitat:

Zitat von Insider2004 (Beitrag 1179975)

Das ganze Delphi-Konzept beruht darauf, dass GUI und Code stark verdrahtet sind. Deine Betrachtung ist rein theoretisch und mit Delphi nicht zu vereinbaren. Das geht vielleicht in der MFC von MS.

Das geht auch mit Delphi sehr gut. Ich mache das mit Delphi auch. Der GUI-Layer lässt sich so komplett gegen einen anderen Layer austauschen.
Natürlich hat der auch ein gewisses Maß an Logik drin. Aber eben nur so viel wie die GUI benötigt, nichts zu den Daten an sich.

[Insider2004]

Zitat:

Zitat von jaenicke (Beitrag 1179986)

Zitat:

Zitat von Insider2004 (Beitrag 1179975)

Das ganze Delphi-Konzept beruht darauf, dass GUI und Code stark verdrahtet sind. Deine Betrachtung ist rein theoretisch und mit Delphi nicht zu vereinbaren. Das geht vielleicht in der MFC von MS.

Das geht auch mit Delphi sehr gut. Ich mache das mit Delphi auch. Der GUI-Layer lässt sich so komplett gegen einen anderen Layer austauschen.
Natürlich hat der auch ein gewisses Maß an Logik drin. Aber eben nur so viel wie die GUI benötigt, nichts zu den Daten an sich.

Kannst Du da mal ein Beispiel anhand einer Procedure geben? Kann ich mir nicht vorstellen, wie man den GUI-Layer einfach so austauschen kann.

[Uwe Raabe]

Zitat:

Zitat von Insider2004 (Beitrag 1179995)

Zitat:

Zitat von jaenicke (Beitrag 1179986)

Zitat:

Zitat von Insider2004 (Beitrag 1179975)

Das ganze Delphi-Konzept beruht darauf, dass GUI und Code stark verdrahtet sind. Deine Betrachtung ist rein theoretisch und mit Delphi nicht zu vereinbaren. Das geht vielleicht in der MFC von MS.

Das geht auch mit Delphi sehr gut. Ich mache das mit Delphi auch. Der GUI-Layer lässt sich so komplett gegen einen anderen Layer austauschen.
Natürlich hat der auch ein gewisses Maß an Logik drin. Aber eben nur so viel wie die GUI benötigt, nichts zu den Daten an sich.

Kannst Du da mal ein Beispiel anhand einer Procedure geben? Kann ich mir nicht vorstellen, wie man den GUI-Layer einfach so austauschen kann.

Wie sollte ein solches Beispiel anhand einer Procedure denn aussehen? Das hat ja nichts mit irgendwelchen Methoden zu tun, sondern mit dem generellen Programmaufbau. Nimm z.B. eine Datenbankanwendung und verlagere die Datenzugriffskomponenten und deren Ereignisse in ein Datenmodul. Nun ist es ein Leichtes, je ein VCL- und FMC-Form zu erstellen, das die Daten in seinen entsprechenden Controls darstellt.

Das Ganze lässt sich auch noch weiter abstrahieren und auf andere Fälle anwenden. Man muss nur konsequent die Programmlogik von der GUI trennen, dann ist ein Austausch der GUI kein Problem.

Da FMX ab XE3 auch Actions unteerstützt, wird ein solches Vorhaben noch einfacher.

[Insider2004]

Ein Beispiel wäre nett. Gibts kein Opensource-Programm wo das verwirklicht wurde?

[mkinzler]

https://radstudiodemos.svn.sourcefor...y/ActionsDemo/

[Darlo]

Zitat:

Zitat von mkinzler (Beitrag 1180004)

https://radstudiodemos.svn.sourcefor...y/ActionsDemo/

Bräuchte man nur XE3 ;-). Scheinen aber einige hier zu haben (Vermutung).

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

[Insider2004]

In Lazarus haben sie das Performance-Problem nicht.

[mkinzler]

Firemonkey unter Lazarus?

[greenmile]

Jetzt kommen wir doch endlich mal zum Kern. Ich finde den Weg, den EMBA geht, richtig und gut. Aber für mich sind LiveBindings und Win8 Support nur halb so wichtig, Mit XE2 wurde mir etwas versprochen, was nicht 100% funktioniert (= FM), Nun folgt XE3 und plötzlich wird aus einem Produkt (iOS Support, wie in XE2 halbherzig integriert) zwei Produkte. Kann ich Delphi selbst noch mit einer SA oder für 500 EUR für das Upgrade abdecken, kommt nun plötzlich ein zweites Produkt mit ins Spiel. Das sieht für mich wirklich nach Schnupperversion in XE2 aus, das ist nicht korrekt, auch wenn das bei EMBA wahrscheinlich niemanden ernsthaft interessiert. Ich kann nur hoffen, dass die Performance von FM2 endlich auf ein halbwegs akzeptables Niveau angehoben wird und die peinlichen Bugs verschwinden ,dann wird das was. Ansonsten könnte es echt peinlich werden. Es ist fast unmöglich mit FM eine Mac Anwendung zu erstellen der man nicht ansieht, dass sie mit Delphi entwickelt wurde. Es ist wie damals VisualBasic: Nicht performant und eher eine Lachnummer. Und ich mag Delphi!

Aber letztendlich kann man nur abwarten was kommt, es dauert ja nicht mehr lange und vielleicht werden wir ja alle eines besseren belehrt.

[Bernhard Geyer]

Zitat:

Zitat von cookie22 (Beitrag 1179952)

Das Problem an FMX ist einfach, dass die Programme weder unter Windows noch unter OS X aussehen wie native Programme.

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.

Zitat:

Zitat von cookie22 (Beitrag 1179952)

Zweitens weiß man leider, wie schnell hochgelobte Technologienen bei Delphi wieder abgeschossen werden. Das haben wir einfach schon viel zu oft erlebt.

Das stimmt leider. CLX/VCL.NET oder generell der Nicht-Oxygen-Pascal-Port.

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Leider laufen VCLs nicht in FMX. Das Interface ist unnötigerweise völlig inkompatibel. ... das teilweise OnShow oder OnClick events fehlen bei manchen Komponenten.

WOW. 2 Fehlende Events bedeuten völlig inkompatibel.

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Es ist unmöglich seinen VCL code da irgendwie zu portieren.

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

Zitat:

Zitat von Insider2004 (Beitrag 1179943)

Ein anderes Beispiel ist z.b. dass aus .Caption plötzlich .Text wurde.

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.

[MEissing]

Zitat:

Zitat von Peter666 (Beitrag 1180024)

@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:

Zitat von Bernhard Geyer (Beitrag 1180032)

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:

Zitat von MEissing (Beitrag 1180047)

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:

Zitat von Bernhard Geyer (Beitrag 1180031)

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:

Zitat von bernau (Beitrag 1180055)

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:

Zitat von bernau (Beitrag 1180055)

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:

Zitat von Insider2004 (Beitrag 1179930)

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:

Zitat von bernau (Beitrag 1180058)

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ß