Was bedeutet "Support & Maintenance for Delphi" bei Emba?

[jaenicke]

Zitat:

Zitat von DeddyH (Beitrag 1227139)

Natürlich hat jeder Programmierer zu Delphi 5-Zeiten bereits die Unicode-Problematik beherzigt, da ja klar war, dass Delphi irgendwann einmal komplett von Ansi zu Unicode umschwenkt.

Auch da gab es schon die konkreten API-Funktionen usw., deshalb habe ich auch schon lange vor Delphi 2009 entweder nur die Metatypen benutzt oder nur die konkreten. Genauso bei Integer oder Real, wo es relevant sein könnte habe ich auch immer (also nach ein paar Jahren lernen halt) LongInt usw. benutzt.

[Codehunter]

Meistens ist es ja so, dass man mit dem selbst produzierten Code am wenigsten Probleme hat. Zum Teil ging man ja dazu über, eigene Basistypen zu deklarieren, sodass man später nur an einer einzigen Stelle was ändern musste.

ABER: Bei nicht wenigen Projekten hat man 3rd-Party-Komponenten eingesetzt. Die waren für die damalige Zeit sehr mächtig und haben einem viel Arbeit abgenommen (wie z.B. Unidac, Firedac etc. heute) also wurden sie gern und oft verwendet.

Das Rad der Zeit drehte sich weiter, aber es fehlte stehts an den (seitens Geschäftsführung hier oder Kunde da) eingeplanten Migrationspfaden. Also blieb für die Altprojekte die Zeit quasi stehen. Irgendwann kommt man an den Punkt, da kann man einfach nicht mehr weiter machen auf der Basis und dann ist der Berg an notwendigen Anpassungen natürlich riesengroß.

Ich sag nur: Altprojekt läuft noch auf BDE, Kunde verlangt jetzt native 64-Bit-Anwendungen. *PLONK* 3rd-Party-Komponenten haben Design- und Runtime-Packages nicht sauber getrennt und desgnide im Runtime-Package verwendet. *PLONK*

So vergeudet man dann später die einstmals eingesparte Zeit wieder. Traurig aber wahr. Dann sind immer die Programmierer doof und unfähig. Fragt man aber, wer denn eigentlich aus Kostengründen kein Delphi 2009 kaufen wollte ist plötzlich Ruhe im Chefbüro.

Da kann froh sein wer selbstständiger Programmierer ist und in der Lage ist die Upgrades reinzuwirtschaften.

[Furtbichler]

Ich habe eine kommerzielle Software, die unter D3 entwickelt und bis D6 portiert wurde. Danach hat der Kunde die Portierungskosten nicht mehr übernommen. Das Teil läuft heute noch, D6 ist bei mir immer noch installiert. Bis ich D6 nicht mehr verwenden kann, weil Windows entweder eingestellt oder inkompatibel ist, vergehen noch Jahre. Aber selbst wenn, kann man einen Entwicklungs-PC oder eine VM mit der alten IDE so belassen.

Wieso man auf Deibel komm raus unbedingt *alle* seine Projekte upgraden muss, ist mir ein Rätsel. Natürlich ist es besser, hübscher, einfacher, aber wenn es nicht bezahlt wird... Mein D6 läuft sehr gut, die 3rd-Party-Komponenten (ausgewählte) sind auf dem aktuellsten Stand, und einige Komponenten sind im Laufe der Zeit eben rausgeflogen (meist Hobby-Komponenten). Also... WTF. Dann habe ich für dieses Projekt eben keine tolle (verbuggte) Super-IDE-Unterstützung. Na und? Die Delphi-IDE ist eh suboptimal.

Ich mach das Gleiche übrigens mit VS-Projekten. Für einen Kunden wurde das unter .NET 2.0 und VS2003 entwickelt. Wozu das Projekt portieren?

Wenn ich mal meinen Betrieb ruinieren möchte, würde ich Kundenprojekte ungefragt portieren. Hätte ich damals Unittests geschrieben, wäre das nicht so wild. Hab ich aber nicht, denn die waren damals noch gar nicht erfunden.

Und das es Leute gibt, die das lustige Kinderspiel 'Hinterher tue ich einfach so, als ob ich von vorneherein daran gedacht hätte' spielen, ist Teil einer pluralistischen Gesellschaft.

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1227357)

Wenn ich mal meinen Betrieb ruinieren möchte, würde ich Kundenprojekte ungefragt portieren.

Das ist bei dir auch etwas anderes. Bei uns gehören die Tools zum Gesamtpaket unserer Kassensoftware und werden meistens nicht nur bei einem Kunden eingesetzt, sondern sind allgemein gehalten.
Dass das bei reinen Kundenprojekten auf Anforderung etwas anderes ist, ist klar.

Zitat:

Zitat von Furtbichler (Beitrag 1227357)

Dann habe ich für dieses Projekt eben keine tolle (verbuggte) Super-IDE-Unterstützung. Na und? Die Delphi-IDE ist eh suboptimal.

Bei XE4 kann ich mich nicht beschweren. Probleme machen nur noch die wenigen Riesenunits mit mehr als 10k Zeilen :kotz:, die noch übrig geblieben sind...
Da funktioniert dann Error Insight nicht richtig und der Editor wird etwas langsamer.
In allen sauberen Units nach dem Refactoring oder gleich Umschreiben z.B. mit Generics funktioniert Error Insight bei mir aber nun korrekt und schnell, von ein paar Sperenzchen mit meiner Trickserei mit einem generischen Pointer mal abgesehen.

Und solche Sachen wie in Delphi 7... ich wollte gestern eigentlich nur für einen Forenpost im DF einen Assembler-Codeabschnitt kopieren... naja... wurde leider noch nicht so richtig unterstützt. Man konnte nur 30 Zeilen ab einer bestimmten kopieren, wobei es geflackert hat als würde der Editor dabei jede Zeile der Reihe nach markieren und kopieren :shock:. Markieren? Fehlanzeige.
Aber das ist ja nur das was mich aktuell genervt hat, der Rest würde Seiten füllen.

Gerade bei den ganzen Änderungen und Erweiterungen, die es in den letzten Jahren gab, macht daher finde ich ein Wartungsvertrag Sinn. Und standardmäßige Projektupgrades machen z.B. Sinn, wenn es sich um Projekte handelt, die standardmäßig zur Verfügung stehen, also zu erwarten ist, dass diese einmal z.B. an eine neue Softwarearchitektur angepasst werden müssen.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1227362)

ich wollte gestern eigentlich nur für einen Forenpost im DF einen Assembler-Codeabschnitt kopieren... naja... wurde leider noch nicht so richtig unterstützt. Man konnte nur 30 Zeilen ab einer bestimmten kopieren, wobei es geflackert hat als würde der Editor dabei jede Zeile der Reihe nach markieren und kopieren :shock:. Markieren? Fehlanzeige.

Huh? Ich habe ja bekanntermaßen 10 Jahre mit D7 pro gearbeitet aber ein derartiges Problem ist mir dabei nie unter gekommen. Ob da evtl. ein Addon wie GExperts oder CnPack Probleme macht?

[Union]

Das hat mich aber auch schon geärgert bei D7. Ich hatte schon oft im Rahmen von Extremst-Optimierungen die Notwendigkeit, den bestehenden asm-Code beim Debuggen/Profilen zu kopieren um evtl. schnellere Varianten für Sonderfälle zu erstelllen. Das musste ich dann abtippen, was bei längerem asm ekelhaft werden kann.

[Patito]

?!

Also ich habe hier im D7 im RechtsClick-Menü ein "Kopiere ASM Code" das funktioniert (kommt vom CnPack).

[jaenicke]

Zitat:

Zitat von Patito (Beitrag 1227921)

Also ich habe hier im D7 im RechtsClick-Menü ein "Kopiere ASM Code" das funktioniert (kommt vom CnPack).

Mit Markierung mehrerer Zeilen?

Zitat:

Zitat von Codehunter (Beitrag 1227907)

Huh? Ich habe ja bekanntermaßen 10 Jahre mit D7 pro gearbeitet aber ein derartiges Problem ist mir dabei nie unter gekommen. Ob da evtl. ein Addon wie GExperts oder CnPack Probleme macht?

Standardinstallation von Delphi 7 Personal. Mag an der Edition liegen, das kann ich nicht beurteilen. Ich hätte jetzt aber nicht erwartet, dass man das dann in der Form (die einfach nach "kann die IDE nicht" aussieht) macht.

Wie sieht das denn bei dir aus, wenn du in der CPU Ansicht mehrere Zeilen markierst und das Kontextmenü aufrufst?

[Union]

Also bei Delphi 7 Enterprise kann man im CPU-Fenster nichts markieren oder kopieren.

[jaenicke]

Hmm, vielleicht ist da doch das CnPack bei mir drin und das macht das. :?
Das erklärt dann auch die Umsetzung.

Naja, damals beim Lernen von Delphi habe ich das ja nie gebraucht und danach gab es ja schon bessere Delphiversionen, deshalb wusste ich das gar nicht, dass das da nicht ging.