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.