Delphi XE2

[hanspeter]

Hallo zur Zeit versuche ich ein kommerzielles Projekt von D2005 auf XE2 zu portieren. Ich habe insgesamt 4 XE Installationen. Jede macht anderer Probleme.
Daheim habe ich eine Installation unter Win7/64 laufen. Hier funktioniert der Debugger nicht.
Die möglichen Haltepunkte werden als blauer Punkt dargestellt. Ein gesetzter Haltepunkt wird korrekt dargestellt und ist auch in der Haltepunktliste im Debugfenster. Sobald ich das Programm starte, sind alle Haltepunkte weg und die gesetzten sind als ungültig markiert.
Auf der gleichen Maschine habe ich XE2 in einer VM mit XP/SP2 laufen. Öffne ich hier das gleiche Projekt ohne eine Änderung, dann funktioniert der Debugger.
Allerdings bin ich in einer VM (VMWare) mit der Laufzeit nicht so glücklich.
Auf dem Notebook habe ich XE2 und Win7 Home/32 am Laufen. Hier scheint es zu laufen, ich habe allerdings noch nicht viel damit gemacht.
Das Wechseln zwischen Code und Designansicht dauert bei größeren Programmen nach einer Codeänderung über 10 sec.
In der Firma läuft XE2 unter XP.
Hier nutze ich XE2 täglich und ärgere mich über ständig andere Zicken.
Ich habe mich ja schon daran gewöhnt, das ich beim Wechsel von Code in Designansicht Kaffee holen kann. Mal sind plötzlich alle Haltepunkte weg. Wildes Klicken auf Bereinigen/Erzeugen bringt diese dann irgendwann wieder.
Problemlos ist der Programmstart, mit dem Schalter "erzeugen" in der Projektverwaltung.
Starte ich mit F9 dann kommen sehr häufig "interne" Fehler. (z.Zt. [DCC Fataler Fehler] Settings_Form_Unit.pas(60): F2084 Interner Fehler: AV0483E50E-RF724800E-0
Hat wer XE2 stabil am Laufen oder eine Idee wie man das Teil stabil bekommt?
Den "Service" von Embarcadero habe ich schon vor Tagen per email angeschrieben, aber bis jetzt noch keine Reaktion.
Hat wer eine Idee, wie man wenigstens das Debugger-Problem in den Griff bekommt oder funktioniert XE2 unter einem 64 bit Betriebssystem nicht richtig?

Gruß
Peter

[Dawn87]

Bezüglich der internen Fehler hilft es oft mal alle DCUs zu löschen. Des Weiteren läuft der Debugger hier unter Windows 7 64Bit bisher einwandfrei.

[SvB]

Ich habe XE2 in eine VM mit Win7 Pro x64 laufen. Habe zwar noch nicht viel gemacht (außer mit den Demos gespielt), aber bisher noch keine Probleme festgestellt.

Betreffs dem Umschalten von Code zu Form habe ich mal vor einiger Zeit mit XP das Problem mit XE gehabt und dort hat Andy eine Anpassung im IDE Fix Pack vorgenommen. Seit dem läuft das relativ gut, solltest Du mal probieren.
Für XE2 gibt es hier auch schon ein "develper snapshot".

Hast Du das Update 1 für XE2 schon installiert?

[jbg]

Zitat von SvB:

Betreffs dem Umschalten von Code zu Form habe ich mal vor einiger Zeit mit XP das Problem mit XE gehabt und dort hat Andy eine Anpassung im IDE Fix Pack vorgenommen. Seit dem läuft das relativ gut, solltest Du mal probieren.

Hat er schon ausprobiert, wobei das eine frühe Version von IDE Fix Pack für XE2 war, bei der die originalen Compiler Caches noch aktiv waren (also 2 mal Verzeichnisse Cachen und so). Der Ressource-String Ring-Puffer war da aber schon drinnen, der bei dir die Geschwindigkeitssteigerung bewirkte.
Man könnte nun natürlich die IDE mit der IDE debuggen und zu dem Zeitpunkt an dem es lange dauert, anhalten, auf den Hauptthread wechseln und den CallStack betrachten. Das hat letztes mal auch zum Ziel geführt (leider passen seit dem Update 1 die jdbg Dateien nicht mehr zu den bpl Dateien. Da heben sie wieder mal beim Installer geschlampt).

[SvB]

Alles klar, dann ist das nicht ganz so einfach.

[hanspeter]

Erst mal Danke für die Tips.
Die häufigen internen Fehler kommen nur, wenn man mit F9 startet.
Ich verwende seit Tagen die Kombination Bereinigen - Neu erzeugen. Hier traten noch nie interne Fehler auf.
Das Problem ist, das ich in einem Auftrag produktiv sein muss und keine Zeit habe, mich mit den Problemen und Unzulänglichkeiten des Entwicklungssystems zu beschäftigen.
Ich hatte angenommen, da XE2 noch den alten 32 bit Compiler hat, das das die wohl vorerst letzte stabile Version des 32 bit Entwicklungssystems ist und ein Update von 2005 empfohlen.
Ich warte noch die Reaktion des "Support-Services" von Embarcadero ab und werde dann wohl auf XE zurückgehen müssen.

Gruß
Peter

[BlackSeven]

Ich kann die internen Compiler-Fehler bestätigen. Diese treten nur beim Comilieren (F9), nicht beim Erzeugen des
Projekts auf. Leider habe ich bisher noch keine Lösung gefunden. Unter XE läuft alles stabil.

[jbg]

Der Compiler Engineer von Embarcadero, Barry Kelly, hat einen möglicherweise interesanten Blog-Eintrag. Vielleicht hilft es wenn man die Compiler Caches abschaltet:

Code:

SET DCC_CACHE_DISABLE=SearchUnitNameInNS,FileSystem,UnitFindByAlias,GetUnitOf

(wobei man den FileSystem Cache wohl besser aktiviert lassen sollte, da sonst die Kompilierung in die Stunden gehen dürfte)

[Patito]

Zitat von jbg:

Der Compiler Engineer von Embarcadero, Barry Kelly, hat einen möglicherweise interesanten Blog-Eintrag. Vielleicht hilft es wenn man die Compiler Caches abschaltet:

Code:

SET DCC_CACHE_DISABLE=SearchUnitNameInNS,FileSystem,UnitFindByAlias,GetUnitOf

(wobei man den FileSystem Cache wohl besser aktiviert lassen sollte, da sonst die Kompilierung in die Stunden gehen dürfte)

Hm. Klingt nicht so als ob der Compiler zur Zeit in guten Händen ist...
Frage mich nur warum der Kopf des Chief-Scientisten nicht schon lange gerollt ist?!?

Naja, aber auch mit Delphi 7 muss man beim compilieren aufpassen.
Sobald man eine größere Projektgruppe hat (mit installierten Packages, ...) gibt es
da auch schnell Probleme.

Statt F9 mach ich eigentlich für alles immer einen kompletten Rebuild.
Und falls man installierte Packages kompiliert ist es oft nötig danach die IDE neu zu starten.

Ich vermute mal ganz grob, dass der "Aktueller Pfad" Probleme macht und sich
je nachdem welcher Pfad gerade aktuell ist die Reihenfolge der Verzeichnisse in
denen gesucht wird unvorhergesehen ändern kann.
(Wenn z.B. ein Projekt die Units eines Packages mit anderen Optionen in ein eigenes Temp-Verzeichnis
compiliert hat - und dann plötzlich dieses Verzeichnis im Suchpfad vorrang vor dem Library-Path hat)
?!??
wie wird denn der "Aktuelle Pfad" vom Compiler intern behandelt

[hanspeter]

Ja den Effekt habe ich bei der Componentenentwicklung häufiger.
Wenn ich nicht sorgfältig alle Reste einer z.B. umbenannten Komponente lösche, dann bekommt man Probleme.
Zuletzt bin ich darübergestolbert, wenn man einen Componentennamen verwendet, der irgendwo schon verwendet aber nicht installiert ist. Bei mir war das der Name TDatagrid (gibt es wohl in Midas)
Hier streikt die Installation einfach ohne ersichtlichen Grund - es geht einfach nicht.
Dringender ist jedoch mein Problem mit dem nicht funktionsfähigen Debugger.
Ich habe jetzt einen Tip gefunden, das es mit Eurekalog zusammen hängen könnte.
Ich hatte vor längerer Zeit die Demoversion auf dem Rechner und diese aber schon lange deinstalliert.
Insgesamt ist die Situation mehr als ärgerlich.
Wenn ich Geld für eine neue Version ausgebe, dann erwarte ich eigentlich das sich die Situation verbessert und nicht das ich wieder wie zu Zeiten von D8 an den Werkzeugen basteln muss.

Peter