Zu- und Unzufriedenheit mit Delphiqualität sowie Preis- und Lizenzpolitik

[himitsu]

Zitat:

Alle halbe Jahre MUSS ich wieder ein neues Delphi installieren, sonst geht es mit Android xyz oder Apple abc Release def nicht mehr

Bei anderen Entwicklungsumgebungen reicht es ja oftmals, einfach nur das neue SDK runter und eventuell ein kostenloses Update runter zu laden, aber Emba hat wohl einfach zu viel fest integriert und keine Ambitionen die nötigen Dinge unabhängig auch für alte Delphi-Versionen bereitzustellen?

Das Problem/Vorteil bei Delphi/Studio ist halt, dass das alles "eigenständige" Programme und keine Programmversionen sind.
Du updatest halt nicht dein Delphi, sondern installierst ein neues Programm.

Gut, man hat dann zwar "paralell" auch die Möglichkeit ältere RTL/VCL/Komponenten-Versionen installiert zu haben,
aber bei den Compilerversionen gäbe es da doch auch die Möglichkeit "alte" Compiler im selben Delphi zu haben, also nicht nur
Win32 Win64 iOS iOS64 Android als Ziele, sondern Win32v1 Win32v2 Win32v3 Win64x1 ...

Wenn es Delphi wirklich nur als "Update" gäbe, dann hätte man immer nur die jeweils größte Version installiert und das Alte "überschrieben".

Zitat:

Zitat von Delphi-Laie (Beitrag 1339322)

Denjenigen, der das vorschlug, und diejenigen, die das genehmigten, sollten mit der Frage konfrontiert werden, ob ihr Unternehmen ein Kindergarten ist.

Brennende Tiere sind eben voll der Hit, seit vielen Jahren, auch wenn Codegear/Embarcadero da immer paar Jahrzehnte hinterher hinkt, hinter aktuelleren Trends.

Linux 1983 -> XE10.? 201?
NT 1993 -> D 2009 (Unicode)
XP 2001 -> XE 2011 (der Name?)
2000/XP -> XE2 2011 (64 Bit)
Android 2008 -> XE5 2013
iOS 2007 -> XE2 2011

Na gut, zumindestens werden die Zeiten immer kürzer, auch wenn sie wohl nie das halbe Jahr schaffen, um ein neues Feature/System/Funktion zu einzubauen. :angle:

[greenmile]

Zitat:

Zitat von himitsu (Beitrag 1339345)

Bei anderen Entwicklungsumgebungen reicht es ja oftmals, einfach nur das neue SDK runter und eventuell ein kostenloses Update runter zu laden, aber Emba hat wohl einfach zu viel fest integriert und keine Ambitionen die nötigen Dinge unabhängig auch für alte Delphi-Versionen bereitzustellen?

Das normale Update für vorherige Versionen würde mir ja schon reichen. Es wurden Updates für Subscription versprochen, aber was bitte kam für XE8? Für XE10 Seattle? Aus dem Auge, aus dem Sinn. Und nun soll mir keiner kommen von wegen ist doppelte Programmierung, muss immer in 2 Sourcen geändert werden oder so. Muss ich ja auch bei meinen Programmen machen. Ich bin schon einige Zeit sauer, aber so langsam angepi**t. Ich habe mit der Android App einige Probleme und hatte gehofft, dass die in Berlin behoben sind. Man erfährt aber in der Changes List kaum was interessantes. Also habe ich Berlin installiert und getestet. Ob die Fehler behoben sind kann ich nicht sagen, weil jetzt andere Sachen plötzlich nicht mehr funktionieren wie z.B. 2 Multiview (eins links, eins rechts) mit Ownerdraw massiv Probleme machen, was in Seattle lief. Also hätte ich definitiv mehr Probleme als vorher. Hatte auf ein Update von Seattle gehofft, aber da tut sich nichts. Ist doch scheiße. Wenn ich die mobilen Sachen nicht bräuchte, wäre die Subscription schon längst gekündigt.

[bra]

Die ständigen neuen Versionen nerven mich aber auch. Zumal mit jeder neuen Version neue Bugs dazu kommen und man erstmal tage- oder wochenlang rumbasteln muss, bis unsere App wieder läuft. Wir warten inzwischen bis zum ersten Update jeder Version, vorher ist die eh nicht zu gebrauchen. :evil:

[greenmile]

:thumb:

[Uwe Raabe]

Zitat:

Zitat von bra (Beitrag 1339351)

Wir warten inzwischen bis zum ersten Update jeder Version, vorher ist die eh nicht zu gebrauchen.

Das ist auch meine Empfehlung. Das Release-Datum einer neuen Version wird im Wesentlichen vom Marketing bestimmt, während das erste Update eher vom Produktmanagement gesteuert wird.

[Der schöne Günther]

Dann bin ich ja nicht alleine mit der Arbeitsweise.

Grade erst den Umzug auf Seattle gemacht, mit Berlin wird teilweise etwas gespielt.

[TRomano]

Im VCL Bereich ist der Umstieg auch meist wesentlich leichter (da passiert in den letzten Versionen auch nicht so viel), deswegen konnte ich ein Projekt (> 25.000 Zeilen) beim ersten Compilieren "hochhieven". Noch schnell TBufferedStream (neu bzw. aus FireDAC) in zwei Classes "eingetauscht" und schon läuft das Projekt in 10.1 Berlin (von Seattle). Bisher kamen auch noch keine Beschwerden ...
Man muss meist bloß die Komponenten-Hersteller abwarten, aber da ich nichts Exotisches benutze ist das meist auch schnell von denen erledigt ...

[jaenicke]

Das größte Problem ist finde ich die Packageverwaltung. Eigentlich unterscheiden sich die Packages alle nicht, aber trotzdem muss ich die alle für jede Version einzeln kopieren, weil es immer noch keine Möglichkeit gibt Einstellungen in der Projektdatei versionsbezogen zu setzen...

Deshalb ist das aktuell der größte Aufwand. Alles andere hielt sich (auch in den FMX Projekten, eines davon mit mehr als 1mio Zeilen) sehr in Grenzen.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1339384)

Das größte Problem ist finde ich die Packageverwaltung. Eigentlich unterscheiden sich die Packages alle nicht, aber trotzdem muss ich die alle für jede Version einzeln kopieren, weil es immer noch keine Möglichkeit gibt Einstellungen in der Projektdatei versionsbezogen zu setzen...

Bei diesem Post schlug mein Keyword-Trigger an 8-)

So ganz habe ich dein Problem nicht verstanden. Kannst du das etwas genauer beschrieben? Gerne auch als PM um den Thread hier nicht zu verunreinigen.

[sh17]

Zitat:

Zitat von Uwe Raabe (Beitrag 1339387)

Zitat:

Zitat von jaenicke (Beitrag 1339384)

Das größte Problem ist finde ich die Packageverwaltung. Eigentlich unterscheiden sich die Packages alle nicht, aber trotzdem muss ich die alle für jede Version einzeln kopieren, weil es immer noch keine Möglichkeit gibt Einstellungen in der Projektdatei versionsbezogen zu setzen...

Bei diesem Post schlug mein Keyword-Trigger an 8-)

So ganz habe ich dein Problem nicht verstanden. Kannst du das etwas genauer beschrieben? Gerne auch als PM um den Thread hier nicht zu verunreinigen.

Er meint sicher, das für jede neue Delphi-Version ein neues Package der Komponente erstellt werden muss. Hat, denke ich, nichts mit Deinem neuen Projekt zu tun :)

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1339384)

Das größte Problem ist finde ich die Packageverwaltung. Eigentlich unterscheiden sich die Packages alle nicht, aber trotzdem muss ich die alle für jede Version einzeln kopieren, weil es immer noch keine Möglichkeit gibt Einstellungen in der Projektdatei versionsbezogen zu setzen...

Indirekt schon. Wenn am Ende der BPL die Compilerversion steht, dann kann man die in der Projektverwaltung weg lassen.
Beispiel: VCL240.bpl und Abhängigkeit "VCL"

Ansonsten ja, man braucht für jeden neue Compiler-Version eine eigene BPL, falls man die BPLs nicht über die Projektverwaltung kompilieren lassen kann. (Package-Projekte in Projektgruppe).
Das liegt aber daran, dass die Packages einmal eine Versionsprüfung haben und da die RTTI verlinkt ist und da sich sowieso bei jeder RTL/VCL/FMX/Delphi-Version irgendwas an den Schnittstellen ändert.
Bei DLLs dagegen sind die Schnittstellen "unabhängig" und ändern sich nicht ständig. (außer jetzt bei 32<>64 Bit und Unicode, wenn der Entwickler da Mist gebaut hat)

[Bambini]

Zitat:

Zitat von Uwe Raabe (Beitrag 1339387)

Zitat:

Zitat von jaenicke (Beitrag 1339384)

Das größte Problem ist finde ich die Packageverwaltung. Eigentlich unterscheiden sich die Packages alle nicht, aber trotzdem muss ich die alle für jede Version einzeln kopieren, weil es immer noch keine Möglichkeit gibt Einstellungen in der Projektdatei versionsbezogen zu setzen...

Bei diesem Post schlug mein Keyword-Trigger an 8-)

So ganz habe ich dein Problem nicht verstanden. Kannst du das etwas genauer beschrieben? Gerne auch als PM um den Thread hier nicht zu verunreinigen.

Sofern man die alten Delphi Versionen auch auch der Maschine hat und diese nutzt, müssen sich die Packagenamen unterscheiden.
Eine package1.bpl für Seattle muss unter Berlin anders heißen, da der bpl Path von beiden Delphi Versionen genutzt wird. Compiliert man das Package1.bpl mit Berlin unter dem gleichen Namen gehts nicht mehr unter Seattle und vice versa. Das wäre kein größer Heck Meck, aber wenn Packages andere Packages verwenden wir es aufwendig.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1339396)

Indirekt schon. Wenn am Ende der BPL die Compilerversion steht, dann kann man die in der Projektverwaltung weg lassen.

Genau! Der Package Magician soll ja in Zukunft noch weitere Features bekommen...

[Uwe Raabe]

Zitat:

Zitat von Bambini (Beitrag 1339398)

Sofern man die alten Delphi Versionen auch auch der Maschine hat und diese nutzt, müssen sich die Packagenamen unterscheiden.
Eine package1.bpl für Seattle muss unter Berlin anders heißen, da der bpl Path von beiden Delphi Versionen genutzt wird. Compiliert man das Package1.bpl mit Berlin unter dem gleichen Namen gehts nicht mehr unter Seattle und vice versa. Das wäre kein größer Heck Meck, aber wenn Packages andere Packages verwenden wir es aufwendig.

Genau dafür gibt es ja bei den Packages den LIBSUFFIX. Damit kann der Packagename (dproj und dpk) versionsneutral bleiben, während die bpl den LIBSUFFIX dran hängen hat. Leider gibt es in Delphi bisher keine Möglichkeit, den LIBSUFFIX automatisch vergeben zu können. {$LIBSUFFIX AUTO} for packages

[Bambini]

Zitat:

Zitat von Uwe Raabe (Beitrag 1339401)

Zitat:

Zitat von Bambini (Beitrag 1339398)

Sofern man die alten Delphi Versionen auch auch der Maschine hat und diese nutzt, müssen sich die Packagenamen unterscheiden.
Eine package1.bpl für Seattle muss unter Berlin anders heißen, da der bpl Path von beiden Delphi Versionen genutzt wird. Compiliert man das Package1.bpl mit Berlin unter dem gleichen Namen gehts nicht mehr unter Seattle und vice versa. Das wäre kein größer Heck Meck, aber wenn Packages andere Packages verwenden wir es aufwendig.

Genau dafür gibt es ja bei den Packages den LIBSUFFIX. Damit kann der Packagename (dproj und dpk) versionsneutral bleiben, während die bpl den LIBSUFFIX dran hängen hat. Leider gibt es in Delphi bisher keine Möglichkeit, den LIBSUFFIX automatisch vergeben zu können. {$LIBSUFFIX AUTO} for packages

Wie können anhängige Packages dann das passende Package finden? Gibt es da eine Trick für den

Delphi-Quellcode:

requires

Bereich?

[Uwe Raabe]

Zitat:

Zitat von Bambini (Beitrag 1339402)

Wie können anhängige Packages dann das passende Package finden? Gibt es da eine Trick für den

Delphi-Quellcode:

requires

Bereich?

Trick ist gut :-D

Schau mal in die Requires-Clause eines beliebigen Packages. Dort findest du vielleicht sowas wie RTL oder VCL. Damit werden die DCP-Dateien referenziert. Innerhalb der DCP ist dann der tatsächliche Name der BPL versteckt, der natürlich für jede Delphi-Version unterschiedlich lautet (z.B. RTL240.bpl oder VCL240.bpl für Berlin). Ich glaube, Delphi 5 war die letzte Version, die das noch nicht konnte.

Nehmen wir mal unsere eigenen Packages PkgA und PkgB, wobei PkgA in der Requires-Clause von PkgB steht. Bei beiden Packages setzen wir jetzt den LIBSUFFIX auf 240 (für Berlin). Compilieren wir nun beide Packages werden die Dateien PkgA.dcp, PkgA240.bpl und PkgB.dcp und PkgB240.bpl erzeugt.

Jetzt kommt irgendwann Delphi Tokyo heraus. Dann ändern wir bei beiden Packages lediglich den LIBSUFFIX auf 250 und compilieren neu. Da die Requires-Clause in PkgB immer noch nur PkgA enthält, ändert sich an der DPK-Datei nur der LIBSUFFIX (wird von der IDE erledigt). Natürlich muss ich zum PkgB250.bpl das passende PkgA250.bpl ausliefern, aber deswegen muss ich das Package-Projekt nicht extra umbenennen.

Es wäre natürlich schön, wenn man für dieses LIBSUFFIX sowas wie $(AUTO) eintragen könnte, was dann immer den passenden Wert zurückliefert. Leider funktionieren alle bisherigen Ansätze dafür nicht. Deswegen der QP-Eintrag.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1339400)

Genau! Der Package Magician soll ja in Zukunft noch weitere Features bekommen...

Gut wäre ja, wenn man die Projektversionsnummer vom Compiler einbauen lassen könnte und nicht für jede Compilerversion ein eigenes Projekt bauen müsste,
oder nachträglich im AfterCompile das umbenennt, was beim Debuggen bissl Probleme bereiten tut.

Zitat:

Zitat von Bambini (Beitrag 1339402)

Zitat:

Zitat von Uwe Raabe (Beitrag 1339401)

Genau dafür gibt es ja bei den Packages den LIBSUFFIX. Damit kann der Packagename (dproj und dpk) versionsneutral bleiben, während die bpl den LIBSUFFIX dran hängen hat. Leider gibt es in Delphi bisher keine Möglichkeit, den LIBSUFFIX automatisch vergeben zu können. {$LIBSUFFIX AUTO} for packages

Wie können anhängige Packages dann das passende Package finden? Gibt es da eine Trick für den

Delphi-Quellcode:

requires

Bereich?

Wie gesagt, wenn deine BPL Name{versionsnummer}.bpl heißt, dann gibst du bei require nur den Name an, ohne die Nummer.
siehe die Delphi-Packages Vcl123.bpl -> requires "Vcl"

[himitsu]

{$SOPREFIX ''}
{$LIBPREFIX ''}
{$LIBSUFFIX '240'}
{$LIBVERSION ''}
{$EXTENSION 'bpl'}

<Basisname>.dcp
<LibPrefix><Basisname><LibSuffix>.<Extension><LibV ersion>
Der Basisname kommt dann in die Requires-Liste.

Automatisch geht, aber nicht schön :stupid:

Delphi-Quellcode:

{$IF     CompilerVersion = 18.0} {$LIBSUFFIX '180'}
{$ELSEIF CompilerVersion = 18.5} {$LIBSUFFIX '185'}
{$ELSEIF CompilerVersion = 20.0} {$LIBSUFFIX '200'}
{$ELSEIF CompilerVersion = 21.0} {$LIBSUFFIX '210'}
{$ELSEIF CompilerVersion = 22.0} {$LIBSUFFIX '220'}
{$ELSEIF CompilerVersion = 23.0} {$LIBSUFFIX '230'}
{$ELSEIF CompilerVersion = 24.0} {$LIBSUFFIX '240'}
{$ELSEIF CompilerVersion = 25.0} {$LIBSUFFIX '250'}
{$ELSEIF CompilerVersion = 26.0} {$LIBSUFFIX '260'}
{$ELSEIF CompilerVersion = 27.0} {$LIBSUFFIX '270'}
{$ELSEIF CompilerVersion = 28.0} {$LIBSUFFIX '280'}
{$ELSEIF CompilerVersion = 29.0} {$LIBSUFFIX '290'}
{$ELSEIF CompilerVersion = 30.0} {$LIBSUFFIX '300'}
{$ELSEIF CompilerVersion = 31.0} {$LIBSUFFIX '310'}
{$ELSEIF CompilerVersion = 32.0} {$LIBSUFFIX '320'}
{$ELSEIF CompilerVersion = 33.0} {$LIBSUFFIX '330'}
{$ELSEIF CompilerVersion = 34.0} {$LIBSUFFIX '340'}
{$ELSEIF CompilerVersion = 35.0} {$LIBSUFFIX '350'}
{$ELSE} {$MESSAGE Error 'CompilerVersion unbekannt'} {$ENDIF}