IDE FixPack 3.5 (2007-XE) (2010-09-12)

[holliesoft]

Hi,

vielen Dank für Dein IDE Fixpack. Respekt vor Deiner Arbeit. Hab' eben mal den Donate-Button auf Deiner Homepage benutzt (sollte jeder machen, der dieses tolle Stück Software benutzt, die das fixt, was Embarcadero nicht hinbekommt ;-))

viele Grüße
Patrick

[jbg]

Zitat:

Zitat von holliesoft (Beitrag 1048989)

sollte jeder machen, der dieses tolle Stück Software benutzt

Aber wehe wenn die Donations mein Gehalt übersteigen.

Zitat:

was Embarcadero nicht hinbekommt

Die Optimierungen hatte sie zu Delphi 2009 Entwicklungszeiten abgelehnt, da sie die Symptome beheben aber nicht die Ursachen. Meine Meinung ist, dass ich lieber 1 Million LoadResString Aufrufe schnell verarbeite, als den gesamten Quellcode nach Resourcestrings zu durchsuchen und die unnötigen Aufrufe zu eliminieren, was viele Manntage verschlingt und deswegen nicht gemacht wurde, was ich wiederum verstehe.

[himitsu]

Zitat:

Zitat von jbg (Beitrag 1048994)

..., als den gesamten Quellcode nach Resourcestrings zu durchsuchen und die unnötigen Aufrufe zu eliminieren, was viele Manntage verschlingt und deswegen nicht gemacht wurde, ...

Noch 350 Tage bis XE2 ... die zwei/drei Tage mehr fallen da nun auch nicht auf. :roll:

[hanspeter]

Kann es sein, das sich IDE Fixpack und GExpert nicht vertragen.
Wenn ich mit GExpert eine Componente austausche z.B. von Panel auf TADVPanel, kommt eine Speicherschutzverletzung im IDE-Fixpack?

Gruß Peter

[jbg]

Welche Version von GExperts und Delphi verwendest du? (damit ich es nachstellen kann)

[hanspeter]

Zitat:

Zitat von jbg (Beitrag 1086062)

Welche Version von GExperts und Delphi verwendest du? (damit ich es nachstellen kann)

Gexpert 1.34 , Delphi 2010.
DEer Bug kommt wohl bei jedem ReplaceComponents

Gruß Peter

[jbg]

Der Fehler tritt bei mir (leider) nicht auf.

Delphi 2010 Prof. DDevExtensions 2.3 + GExperts 1.34 (Win7 64 Bit)
Auch wenn ich die Ladereihenfolge der beiden Plugins ändere tritt der Fehler nicht auf.

1. Delphi starten
2. Neue VCL Form Anwendung
3. Button auf Formular
4. Rechtsklick auf Button
5. Replace Component
6. TEdit eingeben
7. OK drücken

[MaBuSE]

Hallo,
zuerst möchte ich mal Danke sagen für Deine Tools rund um Delphi.
Wir verwenden Idefix, DDevExtentions und DelphiSpeedUp bei und im Haus mit Delphi 7, 2007 und XE und sind sehr zufrieden.

Ich habe noch einen kleinen Bug in der IdeFix 4.5 gefunden.

Beim Delphi XE Start werden einige Dateien in %TEMP% erstellt und csc.exe aufgerufen um daraus eine *.dll Datei zu erzeugen.
(*.cs, *.out, *.err, *.cmdline, *.tmp und *.dll Dateien)
Diese Dateien werden nach der Benutzung der *.dll Dateien wieder gelöscht.

Aus irgend einem Grund werden die dynxmlserializer.8.0.15_TaskMetadata.cs und dynxmlserializer.8.0.15_TaskMetadata.dll Dateien nicht in %TEMP% erzeugt, sondern in %LOCALAPPDATA%\IDEFixPack erstellt und nicht wieder gelöscht.

Wird Delphi beendet und erneut gestartet, so bleibt Delphi bei uns im SplashScreen beim Laden der DDevExtentions 2.5 hängen.

Wenn der Delphi Prozess via TaskManager gekillt wurde. Und die Dateien in %LOCALAPPDATA%\IDEFixPack wieder gelöscht wurden lässt sich Delphi wieder starten.

Auf einem lokalen PC tritt der Fehler bei uns nicht auf. Der Fehler tritt nur in unserer virtualisierten Welt auf.

Folgende Umgebung verwenden wir:

• Embarcadero RAD Studio XE Enterprise
• Embarcadero License Server
• Windows 7 64 bit

in einer

• VM auf ESX Server 4.1
• Citrix Xen Desktop 5
• AppSense
• provisionierte VHDD (Citrix provisioning Services) ReadOnly im Cached Mode

Die Daten in %LOCALAPPDATA%\IDEFixPack werden auch auf dem lokalen PC angelegt, aber dort stört sich Delphi nicht daran ;-)

Ich hoffe diese Infos helfen Dir das Problem zu lösen.

Im Moment haben wir den Workarround, das %LOCALAPPDATA%\IDEFixPack Verzeichnis vor jedem Delphi Start zu löschen.

Danke und viele Grüße
MaBuSE

[jbg]

Zitat:

Zitat von MaBuSE (Beitrag 1135541)

Aus irgend einem Grund werden die dynxmlserializer.8.0.15_TaskMetadata.cs und dynxmlserializer.8.0.15_TaskMetadata.dll Dateien nicht in %TEMP% erzeugt, sondern in %LOCALAPPDATA%\IDEFixPack erstellt und nicht wieder gelöscht.

Der Grund ist, dass dies das Cache-Verzeichnis ist, so dass der CSC.EXE Aufruf ausbleiben kann. Deswegen werden sie nicht gelöscht. (Ab XE2 ist dieser Cache nicht mehr notwendig, da Embt meinen Vorschlag mit dem Vorkompilieren und Signieren der dynxmlserializer.dll aufgegriffen hat)

Zitat:

Wird Delphi beendet und erneut gestartet, so bleibt Delphi bei uns im SplashScreen beim Laden der DDevExtentions 2.5 hängen.

DDevExtensions bleibt da nicht hängen, es ist nur das letzte IDE Plugin, das geladen wurde und seinen Text im Splashscreen hinterlassen hat.


Man kann diesen IDEFixPack Cache abschalten, indem man die Umgebungsvariable "IDEFixPack.DisabledPatches" auf den Wert "Start.XmlSerializer" (beides ohne Quotes) setzt.

Aber dass das Problem nur in der VM auftritt ist schon komisch. Bei meinen VMs (VMWare+WinXP32/Vista64) habe ich da keine Probleme.

[MaBuSE]

Zitat:

Zitat von jbg (Beitrag 1135552)

Man kann diesen IDEFixPack Cache abschalten, indem man die Umgebungsvariable "IDEFixPack.DisabledPatches" auf den Wert "Start.XmlSerializer" (beides ohne Quotes) setzt.

Danke, das werde ich nachher ausprobieren.

Zitat:

Zitat von jbg (Beitrag 1135552)

Aber dass das Problem nur in der VM auftritt ist schon komisch. Bei meinen VMs (VMWare+WinXP32/Vista64) habe ich da keine Probleme.

Wir haben einen Pool aus vielen gleichen VMs, der auf mehreren Servern gehostet wird.
Bei jeder Anmeldung bekommt der Benutzer (Entwickler) eine andere VM.
Die Umgebung des Benutzers wird durch AppSense zur Verfügung gestellt.

Das bedeutet, es existiert ein virtuelle Layer zwischen dem OS und der App. Vermutlich liegt da das Problem, z.B. dass Delphi es sieht, aber nicht darauf zugreifen kann.

Wir stellen gerade von D2007 auf XE um. Das wird bei über 40 Entwicklern auch eine Weile dauern. Bis wir dann soweit sind auf was Neueres umzusteigen gibt es bestimmt schon XE5 ;-)

Danke und
Viele Grüße
MaBuSE