RAD Studio XE7: Was Entwickler davon halten...

[Harry Stahl]

Also, nun habe ich ein größeres Projekt nach XE7 übernommen (bzw. bin dabei) und möchte daher kurz drüber berichten:

Die Übernahme von einem XE5 zu einem XE7-Projekt funktionierte erst mal soweit gut.

Allerdings wieder die üblichen Sachen:

Die Units "FMX.SpinBox" und "FMX.ComboEdit" mussten überall in den Forms da ergänzt werden, wo bislang die entsprechenden Komponenten verwendet worden sind, denn die waren vorher in einer anderen Unit. Das ist eine blöde Arbeit, wünschte mir, EMA ließe sich bei der Übernahme von bisherigen Projekten noch etwas einfallen.

Die beiden Komponenten bereiten zudem Probleme: Direkt wenn man eine Form öffnet, welche diese enthält werden diese immer in der Standardgröße angezeigt, wie wenn man Sie irgendwo einfügt. Diese Problematik gilt aber "nur" wenn diese Komponenten innerhalb eines TabControls liegen (siehe die beiden anliegenden Screenshots).

Ich hoffe, ich krieg das noch irgendwie hin. Was mir sehr gut gefällt, dass die Grids (wohl schon seit XE6) jetzt richtig schnell geworden sind (und vor allem auch unter MAC OS X). Und zwar um ein vielfaches schneller, eigentlich so wie unter der VCL gewohnt.

Daher habe ich heute ganz spontan das PC-Rechnungs-Projekt, das fast unter XE5 ja schon für Windows fertig war, für MAC OS aber nur zu 90%, nach XE7 übernommen. Die Arbeit mit der IDE geht gut und flott. Blöd, dass ich jetzt an diesem Problem hänge.

In meiner Verzweifelung hatte ich versucht, ein Formalar vom Master in der Variante "Windows Desktop" bzw. "MAC OS" abzuleiten, in der Hoffnung, dass die Komponenten da dann richtig angezeigt werden. Da kommt dann aber leider der Fehler:
"Vererbung von Formular "frm_Options" nicht möglich. Es enthält eine Komponente mit einem leeren Eigenschaftsnamen." (Siehe Screenshot).

[Sir Rufo]

Ich würde ein FMX.Layouts.TGridLayout nehmen und dann die Elemente da reinwerfen.

BTW In so einem TabControl würde ich immer mit Frames arbeiten, dann wird das insgesamt wesentlich übersichtlicher.

[Harry Stahl]

Ich habe es mal mit einem TLayout versucht, so nach dem Motto mal sehen, wenn es ein anderer Parent ist. Hat aber auch nicht geholfen.

Das wird wohl so ein richtig fieser Bug sein.

Workaround sieht so aus: Zur Laufzeit die Breite einstellen (entweder "meine" Standardbreite oder Eigenschaft "Tag" mit Wert belegen und zur Laufzeit dann alle Controls der problematischen Controls abklappern und die richtige Breite aus "Tag" setzen.

Doof, aber wirkt.

[Harry Stahl]

Mal was positives: Sehr schön finde ich, dass mal z.B. auch in der Masteransicht auf MACOS umschalten kann. Dann sieht man direkt, wie Styles für diese Plattform vornehmen und kann direkt Korrekturen vornehmen, falls man für einzelne Buttons noch einen falschen Style hatte.

Also das erleichtert schon die Arbeit.

Ein wenig langsamer (z.T. spürbar) wird die IDE, wenn man eine Windows und MAC-Form ableitet und viele Komponenten (z.B. hundert oder mehr) drauf sind. Ich denke da könnte EMBA noch etwas nachbessern.

[Sir Rufo]

Bei hundert und mehr Komponenten auf einer Form hat man aber erheblich mehr Probleme.

Da kann man bestimmt ein paar zu logischen Einheiten zusammenfassen, ein Frame daraus bauen (das man auch öfter wiederverwenden kann ;)) und dadurch das Ganze entzerrt.

[himitsu]

Wo kommen eigentlich diese Aussagen her?

Und warum sagt Gerhard Stoltz in der eMail was komplett anderes, als auf der Webseite? (abgesehn von deutsch in der Mail und englisch auf der Webseite)



Aber Ja, natürlich wird Delphi mit jeder Version besser, womit es kein Wunder ist, daß XE7 von allen Delphi's praktisch das Beste sein wird.
Wobei Größer = Besser? (kompilieren linken dauert länger und die EXEn werden auch immer größer)

Zitat:

Welche Vorteile hätte es z.B von Delphi 5 jetzt auf XE7 umzusteigen?

Erstmal unterstützt die IDE und auch erstellten die Programme aktuellere Windows-Versionen besser, vorallem was das Rechtemanagement (hier und da hat man nicht mehr reinzuschreiben, bzw. hatte es eigentlich noch nie, seit NT/2K) und die Fensterbehandlung (Aero-Preview=MainFormOnTaskbar usw.)
Und dann natürlich alle "neuen" Sprachfeatures der letzten 15 Jahre.

Nachteil: Beim Unicodeumstieg muß aufgepasst werden (OK, eigentlich nicht so sehr, wenn man früher alles richtig gemacht hatte) und ein paar Funktionen/Typen wurden in den Units umhergeschoben, bzw. Proeperty/Methoden/Funktionen wurden mit der Zeit umbenannt oder gegen neuere Schnittstellen ausgetauscht. (vorallem Indy)

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1274169)

Wo kommen eigentlich diese Aussagen her?

Und warum sagt Gerhard Stoltz in der eMail was komplett anderes, als auf der Webseite? (abgesehn von deutsch in der Mail und englisch auf der Webseite)

Du wirst schon wissen was Du meinst.

Zitat:

Zitat von himitsu (Beitrag 1274169)

Nachteil: Beim Unicodeumstieg muß aufgepasst werden (OK, eigentlich nicht so sehr, wenn man früher alles richtig gemacht hatte)

Was heißt hier "richtig"? Wichtig ist doch vielmehr wofür man Char/String eingesetzt hat. Solange man es nur mit Buchstaben und Text zu tun hat, ist man auf der sicheren Seite. Wenn allerdings die Frage auftaucht ob da jetzt ein Char 8 oder 16 Bit groß ist, da wird's dann interessant, und nicht zu vergessen Umlaute, die in der Darstellung nur ein Zeichen groß sind, deren Codierung aber mehrere Bytes umfasst, da muß man dann manchmal mitdenken.

Gruß
K-H

[himitsu]

richtig:

Wenn das immer ANSI sein mußte, dann auch als ANSI deklariert (vorallem bei Schnittstellen und Speicher-/Transferdaten).
Da wo es "egal" war, die Alias Char/PChar/String verwendet.
Und zusammengehöriges auch richtig deklariert, wie z.B. CreateFile > PChar/String und CreateFileA > PAnsiChar/AnsiString.

So wie man es schon vom Alias "Integer" her schon kannte, der in Delphi 1 noch 16 Bit war. (OK, daß man auf die Idee kommt den Integer bei 64 Bit auf 32 Bit einzufrieren und dafür einen Neuen zu erfinden, konnte keiner ahnen)
String und PChar waren ja schon per Definition schon länger als veränderlich definiert,
auch wenn Delphi über 10 Jahre brauchte, bis es sich dem Unicode-Windows angepasst hatte und noch länger dauerte es bis zum Windows 64.

[p80286]

Da würde ich Dir nicht widersprechen, nur wie erkläre ich einem unbedarften Menschenkind, daß M$ Ansi,(Oem),UTF8 und Unicode fröhlich durcheinander würfelt (*.doc Word 2003). Da sind Deine "richtigen" Arbeitsweisen dann nur noch Richtlinien wie man tunlichst programmieren sollte, damit die Fehlerhäufigkeit nicht so hoch ist, und vor allem, wenn dann mal ein Fehler auftaucht, er schneller zu finden ist.

Was die Integers angeht,Da nutz ich (wo immer es geht) Int16,Int32,Int64 bzw. Word16,Word32,Word64.

Gruß
K-H

[himitsu]

Was gerne gemacht wurde, was Pointer/Object <-> Integer, welches ja funktionieren würde, wenn der INT/Integer mit wachsen würde.

Bei SendMessage nutzte ich sowieso gerne die Original-Typen (LPARAM, WPARAM und LRESULT), womit ich dort fast keine Probleme hatte.
Aber ansonsten ist der Typ IntPtr in Delphi halt nicht so geläufig, denn der wäre für solche Cast der Richtigere. (neben NativeInt/NativeUInt jetzt und Integer/Cardinal früher)

[Bambini]

Zitat:

Zitat von Back2Code (Beitrag 1273592)

Welche Vorteile hätte es z.B von Delphi 5 jetzt auf XE7 umzusteigen?

Bei D5 auf XE7 kommen noch die unicode Strings auf dich zu.
Aber früher oder später muss man du da wohl ran :wink:

Ein großes Problem der aktuellen XE7 Version ist der instabile Quell-Code Parser,
der mit Code Inside/Code Completion helfen soll. Der hat wohl einen größeren BUG und frist den Speicher
bzw. zerhackt diesen. Ich habe ein großes VCL Projekt (ca. 500 direkte eigene Units, mit DevExpress und einigen anderen Tools).
Nach dem Öffnen und einigen Code Änderungen bläht sich die XE7 IDE auf 1GB auf und raucht dann kurze Zeit dannach mit
"out of memory" beim Tippen oder compilieren komplett ab.
Das Navigieren im Code, schon alleine mit dem Cursor durch den Code zu laufen ist in diesem Projekt super langsam.

Bin nach vielen Versuchen wieder auf die XE6.1 Version zurückgegangen und warte auf SP1.
Kommt wohl in Kürze, da iOS 8 Entwicklung mit dem XCode 6 auch nicht klappt.

Fazit: not ready yet.

Resume: Sofern man eh nix mit Crossplatform unter Firemonkey am Hut hat und die kleinen Neuerungen im VCL nicht braucht, kann man sich das Update seit Jahren sparen. Die EXE werden immer größer und die Compiler machen nix schneller.

[himitsu]

Nja, wenn er sich nicht grade die XE7 Starter zulegt, sondern mindestens Professional, dann bekommt er die XE6 und Alles davor gratis dazu (bis runter zu D7) und hatte dann die große Auswahl.

[Bambini]

Zitat:

Zitat von himitsu (Beitrag 1274231)

Nja, wenn er sich nicht grade die XE7 Starter zulegt, sondern mindestens Professional, dann bekommt er die XE6 und Alles davor gratis dazu (bis runter zu D7) und hatte dann die große Auswahl.

... an CD's und DVD's im Regal :wink:

[mkinzler]

Nein, CDs/DVD gibt es ja schon lange nicht mehr. Man bekommt das Recht, ältere Versionen zu benutzen und kann diese herunterladen.

[Bambini]

Zitat:

Zitat von mkinzler (Beitrag 1274235)

Nein, CDs/DVD gibt es ja schon lange nicht mehr. Man bekommt das Recht, ältere Versionen zu benutzen und kann diese herunterladen.

Klar :lol:
Wenn man aber den Festplatten über die Jahre nicht ganz so traut, brennt man hin und wieder die *.iso auf die Silberlinge.
Obwohl die letzten Delphi ISO's auch nicht mehr auf normale DVD passen. Da muß jetzt Double Layer oder BlueRay ran.

[himitsu]

Bei mir ist es eher andersrum, nachdem die ersten gebrannten Sicherungskopien nicht mehr lesbar waren, landet das auf 2 ab und an gespiegelten Backupfestplatten.
Abgesehn davon, daß es sich von ISO schneller installieren läßt, als erst die CD/DVD rauszusuchen, dan noch das USB-DVD-Laufwerk zu finden und dann stundenlang beim Rattern zuzuhören.


Kurz nach dem Kauf kann man sich die Lizenzen der Vorgängerversionen freischalten lassen und dann mit jedem beliebigen Installationsmedium nutzen.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1274235)

Nein, CDs/DVD gibt es ja schon lange nicht mehr. Man bekommt das Recht, ältere Versionen zu benutzen und kann diese herunterladen.

Gibt's schon noch. Kosten auch "nur" 40 € :-)

[newbe]

davon mal ab kauf ich mir aber keine XE7 um dann mit irgendwelchen niedrigeren Versionen zu arbeiten, und später dann nochmal das schöne Procedere der Installation zu erleben.

mfg newbe

[kuba]

Zitat:

Zitat von newbe (Beitrag 1274244)

davon mal ab kauf ich mir aber keine XE7 um dann mit irgendwelchen niedrigeren Versionen zu arbeiten, und später dann nochmal das schöne Procedere der Installation zu erleben.

mfg newbe

Was machst du wenn du eine Komponente benötigst die noch nicht für XE7 zur Verfügung steht ??

kuba

[newbe]

Äpfel und Birnen? Is dat dein Ernst?

Btw. Ich nutze sehr wenige Fremdkomponenten. Und wenn ich sowas kaufe um zu Migrieren, stelle ich natürlich vorher sicher, das alles zu haben ist was ich dazu brauche.

mfg newbe

[kuba]

Ich habe hier immer noch zusätzlich eine ältere Delphi Version installiert, für den Fall der Fälle ...

In einigen Tagen vollziehe ich ebenfalls ein Upgrade von XE2 auf XE7. Zuvor hatte ich 2005, 2010 und XE im Einsatz. Bisher gefiel mir XE2 am besten und zwar wg. der Möglichkeit auch 64-Bit Anwendungen zu kompilieren. Der Grund für das Upgrade ist die angeblich letzte Möglichkeit upzugraden. Weiterhin interessiert mich brennend was sich in den letzten Jahren so getan hat, würde auch gern mal ein App in Umlauf bringen. So ein Upgrade ist ja schon recht teuer, da sich in den letzten Jahren vieles verändert hat muss es jetzt mal sein ...

kuba

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1274238)

Bei mir ist es eher andersrum, nachdem die ersten gebrannten Sicherungskopien nicht mehr lesbar waren, landet das auf 2 ab und an gespiegelten Backupfestplatten.

Das kommt dann aber auch sehr darauf an was man für Rohlinge gekauft hat. Bei mir sind noch die CDs mit meinen ersten Sicherungskopien aus meiner Schulzeit problemlos lesbar, genauso wie später dann die ersten DVDs.
Von anderen Rohlingen, die ich größtenteils von anderen bekommen habe, die diese bei Discountern oder in Schnäppchenaktionen gekauft haben, sind hingegen sehr viel weniger noch lesbar.

Da man Delphi aber ohnehin einfach wieder herunterladen kann, brenne ich die ISOs auch nicht.

[himitsu]

Dank der "Upgrade von jeder Vorgängerversion"-Aktionen ist der Kauf der neusten Version bestimmt günstiger, als der jetzige Kauf einer älteren Vorgänger-Vollversion.
Selbst wenn man also nicht "gleich" die aktuellste Version nutzt (die nächsten 5 Monate sind die Updates/Bugfixe noch kostenlos) ürfte es dennoch güstiger sein, als eine "neuere" alte Vollversion, außer er hat glück und bekommt auf dem Gebrauchtmarkt günstig eine Vollversion, bzw, eine uralte Vollversion inkl. aller aufbauenden Upgrades zu einer "neueren" Version.

Delphi-Preise verfallen irgendwie nicht so wirklich.
Selbt ein gebrauchtes Delphi 2005 Prof kann man für "nur" 800 € bekommen. (teurer, als XE7 und dann nut die alte Version nutzen, wobei man dann immernoch XE7 auch nutzen kann)

[Harry Stahl]

Generell gefällt mir XE7 sehr gut. Der Compiler ist m.E. einer der schnellsten bisher.

Was ich gerade schade finde, sind die immer wieder neuen Bugs von Version zu Version.

Nach stundenlanger Suche habe ich nun herausgefunden, dass jede TDateEdit, welches in einer Windows-FMX-Form liegt, ca. 300 Millisekunden für die Erzeugung braucht.

Bei 4 TDateEdit also ca. 1,2 Sekunden.

Unter XE6 war die Erzeugung nicht messbar.

Böser Bug!!:evil:

[Mavarik]

Zitat:

Zitat von RWarnecke (Beitrag 1273664)

Aus meiner Sicht, muss man bei solchen Crosscompilern immer Kompromisse eingehen. Ich will die Aussage nicht über einen Kamm scheren, aber mir wird zumindest seitens Emba diese Meinung deutlich vermittelt.

Also der neue Designer aus XE7 ist für mich auch überhaupt nicht zu gebrauchen. Ich habe mir aus Ermangelung eines solchen, unter XE5 schon einen Fenster/Frame Handler geschrieben, der eigentlich genau das macht... Device unabhängig meine Forms darstellen und zwar ohne Kompromisse auf allen Plattformen...

Und nein ich will gar nicht das es so aussieht wie alle Apps je nach Plattform unterschiedlich... Meine App soll wie meine App aussehen und zwar überall gleich... Also Premium-Style verwenden, anpassen und fertig.

Meine App sieht auf iOS, Android, Windows, MacOS immer gleich aus...
Ein Sourcecode!
Nur in meiner eigenen Mobilen-Helper-Unit sind die IFDEF's der Rest ist Plattform unabhängig...

XE6 war hier schon richtig gut. Aber an XE7 kommt man nicht vorbei, denn nur in XE7 sind die Bugs behoben. Außer denen die immer noch drin sind. ;-(

Zum Vergleich die erste compilierfähige Version für Android war auf meinem Nexus 10 so langsam, dass man nicht mit arbeiten konnte. Mit XE7 ist die Android App um ein vielfaches schneller als auf meinem iPad und immer noch schneller als auf meinem iPhone 5.

Es hat sich also einiges verändert...

Mavarik

[RWarnecke]

Meine Aussage mit den Kompromissen bezieht sich nicht nur auf das designen der GUI sondern auf alles. Für mich ist es immer noch ein Rätsel, wie ich API-Befehle von iOS entsprechend für Delphi umsetze. Bei XCode kann ich den API-Befehl entsprechend anwenden und funktioniert auf Anhieb. Das gleiche ist mit der Windows-API. Hier habe ich eine ähnliche Konstellation. Einfach im MSDN nachschauen, wie der Befehl aufgebaut ist und das ganze entsprechend nach Delphi übersetzen. Das nenne ich einfache und schnelle Entwicklung.

Die genannten Beispiele vermisse ich sehnlichst bei Firemonkey. Wenn ich erst hier und da etwas casten muss und dann noch irgendwo zwischen speichern oder sonst irgendwas machen muss, behindert mich das nur in meiner Arbeit. Ein gutes Beispiel ist die Komponente TLocationSensor. Dieser hat bei mir schon seit XE4 nicht richtig funktioniert. Ich habe lediglich nur die Ermittlung der Geo-Koordinaten von der Komponente abgezogen und den Rest selber berechnet und ausgewertet. Aber es ist ja nicht nur die Komponente, einfach das ganze Aussehen, die oft schon angesprochene Performance der Apps. Eine Delphi iOS App macht einfach nicht das her, was eine XCode App her macht. Das ist zumindest meine Meinung, nach jetzt 4 Versionen von Delphi, womit man iOS und Android Apps erstellen kann.

[kuba]

Zitat:

Zitat von Harry Stahl (Beitrag 1274275)

Generell gefällt mir XE7 sehr gut. Der Compiler ist m.E. einer der schnellsten bisher.

Was ich gerade schade finde, sind die immer wieder neuen Bugs von Version zu Version.

Nach stundenlanger Suche habe ich nun herausgefunden, dass jede TDateEdit, welches in einer Windows-FMX-Form liegt, ca. 300 Millisekunden für die Erzeugung braucht.

Bei 4 TDateEdit also ca. 1,2 Sekunden.

Unter XE6 war die Erzeugung nicht messbar.

Böser Bug!!:evil:

Das bringt mich gerade auf eine Idee, habe da so ein Problem die TDateEdit Komponente während des OnShow Event mit Werten aus der Regitry zu befüllen (XE2 kein FMX). Mit anderen Komponenten funktioniert alles reibungslos, nach meinen Tests spricht alles dafür dass die Komponente irgendwie nicht "bereit" ist den ausgelesenen Wert zu übernehmen. Wird die Komponente denn erst zur Laufzeit erzeugt ? Ich dachte das passiert schon zur "Entwicklungszeit" wenn die Komponente auf dem Formular plaziert wird. Das muss ich mir nochmal genauer anschauen und werde mal mit Hilfe eines Timers erst nach dem OnShow Event einlesen.

Habe gerade nochmal nachgeschaut, es sind 2 Komponenten TDateTimePicker und TSpinEdit ...

Ach sorry, aber ich glaube das Problem hängt nicht miteinander zusammen, war nur so eine Idee.

kuba

[jaenicke]

Zitat:

Zitat von kuba (Beitrag 1274393)

Das muss ich mir nochmal genauer anschauen und werde mal mit Hilfe eines Timers erst nach dem OnShow Event einlesen.

Besser ist dir im OnShow eine Message mit PostMessage zu schicken.
Damit brauchst du keinen Timer und hast dennoch den gleichen Effekt, du bekommst eine Windows Message. Denn der Timer funktioniert intern auch nur per Message WM_TIMER.

Zitat:

Zitat von kuba (Beitrag 1274393)

Habe gerade nochmal nachgeschaut, es sind 2 Komponenten TDateTimePicker und TSpinEdit ...

Beliebt sind da eigene Eventhandler, die beim Laden der Werte ablaufen. (OnChange, ...)

[jbg]

Zitat:

Zitat von Harry Stahl (Beitrag 1274275)

Bei 4 TDateEdit also ca. 1,2 Sekunden.

Unter XE6 war die Erzeugung nicht messbar.

Böser Bug!!:evil:

Das ist ein architektonischer Problem. Das hat man davon, wenn man aus allem und jedem ein Control machen muss. Für jeden Tag im Monat wird ein TTextControl erzeugt, was viel unnötigen Code mit sich bringt. Schon allein das Ausrichten der Controls wird verlangsamt. In diesem Fall ist es aber das Setzen der TTextControl.Text-Eigenschaft, da dort der Style geklont wird, was viel Zeit kostet, da zum Klonen das DFM-Streaming benutzt (missbraucht) wird. Und das DFM-Streaming ist seit der Umstellung von "IsStoredProp" auf Attribute (RichRTTI) noch um einiges langsamer geworden.
Zudem wird der Kalender für 1899 und das aktuelle Jahr aufgebaut, also doppelt.

[Harry Stahl]

Nachdem ich also nun ein mittelgroßes Projekt mit Delphi XE7 für den MAC fertig gestellt habe, muss ich sagen, dass ich es nur mit XE7 so schnell fertig stellen konnte. Denn die ganzen Modifikationen, die man machen muss, damit die Dialoge "MAC-Like" aussehen, das ging mit dem Multiview-Designer enorm viel einfacher, als der bisherige Weg, alles über IFDEFS lösen zu müssen.

Wer Interesse hat, kann sich ein paar Screenshots zum Programm hier ansehen: http://www.pc-rechnung.de

In Kürze wird noch ein Produktvideo folgen und ein kleines Video für Entwickler in meinem Firemonkey-Videoblog, das hier noch ein paar Erläuterungen geben wird.

Zusammenfassend kann man aber sagen, dass mit XE7 nun vieles einfacher geworden ist und der Compiler ist echt Hölle schnell.

[blondervolker]

Guten Abend,

also die zusätzlichen "Schnuckeleien" hätte man schon bei XE oder XE2 usw. reinbasteln können...
In Halle an der Saale wurde damals schon gesagt, dass noch weitaus "MEHR" dazu kommen wird.
Also warte ich noch weiter und vor allem länger ab.
Ich kauf mir auch nicht jedes Jahr eine "Neue Kutsche".
Blöder Vergleich... Aber ich fahre auch nur von A nach B...
Und "Fliegen" kann meine "Kutsche" immer noch nicht.:-D

Mehr wie "Lernen" kann man nicht...
Aber permanent neue "Versionen" heraus zu bringen, mit mehr und noch mehr, finde ich absoluten
Schwachsinn.Ist meine Meinung.:roll:
Die sind bis heute zu "Faul" die fetten"KÄFER" zu entfernen.
Und warum nicht?:pale:

Ich hab den Eindruck, dass der "Chef" von diesen laden noch schnell etwas für seine "Rente" tun will.:-D
Dann isser "wech".:-D
Unterm Strich sollte ich mal "Schauen" was ich meistens "Entwickle".
Und ein "Universal-Talent" von jeder Version zu sein, kann ich nicht behaupten.Und "Bock" jedesmal alles
zu lesen artet nicht in "Wissen" aus, sondern in ein "Durcheinander".
Denne renns`te nach permanent neuen Komponenten und wirst "ARM".(Arm dran oder Arm ab):-D


Die meisten Anwender sind doch schon "Froh", wenn die Tastatur im Vordergrund "GRINST".
Aber fehlerfreie Sätze zu bilden...verstehen selbst kaum die "Einheimischen".:P
Das einzige was gut ist, dass sich die neue Version nicht verbiegen kann.:stupid:

[schand99]

Zum Wiedereinstieg in die Pascal-Entwicklungsumgebung von Delphi 2006, damals noch von Borland, auf XE5 bzw. XE7 hatten mich die vielversprechenden Werbetexte von Embarcadero bewogen. Eine zum Großteil einheitliche Codebasis für verschiedene Plattformen klingt ja auch ziemlich verlockend.
Die Realität sieht dann leider etwas anders aus: vor allem Programme für Android-Geräte laufen mehr schlecht als recht. Abstürze (App reagiert nicht mehr, oder App wurde beendet) sind Regel und nicht Ausnahme. Würde mich nie trauen eine mit Delphi XE7 erstellte App in den Play-Store zu stellen.
Hoffe dass Embarcadero baldigst ein Update für die meiner Meinung nach nur halbfertige Entwicklungsumgebung bereitstellt.

[EWeiss]

Zitat:

Hoffe dass Embarcadero baldigst ein Update für die meiner Meinung nach nur halbfertige Entwicklungsumgebung bereitstellt.

Warum sollten die das tun?
Gibt doch bald XE8 was interessiert die dann noch das vergangene.
Kauf dir dann halt XE8 [Ironie]und alles ist gut.[/Ironie]


gruss

[Mavarik]

Zitat:

Zitat von schand99 (Beitrag 1292436)

Die Realität sieht dann leider etwas anders aus: vor allem Programme für Android-Geräte laufen mehr schlecht als recht. Abstürze (App reagiert nicht mehr, oder App wurde beendet) sind Regel und nicht Ausnahme. Würde mich nie trauen eine mit Delphi XE7 erstellte App in den Play-Store zu stellen.

FMX läuft "besser" auf iOS... Ist ja auch schon knapp 1 Jahr länger auf dem Markt als die Andoid Version...

Die ersten Versionen für Android waren nicht zu gebrauchen und von der "Performance" unbenutzbar. Das hat sich mit XE7 deutlich gewandelt.

Routinen die vorher auf iOS 10x schneller als auf Android waren, sind auf Android teilweise doppelt so schnell wie auf iOS... Besonders auf den mehrkern Android Geräten.

Aber die Fehler die Du beschreibst kann ich nicht - mehr - nachvollziehen.

Mavarik

[Harry Stahl]

Zitat:

Zitat von schand99 (Beitrag 1292436)

Die Realität sieht dann leider etwas anders aus: vor allem Programme für Android-Geräte laufen mehr schlecht als recht. Abstürze (App reagiert nicht mehr, oder App wurde beendet) sind Regel und nicht Ausnahme. Würde mich nie trauen eine mit Delphi XE7 erstellte App in den Play-Store zu stellen.

So ein Programmverhalten kann ich - wie auch Mavarick schon sagte - nicht bestätigen. Habe mein PC-Adreßzz! für Android seit XE5 im Angebot, es kam im Zeitraum 01.01.2014 bis heute auch nicht nur eine Kunden-Meldung hinsichtlich Programmabstürze oder sonstiger Probleme.

Lediglich jetzt mit Android 5 kamen Rückmeldungen (erst Nutzer von Google-Geräten, allmählich zieht aber auch Samsung mit einigen Geräten mit dem Update auf Lollipop nach), dass sich das Programm nach dem Update auf Android 5 nicht mehr starten lässt.

Aber das ist letztlich bedingt durch Änderungen in Android 5 selbst, EMBA hat dafür schon einen Fix für XE7 geliefert, der das Problem behoben hat.

Bei der Entwicklung von mobilen Anwendungen ist einiges schlichtweg anders und führt zu Fehlern, wenn man das nicht berücksichtigt. Z.B. sind Strings in mobilen Anwendungen Index-0 basiert, sonst sind sie ja Index-1-basiert. Wenn man da entsprechende falsche Operationen macht, dann kann man sein Programm auch schon mal abschießen. Das liegt dann aber nicht an Delphi, sondern am Entwickler.;-)

Hier ein paar Tipps, was z.B. beim migrieren von Desktop-Apps zu mobilen Apps berücksichtigen muss: http://docwiki.embarcadero.com/RADSt...om_Desktop_aus

[bernhard_LA]

mein Arbeitsalltag und die persönliche Bewertung sieht wie folgt aus

1. Microsoft SharePoint
   

   Bewertung : div. Bugs und man ist als User ziemlich eingeschränkt in seinen Möglichkeiten, Verwendung dieser SW nervt mich ...

2. Microsoft Visual C++ 2005
   
   

   Bewertung : gibt bei uns einige nicht gelöste Performance Probleme (XML Datei Verarbeitung) in unserer Anwendung, Workarounds über Delphi DLLs , Compiler Note 3

   
   
3. Microsoft SQL Server
   

   Bewertung : Lizenzen kosten einen Vermögen in meinem Projekt, wegen diverse Rahmenbedingungen müssen wir aber dem Server treu bleiben, Note 3
   Auch ADO gehört zu unseren Rahmenbedingungen, die Flexibilität von ZEOS ( http://sourceforge.net/projects/zeoslib/ ) fand ich persönlich eigentlich besser
   

4. Microsoft Lync
   

   Bewertung : div. crashes .... macht mich wahnsinnig, jedes Meeting ein Abenteuer für sich! Note 4-

5. EMBA Delphi XE 2
   

   Bewertung : täglich viele Stunden im Einsatz, für uns als Anwendungsentwickler für Desktop , absolut OK ; Note 2 -
   

6. EMBA Delphi XE3-X7
   

   Bewertung : Cross Plattform ist definitiv besser geworden, leider kein Bedarf bei unseren Kunden für iOS oder Android ; Note 2
   

7. LAZARUS
   

   ein paar kleinere Themen für UNIX erstellt, als Free Ware eine super Sache, deshalb auch die Note 2

   ttp://www.lazarus-ide.org/
   
   was mich wirklich stört
   

   ich will mit Lazarus eine Open Source Pascal alternative haben, Second Source für den Compiler ist absolut notwendig !
   Mit Focus auf Desktop-SW Entwicklung ist UNIX für uns ein wichtiges Thema , will ich auch endlich haben !
   Wir haben auch immer RAD (Delphi + C++) gekauft, wichtig ist ein besserer Link C++ / Delphi und bei C++ und die Verwendung von Bibliotheken wie Boost oder gcc Compiler material
   Cool wäre die Unterstützung einer Mixed Language Programmierung in C++ und Delphi, ich mache ein neues C++ projekt auf und kann Delphi Units einbinden als ob Sie in C++ geschrieben wären, der Compiler soll sich um die Details / Interfaces... kümmern