Delphi XE6 im Anmarsch

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1256076)

Zitat:

Zitat von Uwe Raabe (Beitrag 1256074)

Beschränkt man wiederum den Zeitraum auf letztes Jahr, steht "Delphi XE5 and C++Builder XE5 ISO (Includes Update 2)" an der Spitze.

Interessant ist auch, daß sich grade erst wieder jemand ein Turbo Pascal 5.5 besorgt hat. :lol:

Ja, das ist ein Klassiker. Ich muss zugeben, daß ich das auch vor ein paar Monaten mal runtergeladen habe, weil ich zu faul war, die Disketten zu suchen.

Übrigens: "Show top 10 downloads for Delphi for the period: Past Year" 8-)

[Chemiker]

Hallo,

lohnt sich das Update für normale Windows-VCL-Entwickler von Delphi XE5 auf Delphi XE6? Warum ist das Update eigentlich so früh dieses Mal, sonst kam das Update doch immer erst im September?

Bis bald Chemiker

[Uwe Raabe]

Zitat:

Zitat von Chemiker (Beitrag 1256079)

lohnt sich das Update für normale Windows-VCL-Entwickler von Delphi XE5 auf Delphi XE6?

Meine Meinung: Ja!

Zitat:

Zitat von Chemiker (Beitrag 1256079)

Warum ist das Update eigentlich so früh dieses Mal, sonst kam das Update doch immer erst im September?

Hast du letztes Jahr verpennt? In 2013 gab es XE4 und XE5 und die Roadmap für 2014 avisiert ein (vermutlich) XE7 für diesen Herbst.

[Chemiker]

Hallo,

Zitat:

Hast du letztes Jahr verpennt? In 2013 gab es XE4 und XE5 und die Roadmap für 2014 avisiert ein (vermutlich) XE7 für diesen Herbst.

Oh sorry, habe ich jetzt nicht mitbekommen war jetzt eine Zeitlang mehr mit VS C++ beschäftigt.

Das bedeutet jetzt, dass man jedes halbe Jahr eine neue Version mit den ganzen gekauften und freien Komponenten neu installieren muss!

Bis bald Chemiker

[himitsu]

Ja.

(kann)

[Union]

Zitat:

Zitat von Chemiker (Beitrag 1256081)

Hallo,

Zitat:

Hast du letztes Jahr verpennt? In 2013 gab es XE4 und XE5 und die Roadmap für 2014 avisiert ein (vermutlich) XE7 für diesen Herbst.

Oh sorry, habe ich jetzt nicht mitbekommen war jetzt eine Zeitlang mehr mit VS C++ beschäftigt.

Das bedeutet jetzt, dass man jedes halbe Jahr eine neue Version mit den ganzen gekauften und freien Komponenten neu installieren muss!

Bis bald Chemiker

Naja, und früher hat man sich beschwert dass Unicode und x64 erst spät kamen. Jetzt ist halt auch der Innovationszyklus schneller. Und die paar Komponentenhersteller die's noch gibt müssen eben ein paar defines anpassen, wenn überhaupt.

[jaenicke]

Zitat:

Zitat von Union (Beitrag 1256083)

Und die paar Komponentenhersteller die's noch gibt müssen eben ein paar defines anpassen, wenn überhaupt.

Seit with aus vielen Quelltexten herausgeflogen ist, gibt es ohnehin viel weniger Migrationsprobleme. Viele notwendige Änderungen und (teils erst später erkannte) Fehler waren in der Vergangenheit ja nur darauf zurückzuführen.

[himitsu]

Zitat:

Zitat von Union (Beitrag 1256083)

Naja, und früher hat man sich beschwert dass Unicode und x64 erst spät kamen.

Meinst du das wäre schneller fertig geworden, wenn man zwischendrin noch zusätzliche (stabile) Versionen erfinden muß?
Und wenn, dann wären sie auch nur ein halbes Jahr früher gekommen.

[Union]

Zitat:

Zitat von himitsu (Beitrag 1256087)

Meinst du das wäre schneller fertig geworden, wenn man zwischendrin noch zusätzliche (stabile) Versionen erfinden muß?
Und wenn, dann wären sie auch nur ein halbes Jahr früher gekommen.

Mit der heutigen Herangehensweise tatsächlich. iOS und Android kam relativ schnell hintereinander und sind tatsächlich auch ziemlich gut zu gebrauchen.

[Uwe Raabe]

Zitat:

Zitat von Union (Beitrag 1256083)

Und die paar Komponentenhersteller die's noch gibt müssen eben ein paar defines anpassen, wenn überhaupt.

Wenn man das einmal geschickt anfängt, ist es i.A. kein Problem. Ich codiere immer gegen den neuesten Compiler (nicht zwingend die neuesten Features), so daß es damit ohne IFDEFs funktioniert. Die Kompatibilität zu den älteren Versionen fange ich dann durch

Delphi-Quellcode:

{$IF CompilerVersion < xx.x}

oder (meistens zutreffender)

Delphi-Quellcode:

{$IF RTLVersion < xx.x }

ab. Wenn das zu umständlich wird, fliegt der Support für die alte Version raus. Wer das unbedingt braucht, kann ja die alten Sourcen weiter verwenden - auch Abwärtskompatibilität hat Grenzen.

Neuere Versionen sind so häufig ohne Änderungen lauffähig.

[Union]

Wobei ich manchmal den Eindruck habe, dass einige der Hersteller absichtlich komplexe ifdef Verschachtelungen, includes etc, einbauen, damit der gemeine Delphi-Programmierer zu einem Update gezwungen werden kann.

[himitsu]

Seit 13 Jahren gibt es die Conditional-Expressions und das CompilerVersion. Das sollte für die Abwärtskompatibilität ausreichen. (bis Delphi 6 runter)

Da kann man sich wirklich wundern, warum noch so viele IFDEF VERxxx-Include-Monster existieren. :stupid:

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1256091)

(bis Delphi 6 runter)

Mit CompilerVersion in Delphi 6 habe ich mich grade erst verbrannt. Man sollte meinen es wäre CompilerVersion = 14.0. Aber nein, es war tatsächlich "14.01". Irgendein Update hat da wohl die 0.01 eingeschmuggelt oder meine dcc32.exe ist defekt.

Und man sollte nicht vergessen, dass ErrorInsight so seine Probleme mit CompilerVersion bei $IF bis einschließlich Delphi 2009 hatte. Anstatt des Gleitkommawerts wurde die Speicheradresse von CompilerVersion für die Vergleiche herangezogen.

[himitsu]

:shock: Die 5 und 6 hatte ich übersprungen und in D7 da kann ich mich an keine Probleme erinnern. (oder der Code lief zufällig)

Und ErrorInsigt musste man damals eh deaktivieren, weil dort ja alles falsch angezeigt wurde.

[jaenicke]

Übrigens bezüglich der Qualitätsverbesserungen... hier eine Perle dazu:
http://qc.embarcadero.com/wc/qcmain.aspx?d=8008
Man sieht ja wie niedrig die QC Nummer ist. Der Eintrag ist von 2004... gelöst mit XE6.

[himitsu]

Na sooooo alt ist das doch garnicht, denn schließlich ist das nur ein Duplicate of 89553 :zwinker:

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1256195)

Na sooooo alt ist das doch garnicht, denn schließlich ist das nur ein Duplicate of 89553 :zwinker:

Find ich auch witzig, normalerweise markier ich immer nachfolgende Tickets als Duplicate des ersten und nicht umgekehrt - aber so kann man auch den Anschein erwecken, als ob der gefixte Bug (89553) noch gar nicht sooo lange existiert ;)

[jaenicke]

Zitat:

Zitat von Stevie (Beitrag 1256226)

Find ich auch witzig, normalerweise markier ich immer nachfolgende Tickets als Duplicate des ersten und nicht umgekehrt - aber so kann man auch den Anschein erwecken, als ob der gefixte Bug (89553) noch gar nicht sooo lange existiert ;)

Bei einem meiner Tickets wurde auch das ältere Ticket als Duplikat markiert, das ich als Duplikat mit angegeben hatte.
Das lag in solchen Fällen daran, dass das ältere nicht vollständig oder nicht gut beschrieben war.

[Insider2004]

Die ersten XE6-Ostereier-Bugs sind schon da!

http://qc.embarcadero.com/wc/qcmain....0.0.15596.9843

Frohe Ostern!

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1256283)

Die ersten XE6-Ostereier-Bugs sind schon da!

http://qc.embarcadero.com/wc/qcmain....0.0.15596.9843

Frohe Ostern!

Das sind aber nicht alles "Bugs" (bzw. neue) die hier gemeldet wurden:

http://qc.embarcadero.com/wc/qcmain.aspx?d=124181: Userfehler - Hat abgelaufene Zertifikate verwendet
http://qc.embarcadero.com/wc/qcmain.aspx?d=124167: Property ist jetzt protected. Vermutlich sinnvolle Änderung da eine Property das nicht immer sinnvoll ist schon auf dieser Ebene zu haben.
http://qc.embarcadero.com/wc/qcmain.aspx?d=124162: Feature gibt und gab es bisher nicht.
http://qc.embarcadero.com/wc/qcmain.aspx?d=124143: Wunsch einen Funktionsaufruf inlinefähig zu gestalten
http://qc.embarcadero.com/wc/qcmain.aspx?d=124119: Unsere bekannte False-Positive Virusmeldung
http://qc.embarcadero.com/wc/qcmain.aspx?d=124115: "Auffrischen" eines alten XE-Bugs. Könnte also gleich als Duplikat geschlossen werden

[jaenicke]

Du hast die Doppelpunkte in der URL, so dass die Links alle nicht direkt gehen. ;-)

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1256296)

Du hast die Doppelpunkte in der URL, so dass die Links alle nicht direkt gehen. ;-)

Habs jetzt End-Doppelpunkted :-)

[Stevie]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1256287)

http://qc.embarcadero.com/wc/qcmain.aspx?d=124167: Property ist jetzt protected. Vermutlich sinnvolle Änderung da eine Property das nicht immer sinnvoll ist schon auf dieser Ebene zu haben.

Sinnvoll oder nicht - wenn etwas public war, dann sollte es auch public bleiben.
Der Report zeigt sogar ein Beispiel, wo diese Properties gebraucht würden.

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1256322)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1256287)

http://qc.embarcadero.com/wc/qcmain.aspx?d=124167: Property ist jetzt protected. Vermutlich sinnvolle Änderung da eine Property das nicht immer sinnvoll ist schon auf dieser Ebene zu haben.

Sinnvoll oder nicht - wenn etwas public war, dann sollte es auch public bleiben.

Sollt ok. Wenn aber etwas dafür spricht sollte man aber auch APIs ändern können/dürfen um z.B. Designfehler zu korrigieren oder die API schlanker und verständlicher zu machen.

Zitat:

Zitat von Stevie (Beitrag 1256322)

Der Report zeigt sogar ein Beispiel, wo diese Properties gebraucht würden.

Die eigentliche Funktionalität kann man aber auch andersweiter nachbauen. Z.B. per RTTI.

[Sir Rufo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1256324)

Zitat:

Zitat von Stevie (Beitrag 1256322)

Der Report zeigt sogar ein Beispiel, wo diese Properties gebraucht würden.

Die eigentliche Funktionalität kann man aber auch andersweiter nachbauen. Z.B. per RTTI.

Erinnert mich so an den Spruch "Mann oder Memme?"

Ich stehe nicht auf Schmerzen und was nicht sein muß kann man auch unterlassen ;)

[himitsu]

Die sind doch nur Protected?
Und da kommt man auch ganz leicht ohne RTTI ran.

[Sir Rufo]

Zitat:

Zitat von himitsu (Beitrag 1256330)

Die sind doch nur Protected?
Und da kommt man auch ganz leicht ohne RTTI ran.

Es kommt doch nicht darauf an, ob es nun leicht oder schwer ist, es soll so einfach wie möglich sein (

Delphi-Quellcode:

public

oder

Delphi-Quellcode:

published

).

Mit der Argumentation könnten ja dann alle Eigenschaften

Delphi-Quellcode:

protected

sein, ist doch ganz leicht, sogar ohne RTTI.

Wenn es sinnvoll ist, dass die Eigenschaft FMX.Controls.TControl.Scale nun protected ist, dann würde mich dieser sinnhafte Grund aber durchaus interessieren.

Und die Beschreibung unter http://docwiki.embarcadero.com/Libra...trols.TControl ist immer noch analog zu XE5

Zitat:

TControl ist die Basisklasse für FMX-Bildschirmkomponenten. Unterklassen werden grob in Grundformen und über Stile anpassbare Steuerelemente eingeteilt.
TControl erweitert TFmxObject zur Bereitstellung von sichtbaren Objekten durch Hinzufügen von Eigenschaften und Methoden für:

• Größe und Position
  • Ränder und Auffüllung
  • Ausrichtung mit anderen
• Sichtbarkeit, Opazität, Skalierung und Drehung
• Mausinteraktion und Treffertest
• Tastaturinteraktion
  • Fokus und Tabulatorreihenfolge
• Auslöser für Animationen und Effekte
• Zeichnen

[Bernhard Geyer]

Zitat:

Zitat von Sir Rufo (Beitrag 1256329)

Erinnert mich so an den Spruch "Mann oder Memme?"

Memme - Aber was für welche :stupid:

Zitat:

Zitat von Sir Rufo (Beitrag 1256329)

Ich stehe nicht auf Schmerzen und was nicht sein muß kann man auch unterlassen ;)

Wir wissen nicht wieso das gemacht wurde. Meine Vermutung habe ich ja geschrieben.
Aber bevor jetzt die Diskussion ausartet wessen Glaskugel defekt ist oder funktioniert habe ich einfach mal im Forum die W-Frage gestellt: https://forums.embarcadero.com/threa...hreadID=103677

[Satyr]

Hat es eigentlich schon wer geschafft das SG5 mit XE6 zu connecten? Ich weiß, ist recht neu. Aber in XE5 bekomme ich problemlos eine Verbindung. Die XE6 Testversion erkennt es nicht.

[jaenicke]

Was sagt denn der Befehl "adb devices" der Android SDK Version, die in XE6 eingestellt ist? (Kannst du auf der Kommandozeile ausführen.)

[Satyr]

Äh... da weiß ich jetzt nicht konkret was gemeint ist, ehrlich gesagt... verändert habe ich beim SDK nichts. XE5 lief auch ohne Änderung.

[jaenicke]

Du findest das SDK vermutlich unter:

Code:

C:\Users\Public\Documents\RAD Studio\14.0\PlatformSDKs\adt-bundle-windows-x86-[...]\sdk\platform-tools

(was bei den Punkten bei XE6 steht kann ich grad nicht schauen)
Dort kannst du den Befehl ausführen um zu schauen, ob das Android SDK an sich das Gerät erkennt.

[Satyr]

Also unter XE6 war der Pfad jetzt C:\Users\Public\Documents\Embarcadero\Studio\14.0\ PlatformSDKs\adt-bundle-windows-x86-20131030\sdk\platform-tools wenn ich das richtig sehe.
Der Befehl dort ausgeführt zeigt nur "List of devices attached", mehr nicht. Das Handy wird von Windows (Win8.1) aber problemlos erkannt, es ist eingesteckt.

[Union]

Hast Du den Google USB driver in diesem SDK mit dem SDKManager installiert bzw. aktiviert?

[Satyr]

Wie das? Ich habe in Windows die Samsung USB Treiber installiert.
Sorry wenn meine Fragen blöd sind, ich bin bisher gewohnt das es "so" funktioniert...

[jaenicke]

Klar ist, da die adb.exe das Gerät schon nicht findet, dass das Problem schon im SDK besteht, nicht in Delphi.

Wie sieht das Handy denn im Gerätemanager aus, also wie heißt dort der Eintrag?

[Satyr]

Also, es taucht mehrfach auf. Einmal mit eigenem Eintrag im Geräte-Manager "Samsung Android Phone" welcher das Child "SAMSUNG Android ADB Interface" hat. Unter "Modems" ist der Child "SAMSUNG Mobile USB Modem", unter "Tragbare Geräte" findet man "Galaxy S5" und unter USB-Controller findet sich der Eintrag "SAMSUNG Mobile USB Composite Device".
Im Explorer ist das Galaxy S5 als Laufwerk zu finden.

[sh17]

Am Handy auch alles eingestellt in den Entwickleroptionen?

[Satyr]

Japp. Wie gesagt, XE5 erkennt es problemlos. Nur die Testversion von XE6 nicht.

[sh17]

Geht nicht eigentlich immer nur ein ADB-Server? Wenn der von XE5 bereits aktiv ist, gibts es vielleicht Probleme mit dem aus dem SDK von XE6.