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 Delphi-Referenz durchsuchen

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 von 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)

Du wirst schon wissen was Du meinst.

Zitat von himitsu:

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)