Delphi 2011 heißt jetzt Delphi XE

[cookie22]

ja, schon klar. :)

[xZise]

Auch wenn es natürlich nicht schlecht wäre, wenn es beide Delphis könnten.

MfG
Fabian

[Chemiker]

Hallo MEissing,

Zitat:

Zitat von MEissing

Schau dir mal die Zahlen vom zB Tiobe Index an. Da sehe ich einen Aufwärtstrend. Auch zeigen unserer Umsatz/Stückzahlen eine sehr positive Tendenz auf.

Sorry, von solchen Indexen halte ich überhaupt nichts. Ich habe meinen eigenen Index und der ist sehr einfach: Wie viele Bücher werden für Delphi 2009 oder 2010 aktuell in deutscher Sprache angeboten?
Also darf ich festhalten das in Deutschland (nur hier habe ich einen Überblick) steigen die Stückzahlen?

Zitat:

Zitat von MEissing

Das kann ich dir nicht erklären: Du belegst Deine Zahlen nicht;

Ich kann die Zahlen nicht belegen, dann würde ich meine Quelle diskreditieren. Ich kann sie aber auch nicht überprüfen, wenn keine Informationen seitens Embarcadero weitergegeben werden.

Zitat:

Zitat von MEissing

wir selber äussern uns nie über die Anzahl der Entwickler.

Warum eigentlich nicht? Ist doch ein gutes Parameter um zu sehen wie wichtig ein Unternehmen ein Produkt ist und wie viel Arbeit hinter dem neuen Delphi XE steckt.

Zitat:

Zitat von MEissing

Keiner bemerkt hier ausnahmsweise mal positiv, dass sich die Produktqualität in den letzten 3 Jahren (seit CodeGear/Embarcadero) *deutlich* verbessert hat.

Also ich kann jetzt nur für mich sprechen, aber die Produktivität ist seit Erscheinen von Delphi 2009 erst mal sehr gering, durch die Umstellung auf UniCode. Aber es stimmt schon, Delphi war auf einen guten Weg den Anschluss zu anderen Entwicklungsumgebungen wieder herzustellen, deswegen ist der Bruch der jetzt mit XE meiner Meinung standfindet, nicht zu verstehen.

Zitat:

Offensichtlich ist der Preis ein viel entscheidenderes Merkmal, als die Qualität des Produktes.

Ich denke, dass eine schließt das andere nicht automatisch aus.

Zitat:

Wir passen im Laufe der Zeit immer die Roadmap auf Kundenwünsche an (unter der Prämisse der uns zur Verfügung stehenden Ressourcen)
Lass es dir gesagt sein: 64-Bit Support wollen viele, brauchen aber wenige.

Als normaler Anwender von Software gebe ich Dir Recht, allerdings als Entwickler ist das eine Diskussion die man genauso gut bei der Umstellung von 16Bit auf 32Bit geführt hat, 64Bit ist einfach Stand der Technik ob man will oder nicht. Durch das ständige Verschieben ins nächste Jahr wird nicht grade das Vertrauen der Entwickler in Delphi gestärkt.
Man sollte dabei auch bedenken, dass die Umstellung der Software je nach Umfang der Änderungen die erforderlich sind, auch bei den Entwicklern eine gewisse Zeit in Anspruch nimmt.

Zum Schluss noch ein Lob an Deiner Person, ich finde es klasse das Du Dir dieser zugegebener maßen nicht immer sachlichen Diskussion stellst.

Bis bald Chemiker

[HeikoAdams]

Zitat:

Zitat von Chemiker (Beitrag 1043933)

Man sollte dabei auch bedenken, dass die Umstellung der Software je nach Umfang der Änderungen die erforderlich sind, auch bei den Entwicklern eine gewisse Zeit in Anspruch nimmt.

Was man dabei auch nicht vergessen darf: Je länger eine Delphi-Anwendung noch als reine 32bit Software weiterentwickelt werden muss, bevor es irgendwann endlich einen 64bit Compiler gibt, desto größer ist natürlich der Aufwand bei der Umstellung auf 64bit, da entsprechend mehr Sourcecode/Porgrammfunktionen getestet werden müssen, bevor eine Freigabe für 64bit Systeme erteilt werden kann.

[sh17]

Zitat:

Zitat von cookie22 (Beitrag 1043725)

1. error insight funktioniert nicht seit der 2005er version.
2. generics funktionieren nicht zu 100%
3. seit dem hochgepriesenen hotfix 5 kann ich keine packages mehr erstellen.
4. "deklaration suchen" funktioniert oft nicht. dp thread zum thema
5. in der ide hab ich ständig ne sanduhr, wenn ich zwischen code und design switche.
6. wenn fehler im code sind schaltet der editor zufällig die pas datei auf read only. einmal kann man das zurückschalten, beim nächstenmal ist der menü punkt auf disabled gesetzt.

fehler nr.4 ist für mich am schlimmsten und schränkt die produktivität erheblich ein.

So, ich mach mal direkt ein Zitat von hier, hab den Rest noch nicht gelesen, weil ich da mal zustimmen wollte. Ist ja richtig was los hier. Wir sind erst vor kurzem von D6 auf D2010 gewechselt und ich muss sagen, ich bin genauso "zufrieden" wie vorher, aber zumindest erleichtert, nicht schlechter gekommen zu sein. Hab lange gewartet und viel gelesen zu Delphi und bei 2010 endlich zugeschlagen.

1. "deklaration suchen" geht immer noch so bescheiden wie in Delphi - meist gar nicht wenn der Quelltext Fehler enthält.
2. Code-Completion geht meist bei Fehlern im Quelltext auch nicht und innerhalb des Parameter-Arrays von Format noch nie.
3. Der Debugger reisst bei Abbruch über STRG-F2 öfters das ganze Delphi mit, gut, sehe ich unter Umständen ein, wenn die Codestelle "verzwickt" aussieht, das ist aber subjektiv
4. Der wechsel von Code zum Designer dauert "ewig"
5. STRG+F4 geht nicht, wenn der Designer aktiv ist, man muss erst zum Code wechseln

Wenn ich noch ne Weile überlege, fällt mir noch mehr ein. Und ehrlich gesagt hab ich keinen Bock ständig im QC zu suchen, ob ich der Erste mit dem Problem bin - sicher nicht, von daher...

Wie wäre es Delphi 2010 noch zwei Jahr zu pflegen und massiv zu verbessern, bevor eine neue Version rauskommt - klar - kommt kein Geld rein, aber dafür eine stabile IDE als Grundlage für die nächste Version. Es Delphi in WPF wird es ja hoffentlich nicht gleich geben, das wieder alles über den Haufen geworfen wird.

[HeikoAdams]

Zitat:

Zitat von sh17 (Beitrag 1043961)

Und ehrlich gesagt hab ich keinen Bock ständig im QC zu suchen, ob ich der Erste mit dem Problem bin - sicher nicht, von daher...

Ich denke mal, das man die QC mal gründlich durcharbeiten sollte, um doppelte Einträge und Leichen zu entsorgen. Und im nächsten Schritt sollte Emba ein Bugtracking-System konsequent nutzen, falls es wirklich so ist, das intern ein anderes System als QC verwendet wird.

[Hansa]

Zitat:

Zitat von cookie22 (Beitrag 1043847)

1. office plugins
2. explorer shell extensions
3. kunden mit 64 bit oracle wollen auch 64bit clients

zu 1. welche laufen nur unter 64 Bit ? :shock:
zu 2. was fehlt denn da noch ? M$ soll mal besser die längst angekündigt SQL-Erweiterung für Dateisystem bringen. Aber bitte nicht im Stile von Vista.
zu 3. Ist den Leuten da auch klar, dass sie kaum einen Vorteil davon haben ? Bzw. nur unnötigerweise angeschaffte neue Rechner ? :mrgreen:

Übrigens : Nehme alle Fragen zurück, sofern konkreter zwingender Einsatzgrund genannt wird. :mrgreen:

Kann ja fast nicht sein, dass diese mickrigen 3 Sachen so wichtig sind. 8-)

[holliesoft]

'n Abend,

Zitat:

Zitat von Hansa (Beitrag 1043968)

Zitat:

Zitat von cookie22 (Beitrag 1043847)

1. office plugins
2. explorer shell extensions
3. kunden mit 64 bit oracle wollen auch 64bit clients

zu 1. welche laufen nur unter 64 Bit ? :shock:

Wenn Kunden die 64bit Version von Office 2010 installiert haben, dann können sie keine 32bit Plugins installieren.
Genauso verhält es sich mit Plug-Ins für den Internet Explorer.

Du müsstest also Deinen Kunden, für Die Du evtl. Plug Ins entwickelt hast, vorschreiben, dass sie nur 32bit Versionen von Office / IE benutzen. Verstehen tut das kein Anwender.

[MEissing]

Zitat:

Zitat von holliesoft (Beitrag 1043969)

Du müsstest also Deinen Kunden, für Die Du evtl. Plug Ins entwickelt hast, vorschreiben, dass sie nur 32bit Versionen von Office / IE benutzen. Verstehen tut das kein Anwender.

Microsoft empfiehlt sogar den Einsatz von 32-Bit Office (weil sie selbst den Markt für 64-Bit noch nicht als bereit ansehen)

http://blogs.technet.com/b/dmelancht...er-64-bit.aspx

"Microsoft strongly recommends...."

[cookie22]

1. welche die mit nem 64bit office kommuniezren mussen.
2. Was hat die sql-erweiterung jetzt damit zu tun, nice ot.
3. Wenn eine firma auf 64 bit umstellt wollen die auch 64 bit programme haben, sonst könnten sie gleich bei 32 bleiben.

fakt ist 64 bit ist "state of the art". es gehen immer mehr 64 bit windows systeme in betrieb. ob du es glaubst oder nicht unter vista 64 und windows 7/64 dürfen 32 bit prozesse nicht mit 64 bit prozessen kommunizieren. darum ist ein 64 bit compiler nötig, nur weil du ihn vielleicht nicht brauchst, solltest du nicht davon ausgehen, dass andere dieses feature nicht ganz dringend brauchen.

würdest du noch ein neues projekt in delphi nur mit 32 bit unterstützung beginnen ohne zu wissen, ob es wirklich möglich ist in zukunft auf 64 bit umstellen zu können?

diese ungewissheit macht zukunftsplanung fast unmöglich, genau darum weden sich auch immer mehr leute von delphi ab. wer weiss den ob emba endlich die hunderste neue roadmap mal einhält. ich glaub nicht mehr dran.

und so mickerig sind diese drei sachen wohl kaum, 80% aller desktop programme haben z.B. auch ne explorer shell extension. die leute stehen alle auf dem schlauch und zwar schon seit jahren, nicht erst seit gestern.

Zitat:

Übrigens : Nehme alle Fragen zurück, sofern konkreter zwingender Einsatzgrund genannt wird.

hier sind mehr als genug genannt worden. :wall:

Zitat:

Microsoft empfiehlt sogar den Einsatz von 32-Bit Office (weil sie selbst den Markt für 64-Bit noch nicht als bereit ansehen)

und was bringt dir das, wenn deine kunden trotzdem umstellen und nicht bei dir kaufen, weil du kein 64 bit bieten kannst? :stupid:

@matthias:
etwas weiter oben ist die fehlerliste, die du haben wolltest. :)