Delphi Wartung vs. VS Wartung

[greenmile]

Hallo,

da in diesem Forum immer wieder Diskussionen bzgl. der Delphi Wartung aufkommen und Visual Studio sehr gerne als Gegenbeispiel genutzt wird, habe ich mich mal auf die Suche gemacht. Auch wenn ich Befürworter des Subscription-Modells bin hätte ich nicht gedacht, dass sich Embarcadero und Microsoft hier eigentlich kaum unterscheiden.

===

(Quelle: http://www.kessler.de/prd/microsoft/visual-studio.htm)
Der Initialkauf von Visual Studio Professional beträgt 1199 zzgl. MwSt, also 1426,81 EUR. Mit dabei ist eine 2 Jahres Subscription.
Nach den 2 Jahren kosten die nächsten 2 Jahre dann 989 EUR zzgl. MwSt, also 1176,91.

Der Initialkauf von Delphi XE7 beträgt laut EMBT Shop 1236,41 inkl. MwSt. Mit dabei ist (noch) keine Subscription. Die Subscription kostet pro Jahr ca. 292,03 EUR.

===

Im Vergleich:

- Delphi XE7 Pro
Initialkauf: 1.236,41 EUR
Subscription (pro Jahr): 292,03 EUR (mit MwSt?)

- Visual Studio Pro
Initialkauf: 1.426,81 EUR
Subscription (pro Jahr): 588,455 EUR (1.176,91 EUR / 2)


Von beiden Produkten gibt es eine kostenlose Version sowie eine Miet-Variante. Verglichen habe ich nur die Kauf-Variante.

Die Idee, dass beim Kauf gleich 2 Jahre Subscription mit dabei sind, finde ich gut und sinnvoll. Ältere Visual Studio's werden, genau wie Delphi, ebenfalls nicht aktualisiert, so gibt es schon Ewigkeiten z.B. einige Data-Repeater Bugs.

Dieses Beispiel zeigt aber, dass die geldgeile Embarcadero eigentlich ganz normal agiert, zumindest wenn man sich im Businessumfeld bewegt.

[himitsu]

Zitat:

Von beiden Produkten gibt es eine kostenlose Version sowie eine Miet-Variante.

Wirklich?

Turbo Delphi Explorer war die letzte kostenlose Version, aber die wurde gleich wieder eingestellt.
und davor gab es mal die Personal-Editionen. (bis Delphi 7)

Und die Schul-Lienzen (SSL) von Embarcadero sind eigentlich nicht benutzbar. Es sind zwar intern Enterprise-Editionen (glaub ich, bzw. war es mal so :gruebel:), zum Anlocken und Scharfmachen, aber mit den erstellten Programmen darf man nichts anfangen, da die Lizenzen ausschließlich zu Lernzwecken freigegeben sind.


PS: Version ist nicht ganz das richtige Wort.
Du meinst bestimmt Edition, bzw. Lizenz oder notfalls auch Variante.

[stahli]

Der VS-Preis ist aber mit MSDN.
Ohne kommt man auf ca. 650 € Einstiegspreis.

Vor einiger Zeit konnte man von anderen Entwicklungsumgebungen (u.a. Delphi) zu Upgrade-Preisen wechseln.
Die Möglichkeit gibt es heute aber leider offenbar nicht mehr.
(Tja, wenn man zu lange rumdödelt hat man halt Pech.)


Und selbst wenn die Kosten gleich wären (es gibt ja noch andere Kriterien) ... ;-)

[Lemmy]

glaube keiner Statistik die du nicht selbst gefälscht hast...

mein Visual Studio Pro kostet 599€ incl. MwSt. Und wenn wir schon am vergleichen sind, dann müssten wir hier mind. das RAD-Studio Pro mit vergleichen (mehrere Sprachen!) und dann sieht der Vergleich schon wieder ganz anders aus.

Dennoch gebe ich dir in Summe Recht: Im Businessumfeld sind das Peanuts im Vergleich zu den Kosten der Mitarbeiter. Aber wenn ich mich recht erinnere sind es auch meistens Hobbyentwickler und Einzelkämpfer die sich über die Preise aufregen, nur in den seltensten Fällen sind das "Betriebe"...

[Unx]

@greenmile

Hast du dir mal angesehen was die MSDN Subscription beinhaltet?
http://www.visualstudio.com/de-de/pr...ptions-vs.aspx

Ich glaube das ist kein Apfel/Birne Vergleich mehr sondern eher ein Erbse/Kokosnuss Vergleich.

[jensw_2000]

Ohne VS Subscription kostet das VS Profession Upgrade immer um und bei 350 EUR zu Vergleich zu Delphi 800.

[tsteinmaurer]

Ich war sehr lange auf Delphi 2010 Prof. und habe mich dann im Zuge eines Upgrades auf XE5 mal auf einen SA Abschluss verleiten lassen. Habe im Zuge von SA mittlerweil auch XE6 und XE7 bekommen. Nicht schlecht. Benachrichtigung bzgl. neuer Version funktionierte tadellos. Wenn man wie ich, rein auf Windows-Entwicklung unterwegs ist, d.h. kein Mobile, dann relativiert sich hier der Nutzen allerdings sehr stark, weil die Komponentenhersteller nicht wirklich einigermaßen zeitnah mit den neuen Delphi-Versionen nachziehen. Und wenn sie nachziehen, in der Regel als Major-Version als käufliches Upgrade. Gut, es gibt hier ein paar positive Ausnahmen wie Raize.

D.h. konkret z.B. EurekaLog hat Unterstützung für XE6 und XE7 in einem Minor-Release 7.1 nachgeschoben. Ca. 1 Jahr nach dem letzten EL Release. FastReports hat heimlich in V4 die Unterstützung für XE7 eingestellt. D.h. hier ist ein Upgrade auf V5 notwendig etc.

Meiner Meinung nach wäre es für Embarcadero von starkem Interesse, wenn Komponenten-Hersteller, die z.b. in einem Partnerprogramm teilnehmen, dazu vertraglich verpflichtet sind, eine neue Delphi-Version spätestens nach einem Zeitraum X zu unterstützen. Wozu bekommen die Hersteller denn Zugriff zu neueren Delphi-Versionen? Wenn sie das nicht einhalten, wird ihnen einfach der Partnervertrag gekündigt.

Generell war der SA Eindruck positiv was die Abwicklung betrifft, aber ich werde SA nicht verlängern. Für reine Windows-Entwicklung hat es für mich aktuell keinen Mehrwert, wenn die Komponentenhersteller teilweise so weit zurückhängen, dass ich mit XE6 erst produktiv werden kann, wenn bereits XE7 draußen ist.

[greenmile]

Ich gehe hier von "Kosten für die Entwicklungsumgebung" aus und möchte lediglich die jährlichen Kosten für die Entwicklungsumgebung aufzeigen. Und die sind in beiden Fällen nahezu identisch. Quasi "Was muss ich jährlich ausgeben, um zu programmieren". Ich habe z.B. auf der Delphi Seite auch "Kann für Mac compilieren" nicht hervorgehoben. Es geht einzig und allein um die Zahl, die ich ausgeben muss. Und eine Wartung ist auch bei VS mehr als Empfehlswert, da sich der Release-Zyklus auch bei VS in naher Zukunft verkürzen wird.

[Lemmy]

Zitat:

Zitat von tsteinmaurer (Beitrag 1274910)

D.h. konkret z.B. EurekaLog hat Unterstützung für XE6 und XE7 in einem Minor-Release 7.1 nachgeschoben. Ca. 1 Jahr nach dem letzten EL Release. FastReports hat heimlich in V4 die Unterstützung für XE7 eingestellt. D.h. hier ist ein Upgrade auf V5 notwendig etc.

Da muss ich kurz meine Hand heben: FR4 wurde 2006 veröffentlicht und alle bis zu FR5 erschienenen IDEs kostenlos nachgereicht. Dass die dann irgend wann wieder Einnahmen generieren wollen versteht sich IMHO.... War beim Übergang von FR3 auf FR4 nicht anders und von daher nicht überraschend...

Zudem wurden allen Bestellern die ein halbes Jahr vor der Veröffentlichung von FR5 eine FR4 gekauft haben die FR5 kostenlos gegeben. Bestandskunden die früher gekauft haben wurde die FR5 ebenfalls kostenlos gegeben, wenn sie auf eine höhere Version von FR4 aktualisiert haben (z.B. von Prof auf Enterprise) was günstiger war als das einfache Update auf Version 4.

Von daher mag der Vorwurf sicherlich stimmen, dass hier manche sehr schnell mit dem Rechnungsblock wedeln, für Fastreport kann ich das aber nicht gelten lassen...

Grüße

[jensw_2000]

Zum Thema Kostenvergleich ist noch anzumerken, dass ältere .Net Komponenten auch gut mit neuen VS Versionen zurechtkommen. Ein VS Upgrade zieht also nicht immer ein Zwangsupdate aller Komponenten nach sich.
Mit jedem Delphi Upgrade muss man Komponenten ohne Source für die neue Version kaufen bzw. ebenfalls unter Wartungsvertrag haben.

[Uwe Raabe]

Zitat:

Zitat von jensw_2000 (Beitrag 1274935)

muss man Komponenten ohne Source für die neue Version kaufen

Setzt denn wirklich jemand sowas im kommerziellen Umfeld ein? Das halte ich für ziemlich risikofreudig.

[jensw_2000]

Nein, sicher nicht. Da gebe ich Dir Recht.

Ändert aber nichts an den Fakten.
Im kommerziellen Umfeld kostet es trotzdem eine Subscription für die 3rd Party Komponenten, weil vermutlich kaum jemand einen wertvollen Mitarbeiter 2 mal pro Jahr tagelang damit beschäftigt, um die ganzen "Uses Änderungen" in IFDEFS zu verpacken und Packages für die neue Delphi Version zu bauen.

[stahli]

Uwe, Du siehst das immer aus Deiner erfolgreichen kommerziellen Sicht.

Kleine Selbständige und Hobbyprogrammierer können nicht ständige Ausgaben in beliebiger Höhe einplanen.
Wenn Du das als gut laufende Firma kannst ist das ok.
Aber es trifft halt nicht auf jeden potenziellen Delphi-Anwender zu.

Wenn wenigstens das erworbene Produkt dann halten würde was es verspricht, dann könnte man ja mal aller paar Jahre in den sauren Apfel beißen...

Ok, mir es inzwischen ja egal.
Ich habe eine neue (noch größere) Liebe gefunden. :-)

PS: Nur an der DP hänge ich immer noch. :love:

[greenmile]

Zitat:

Zitat von stahli (Beitrag 1274946)

Uwe, Du siehst das immer aus Deiner erfolgreichen kommerziellen Sicht.

Kleine Selbständige und Hobbyprogrammierer können nicht ständige Ausgaben in beliebiger Höhe einplanen.
Wenn Du das als gut laufende Firma kannst ist das ok.
Aber es trifft halt nicht auf jeden potenziellen Delphi-Anwender zu.

Wenn wenigstens das erworbene Produkt dann halten würde was es verspricht, dann könnte man ja mal aller paar Jahre in den sauren Apfel beißen...

Ok, mir es inzwischen ja egal.
Ich habe eine neue (noch größere) Liebe gefunden. :-)

PS: Nur an der DP hänge ich immer noch. :love:

Naja, wer kein Geld verdient wird entweder die kostenlose Variante oder eine "kopierte" nutzen, für die meisten kommt dann eh keine Lizenz in Frage. Der Kleinunternehmer muss es sich ausrechnen. Ein Schreiner braucht Holz, ein Maurer Steine und ein Entwickler halt Entwicklungswerkzeuge für die Arbeit. Man sollte nicht davon ausgehen, dass man nichts investiert und nur Gewinn macht. Es ist das Arbeitswerkzeug.

[greenmile]

Zitat:

Zitat von Uwe Raabe (Beitrag 1274941)

Zitat:

Zitat von jensw_2000 (Beitrag 1274935)

muss man Komponenten ohne Source für die neue Version kaufen

Setzt denn wirklich jemand sowas im kommerziellen Umfeld ein? Das halte ich für ziemlich risikofreudig.

Die Erfahrung muss jeder mindestens einmal in seinem Entwicklerdasein machen. Tut weh, man lernt aber ungemein ;)

[jensw_2000]

Jaaahaaa.
Bis auf ein "Mini Ding" hatte ich auch immer die teureren Varianten mit Source gekauft.
Es geht hier aber um Kosten. Und da steht für mich fest:
.Net Komponenten kann man in den allermeisten Fällen uneingeschränkt mit neuen VS Versionen verwenden. Sie kosten daher nicht zwangsläufig neues Geld, wenn man VS aktualisiert.
Delphi Komponenten kosten entweder eine Subscription oder 2x pro Jahr wertvolle Arbeitszeit und Nerven.

[Bernhard Geyer]

Zitat:

Zitat von jensw_2000 (Beitrag 1274945)

Im kommerziellen Umfeld kostet es trotzdem eine Subscription für die 3rd Party Komponenten, weil vermutlich kaum jemand einen wertvollen Mitarbeiter 2 mal pro Jahr tagelang damit beschäftigt, um die ganzen "Uses Änderungen" in IFDEFS zu verpacken und Packages für die neue Delphi Version zu bauen.

Die meisten (jedenfalls vernünftigen) Packagesammlungen haben ein Inc-Datei und dort wird in den letzten Version einfach nur ein Block für die neueste Compilerversion ergänzt.

[jensw_2000]

Der neue Versionseintrag in der INC stellt sicher auch gleich die ganzen Uses Klauseln in allen Sourcefiles um und fixt alle Referenzen. Seit Delphi XE bleibt da ja leider kein Stein mehr auf dem anderen ... :roll:

[Stevie]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1274958)

Die meisten (jedenfalls vernünftigen) Packagesammlungen haben ein Inc-Datei und dort wird in den letzten Version einfach nur ein Block für die neueste Compilerversion ergänzt.

Wer es richtig macht, nutzt eine inc Datei, die aufwärtskompatibel ist, so wie Jedi.inc. Da muss man bei Benutzung der DELPHIXXX_UP Direktiven garnüscht ändern.

Zitat:

Zitat von jensw_2000 (Beitrag 1274959)

Der neue Versionseintrag in der INC stellt sicher auch gleich die ganzen Uses Klauseln in allen Sourcefiles um und fixt alle Referenzen. Seit Delphi XE bleibt da ja leider kein Stein mehr auf dem anderen ... :roll:

Kommt auf den Bereich an, aber in den meisten Fällen kann jeder halbwegs taugliche Delphi Entwickler das unter Benutzung von Suchen und Ersetzen in Kürze selber anpassen.

[Phoenix]

Zitat:

Zitat von greenmile (Beitrag 1274903)

Ältere Visual Studio's werden, genau wie Delphi, ebenfalls nicht aktualisiert, so gibt es schon Ewigkeiten z.B. einige Data-Repeater Bugs.

Quatschfug.

Für Visual Studio 2010 gibt es noch bis Mitte Juni 2015 Mainstream-Support, für zahlende Kunden bis Mitte 2020.
Für VS 2012 bis 2018 bzw. 2023 und für das aktuelle VS 2013 bis 2019 bzw. 2024. Also jeweils 5 Jahre Mainstream-Support und 10 Jahre Extended Support.

Quelle: http://support2.microsoft.com/lifecy...ilter=FilterNO


Der Data-Repeater ist im übrigen kein Element des Visual Studios, sondern des .NET Frameworks, und in den neueren aktualisierten Versionen des Frameworks sind die vermutlich schon gefixt. Zeig mir auch mal bitte die Bug-Meldungen bei Microsoft Connect auf die Du Dich hier beziehst.

[Phoenix]

Zitat:

Zitat von greenmile (Beitrag 1274911)

da sich der Release-Zyklus auch bei VS in naher Zukunft verkürzen wird.

Auch so nicht wahr. VS 2010 war Version 11. Von 12 (2012) auf 13 (2013) war es zufälligerweise mal ein Jahr.
VS 14 wird aktuell gegen Mitte 2015 erwartet (1,5 Jahre zur vorherigen Version).

Der 1-Jahres Zyklus hat sich als zu kurz herausgestellt. Die Zeiten werden aktuell also tatsächlich wieder länger.
Was sich hier ändert ist, das es zwischen den Versionen Update-Packs gibt, die auch neue Funktionalitäten hinzufügen. Bei VS 2013 sind wir aktuell schon bei Update 3.

Diese Updates bekommt mal allerdings auch, wenn man seine VS Edition ohne Subscription gekauft hat. Von daher ist eine Subscription nicht unbedingt notwendig.

Die braucht man eigentlich ausschliesslich dann, wenn man die Zusatzleistungen wie die MSDN-Software, die enthaltene TFS Client-Lizenz oder die Azure-Inklusivpakete nutzen möchte. Dann spart man in der Tat richtig viel Geld gegenüber dem Einzelkauf, denn allein schon die TFS-Clientlizenz ist fast nochmal so teuer wie das komplette VS Pro.

[Dejan Vu]

Zitat:

Zitat von jensw_2000 (Beitrag 1274955)

Delphi Komponenten kosten entweder eine Subscription oder 2x pro Jahr wertvolle Arbeitszeit und Nerven.

Wa? Ich hab DevExpress, ohne Subscription. Wechsle aber auch mein Delphi nicht 2x pro Jahr. Ich bin doch nicht blöd bzw. war ich es nicht. Und: Ja, ich hab viel Geld mit damit verdient und nein: Ohne das jeweils neueste Teil zu haben. Eigentlich hab ich das meiste mit D6/7 und BDS(?)2007 (die letzte ohne Unicodestrings als Standard) gemacht. Das sind dann in -glaube ich- 15 Jahren 3 Updates. Geht eigentlich.

Ich arbeite zwar derzeit nur mit VS, aber selbst da wird noch in VS2010 entwickelt. Da die Programme mit VS2010 genauso hübsch sind, wie mit VS2014, hüpfen wir da auch nicht auf die jeweils neueste Version. Demnächst wird schon irgendwann eine aktuelle Version gekauft.

Also: Ich kann immer hinter der aktuellen Version hinterherhecheln oder es sein lassen und mich auf meine Arbeit konzentrieren.

Nebenbei: Bei einer neuen VS-Version hab ich nicht all zu viel Arbeit. Aber auch nur, weil ich nicht all zu viel Zusatzprogramme habe: Resharper, Typemock und DevEx.

[Der schöne Günther]

Zitat:

Zitat von Dejan Vu (Beitrag 1275015)

Ich bin doch nicht blöd bzw. war ich es nicht. [...] Ich kann immer hinter der aktuellen Version hinterherhecheln oder es sein lassen und mich auf meine Arbeit konzentrieren.

Ich wollte diese Woche das größte Projekt von XE5.1 auf XE7 hochziehen. Änderungen an FireDAC, regulären Ausdrücken und XML. Danke für die Motivation. :-D 8-)

[stahli]

@Dejan Vu
Das Problem ist eben aus meiner Sicht, dass man seit D-XE2 nicht mehr auf Updates verzichten kann, wenn man ernsthaft mit D arbeiten will.
Erstens werden die Bugs sonst nicht bereinigt (was ganz klar Emba anzulasten ist) und zweitens ändern sich im mobilen Bereich ständig die Betriebssysteme und Anforderungen (wofür Emba da nun nichts kann).

Ich hatte es früher auch so gehalten, aller paar Jahre ein Upgrade zu kaufen (wenn es was interessantes neues gab).
Das ist aber heute (wenn man mit FMX arbeiten will) kein gangbarer Weg mehr.
Entweder man nimmt alle kostenpflichtigen Updates mit oder man bleibt auf der Strecke.

Gilt natürlich nur alles für FMX. Wer nur die VCL nutzt kann sich wohl erst mal eine Weile zurück lehnen... ;-)

[Dejan Vu]

@Günther: Du bist ja nur dann blöd :mrgreen:, wenn Du das vorher schon von D5 auf D7, dann von BDS2005 auf 2006 und 2007 und 2009 etc. gemacht hast. Einmal sei dir verziehen. Oder..äh..ist das dein Hobby?

@Stahli: Jo, das ist wohl so.

[jensw_2000]

Zitat:

Zitat von Dejan Vu (Beitrag 1275015)

Zitat:

Zitat von jensw_2000 (Beitrag 1274955)

Delphi Komponenten kosten entweder eine Subscription oder 2x pro Jahr wertvolle Arbeitszeit und Nerven.

Wa? Ich hab DevExpress, ohne Subscription. Wechsle aber auch mein Delphi nicht 2x pro Jahr. Ich bin doch nicht blöd bzw. war ich es nicht. Und: Ja, ich hab viel Geld mit damit verdient und nein: Ohne das jeweils neueste Teil zu haben. Eigentlich hab ich das meiste mit D6/7 und BDS(?)2007 (die letzte ohne Unicodestrings als Standard) gemacht. Das sind dann in -glaube ich- 15 Jahren 3 Updates. Geht eigentlich.

Ich arbeite zwar derzeit nur mit VS, aber selbst da wird noch in VS2010 entwickelt. Da die Programme mit VS2010 genauso hübsch sind, wie mit VS2014, hüpfen wir da auch nicht auf die jeweils neueste Version. Demnächst wird schon irgendwann eine aktuelle Version gekauft.

Also: Ich kann immer hinter der aktuellen Version hinterherhecheln oder es sein lassen und mich auf meine Arbeit konzentrieren.

Nebenbei: Bei einer neuen VS-Version hab ich nicht all zu viel Arbeit. Aber auch nur, weil ich nicht all zu viel Zusatzprogramme habe: Resharper, Typemock und DevEx.

Hast voll Recht. Wenn man nicht updated und nur mit uralten Versionen arbeitet sind Delphi + VS gleich teuer. Etwa 0 EUR würde ich schätzen.

[Dejan Vu]

Wer zählen kann, ist klar im Vorteil (0 != 3) und wer lesen kann, auch ('uralt' != ältere Version).

Aber in meinem Beitrag ging es eher um die absurde Idiotie (dafür halte ich es), sich das 2x pro Jahr entweder anzutun oder laut Stahli antun zu müssen. Das es auch anders geht, zeigen eigentlich die meisten größeren Betriebe, die sich eben nur alle paar Jahre mal eine aktuelle Version des benutzten Werkzeugs anschaffen. Ich vermute ja, das da jemand entscheidet, der den TCO im Blickfeld hat.

Und dann ist dann der hier aufgestellte Vergleich vielleicht nicht besonders praxisnah. Aber wer Spaß dran hat, soll es halt machen.

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1275008)

Wer es richtig macht, nutzt eine inc Datei, die aufwärtskompatibel ist, so wie Jedi.inc. Da muss man bei Benutzung der DELPHIXXX_UP Direktiven garnüscht ändern.

Wenn man von D6 kommt muss man teilweise aber noch Steinzeit-Technik verwenden.
Werde ich mir aber mal anschauen.

[Uwe Raabe]

Zitat:

Zitat von Dejan Vu (Beitrag 1275027)

Aber in meinem Beitrag ging es eher um die absurde Idiotie (dafür halte ich es), sich das 2x pro Jahr entweder anzutun oder laut Stahli antun zu müssen.

Es gibt aber auch genügend Beispiele, wo das durchaus geht, sinnvoll ist und so gut wie keinen Aufwand verursacht. In meinen Projekten verwende ich ca. 2 Dutzend Bibliotheken und brauche maximal einen Tag, um sie mit einer neuen Delphi-Version zu compilieren - noch bevor irgendwelche Updates dieser Bibliotheken rauskommen. Im Wesentlichen ist es lediglich das Öffnen und Compilieren der einzelnen Projektgruppen, Anpassen des LIBSUFFIX und das Installieren der Design-Packages. Die wenigen Stellen, wo der Compiler eventuell hakt, sind schnell behoben. Dank SA sind die halbjährigen Updates auch keine Kostenfrage. Eigentlich warte ich immer nur auf die passende Version vom ModelMaker Code Explorer, ohne den ich mich schon fast irgendwie verkrüppelt fühle.

Ich will nicht sagen, daß das in allen Fällen möglich ist, nur daß das geschilderte (Schreckens-)Szenario nicht zwingend sein muss und in vielen Fällen durch geeignete Vorbereitungen umgangen werden kann.

[himitsu]

Zitat:

Zitat von Stevie (Beitrag 1275008)

Wer es richtig macht, nutzt eine inc Datei, die aufwärtskompatibel ist, so wie Jedi.inc. Da muss man bei Benutzung der DELPHIXXX_UP Direktiven garnüscht ändern.

Oder man benutzt die schon bei Borland eingeführten Conditional Expressions mit den Konstanten CompilerVersion, bzw. RTLVersion, und kommt ohne eine INC aus.

Früher waren in einigen der INCs, bzw. im System auch "Features" als DEFINEs angelegt, mit denen man arbeiten konnte, anstatt auf eine Version zu prüfen, was auch irgendwie verständlicher war, aber bei Vielen der wirren Änderungen in letzter Zeit, ist das so eh nicht mehr verwendbar, oder schafft Emba es wirklich bei jedem Update auch die RTL-/CompilerVersion zu ändern?
Auf diese Weise war der Code/die Prüfung auch für unterschiedliche Compiler/Bibliotheken (z.B. Delphi, Lazarus, FPC, ...) nutzbar.

Bei meinen Conditional Expressions prüfe ich dann oftmals lieber auf das Vorhandensein bestimmter Typen/Funktionen, damit hab ich mir im Code auch gleich oftmals den Kommentar erspart, was ich eigenntlich prüfen wollte.

Delphi-Quellcode:

{$IF Declared(TEdit)}

/

Delphi-Quellcode:

{$IF Defined(WIN32)}

/

Delphi-Quellcode:

{$IF CompilerVersion >= 20}

Vorallem da man hier ganz praktisch mehrere Prüfungen kombinieren kann, anstatt das Zeug umständlich verschachteln zu müssen.

Delphi-Quellcode:

{$IF Defined(WIN32) and (CompilerVersion >= 20) and (CompilerVersion <= 23)}

Wenn man das mit dem XE nicht eingeführt hätte, dann hätte ich mir eine Integer/Float-Konstante "DelphiVersion" gewünscht.
(Solange das mit dem XE bleibt, oder zumindestens die Nummer nicht mal wieder auf 1 zurückgesetzt wird, wäre das ja immernoch eine Option, wenn man "ab XE" zählt)

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1275038)

Zitat:

Zitat von Stevie (Beitrag 1275008)

Wer es richtig macht, nutzt eine inc Datei, die aufwärtskompatibel ist, so wie Jedi.inc. Da muss man bei Benutzung der DELPHIXXX_UP Direktiven garnüscht ändern.

Oder man benutzt die schon bei Borland eingeführten Conditional Expressions mit den Konstanten CompilerVersion, bzw. RTLVersion, und kommt ohne eine INC aus.

Jo, hab ich auch in der Vergangenheit gemacht. Und dann muss man irgendwann dauernd auf nen Spickzettel schauen, welche Version nun welche CompilerVersion war, nee danke.

[himitsu]

Die CompilerVersion ist ja auch nichts anderes als das in dem VERxxx.
Und ja, darum wäre ein Delphi-Version, mit der öffentlichen Versionsnummer, ganz nett.

[mkinzler]

Nach dem Motto: Was MS kann, können wir schon lange!

(Überspringen von Versionssnummern)

Aber irgendwie kommen wir schon wieder vom Thema ab.

[greenmile]

Zitat:

Zitat von mkinzler (Beitrag 1275060)

Aber irgendwie kommen wir schon wieder vom Thema ab.

:thumb:

Mir ging es lediglich darum aufzuzeigen, dass Embarcadero nicht unmenschlich und geldgeil ist. Wenn man nicht gerade mit kostenlosen Umgebungen wie FPC hantiert, dann kostet das Arbeitswerkzeug nunmal Geld. Und so groß sind die Unterschiede zwischen Embarcadero und anderen Herstellern nicht, im Beispiel der wohl größte von allen (MS). Nur wird bei MS nicht gejammert, geflucht, mit weggehen gedroht. Oder es interessiert einfach niemanden. Befreundete VS-Entwickler kennen diese Diskussion nicht. Nimm die Wartung oder lass es. Gibt es etwas, was in neueren Versionen behoben ist? Dann kauf die neue Version oder programmier drumrum.

[Dejan Vu]

Zitat:

Zitat von greenmile (Beitrag 1275064)

Nur wird bei MS nicht gejammert, geflucht, mit weggehen gedroht.

Weil Bugs dort sehr selten sind, die IDE stabil ist, die Sprache modern ist und moderner wird? Perfekt ist da Vieles nicht, aber es gibt einfach weniger Grund, sich zu ärgern.

Richtig: Ich bin auch auf die Abzockfalle hereingefallen, bei der ich dachte, Emba zieht einen über den Tisch, was aber einfach nicht stimmt. Die Subscription/Abo ist fair und für Profis kein Ding, weil das unter 'laufende Kosten geht' und dazugehört: Werkzeug muss gepflegt werden.

Ich denke, das Gejammere wird sich legen, wenn die Qualität nachhaltig steigt. Man hat aber immer diese Echoeffekte, wenn ein Laden lange Zeit Murks produziert hat und sich dann mal Mühe gibt.

[greenmile]

Seit XE6 kann ich für meinen Teil wirklich nicht meckern und ich habe lange und ausführlich auf FM geschimpft.

[Stevie]

Zitat:

Zitat von Dejan Vu (Beitrag 1275066)

Man hat aber immer diese Echoeffekte, wenn ein Laden lange Zeit Murks produziert hat und sich dann mal Mühe gibt.

... vor allem von denen, die in der "Murksphase" ausgestiegen sind und dennoch nicht müde werden, bei jeder sich bietenden Gelegenheit rumzumotzen ... :x

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1275066)

Zitat:

Zitat von greenmile (Beitrag 1275064)

Nur wird bei MS nicht gejammert, geflucht, mit weggehen gedroht.

Weil Bugs dort sehr selten sind, die IDE stabil ist, die Sprache modern ist und moderner wird? Perfekt ist da Vieles nicht, aber es gibt einfach weniger Grund, sich zu ärgern.

Nun das ist ja nun nicht ganz richtig. Bei M$ ist einiges die Technologie der Zukunft, die morgen schon nicht mehr stattfindet. Und wenn ich da an den Umstieg von "Normal-BASIC" auf "Object-BASIC" denke, da schwappten die Wellen aber auch ganz schön hoch, und der Untergang des Abendlandes stand kurz bevor.

Zitat:

Zitat von Dejan Vu (Beitrag 1275066)

Werkzeug muss gepflegt werden.

:thumb:

Zitat:

Zitat von Dejan Vu (Beitrag 1275066)

Ich denke, das Gejammere wird sich legen, wenn die Qualität nachhaltig steigt. Man hat aber immer diese Echoeffekte, wenn ein Laden lange Zeit Murks produziert hat und sich dann mal Mühe gibt.

Aber der Aufwand einen ruinierten Ruf wieder aufzupolieren ist ungleich größer als es gleich richtig zu machen.

Gruß
K-H

[Dejan Vu]

Zitat:

Zitat von p80286

. Weil Bugs dort sehr selten sind, die IDE stabil ist, die Sprache modern ist und moderner wird? Perfekt ist da Vieles nicht, aber es gibt einfach weniger Grund, sich zu ärgern.

Nun das ist ja nun nicht ganz richtig.[/QUOTE] Wie kann man da widersprechen?
1. 'Bugs sind sehr selten'. Richtig oder nicht richtig?
2. 'IDE ist stabil'. Richtig oder nicht richtig?
3. 'Sprache ist modern'.Richtig oder nicht richtig?
4. 'Vieles ist nicht perfekt'. Richtig oder nicht richtig?
5. 'Es gibt weniger Grund, sich zu ärgern'. Richtig oder nicht richtig?

Ich will MS (Microsoft wird mit 's' geschrieben und nicht mit '$', denn diesen Buchstaben gibt es nicht) nicht in den Himmel heben, aber qualitativ gute Software produzieren sie nun mal. Und natürlich ist niemand perfekt. Und genau das habe ich beschrieben.

Nebenbei: MS ist auch ein klitzekleinwenig größerer Laden als Emba und hat marginal mehr Resourcen und Möglichkeiten, das wollen wir mal nicht vergessen. Und dafür leistet die Delphi-Truppe schon echt Beachtliches.

PS: Was den erwähnten BASIC-Paradigmenwechsel anbelangt, erinnert mich das dann doch ein wenig an die Delphi-Gemeinde...
:duck:

[greenmile]

Zitat:

Zitat von Dejan Vu (Beitrag 1275078)

Nebenbei: MS ist auch ein klitzekleinwenig größerer Laden als Emba und hat marginal mehr Resourcen und Möglichkeiten, das wollen wir mal nicht vergessen. Und dafür leistet die Delphi-Truppe schon echt Beachtliches.

:thumb: