Updates 3, 4, und Boost Library für RAD Studio 2009 ist da

[Uwe Raabe]

Zitat von jbg:

Meine Meinung: Auf InstallAware pfeifen und besser auf InnoSetup umsteigen.

Ganz deiner Meinung!

Allerdings hat Nick Hodges mal gesagt, daß InnoSetup nicht den Anforderungen entsprechen würde, die CodeGear voraussetzt. Ganz offensichtlich tut InstallAware das faktisch aber auch nicht. Fragt sich, was der einfachere Weg ist: InnoSetup aufbohren oder InstallAware brauchbar machen.

Uwe Raabe

[Die Muhkuh]

Gibt ja noch andere Installer.

NSIS, InstallShield

Führe das Update gerade auf dem Laptop durch, da rödelt das aber auch schon seit gut 30 Minuten.

[Bernhard Geyer]

Zitat von jbg:

Meine Meinung: Auf InstallAware pfeifen und besser auf InnoSetup umsteigen. Ist dann zwar nicht mehr MSI, aber wer brauch das schon Im Notfall muss man eben ein MSI Pakte drum herum schnürren. Machbar ist alles.

Ich denke Codegear brauch MSI wenn es noch irgendwelche MSDN-Dokus von MS einbinden will (darf). Nach dem Ableben von C#-Builder und VCL.NET/WinForms ist das zwar nicht mehr so wichtig

[mkinzler]

Zitat:

Folgendes habe ich herausgefunden: Der Update 3 Installer schaut auf das Creation/Modifydate der Dateien. Unterscheidet sich eine Datei, dann wird das gesamte Datei-Paket nicht installiert. So geschehen bei mir mit den IDE BPLs (Hab halt mal im HxD auf Speichern gedrückt nach dem ich Änderungen wieder zurückgenommen hatte) und bei anderen sind die RTL/VCL Quellcodes nicht mehr mit den Debug-Units synchron. Da hat der Installer einfach die Sourcen nicht aktualisiert.

It not a bug, its a feature
http://blogs.embarcadero.com/nickhod...9/05/29/39245/

[jbg]

Zitat von mkinzler:

It not a bug, its a feature

Von wegen. Nick Hodges verkauft es einem nur als Feature. Bei *.pas Dateien würde ich es ja noch verstehen, aber wenn es schon alleine ausreicht das Dateidatum der coreide120.bpl zu ändern, dann stinkt das gewaltig nach "nicht erwarteter Reaktion des Installers". Vor allem wenn dann nicht nur diese einzelne veränderte Datei ausgelassen wird, sondern gleich das gesamte Dateibündel. Wenn mal also z.B. die Forms.pas ändert oder einfach nur neu speichert, dann werden auch Controls.pas, Classes.pas, System.pas, ... nicht mehr aktualisiert.

[mkinzler]

Zitat:

Von wegen.

So sehe ich das auch. ist vielleicht in meinem Beitrag nicht richtig ersichtlich.

[xZise]

Zitat von 0xF30FC7:

Weiß jemand ob der leidige Fehler beim Debuggen unter Windows 7 gefixt wurde?

Würde mich auch mal interessieren. Wobei ich befürchte, das dies nicht so wichtig ist, da W7 ja kein Produktivsystem ist.

MfG
xZise

[divBy0]

Auf meinem Notebook mit Windows Vista 32bit, funktioniert D2009 nach den Updates noch..., nur auf meiner Arbeitskiste unter Vista 64 gehts nicht mehr...

[Daniel]

Zitat von divBy0:

Auf meinem Notebook mit Windows Vista 32bit, funktioniert D2009 nach den Updates noch..., nur auf meiner Arbeitskiste unter Vista 64 gehts nicht mehr...

Die momentan wahrscheinlichste Erklärung ist, dass die Zeitstempel von einigen Deiner Delphi-Programmdateien verändert wurden und somit der Installer beim Update diese Dateien nicht überschrieben hat. Das wiederum hat zur Folge, dass die "Hälfte" Deiner Delphi-Installation "alt" ist und die andere "Hälfte" neu.

Nick Hodges schreibt im seinem Blog, dass Du jetzt zwei Schritte machen solltest:

(1) Über die Systemsteuerung die Delphi-Installation reparieren. Dies führt dazu, dass Dein Delphi wieder auf den Stand der Ursprungsinstallation zurückgesetzt wird.
(2) Danach dann das Update #3 installieren. Dieses findet jetzt die erwartete Installation vor und am Ende solltest Du wieder ein lauffähiges Delphi haben.

[xZise]

Zitat von xZise:

Zitat von 0xF30FC7:

Weiß jemand ob der leidige Fehler beim Debuggen unter Windows 7 gefixt wurde?

Würde mich auch mal interessieren. Wobei ich befürchte, das dies nicht so wichtig ist, da W7 ja kein Produktivsystem ist.

MfG
xZise

Naja egal warum, aber der Fehler ist nicht behoben

MfG
xZise