dxGDIPlusClasses überall in uses injiziert

**dummzeuch**

Hallo,

danke schion mal für die Info, dass es eine devExpress Unit ist.

Ich frage mich jetzt halt, wie die da überall rein kam.
Da er eigentlich nur die Bilder in Standard VCL TImage Komponenten
austauschen musste halte ich es für unplausibel, dass er in alle diese
Forms (müssten 3-5 Forms gewesen sein) jeweils ein devExpress Control
irgend einer Art platziert gehabt hätte.

Achtung: Reine Spekulation, da ich DevExpress nie verwendet habe:

Ich kenne das von TeeChart, welches auch in neueren Versionen eine ähnliche Datei hinzufügt, damit zur Ausgabe GDI+ verwendet wird.

Es könnte sein, dass DevExpress denselben wie auch immer gearteten Mechanismus in der IDE implementiert hat, der automatisch diese Unit hinzufügt, wenn in einem Formular TImage verwendet wird.

Eine mögliche Lösung, ohne auf dem Rechner des Kollegen, der DevExpress installiert hat, dieses zu deinstallieren, wäre ein Unit-Alias für die Projekte, die kein DevExpress verwenden:

dxGdiPlusClasses=Controls

Das würde dazu führen, dass die Projekte auch ohne DevExpress compilieren, wenn durch Unachtsamkeit des Kollegen diese Unit eingefügt wurde. Problem dabei ist allerdings, dass wenn doch irgendwann mal DevExpress verwendet werden soll, der Mechanismus ausgehebelt wird und man sich dumm und dämlich sucht, wenn dan Fehler auftreten.

Prinzipiell halte ich es für besser, wenn der Kollege vor einem Commit darauf achtet, dass er keine Mist eincheckt. Ich erwarte von meinen Mitarbeitern jedenfalls, dass sie dies tun. Das dauert ein paar Sekunden, aber die Zeit ist gut investiert, denn sie verhindert, dass andere evtl. Stunden damit verschwenden, solche Compilefehler zu beheben.

**TurboMagic**

Danke dummzeuch für diesen Hinweis!

Und ja: besser nix unpassendes einchecken ist gut.
Dazu müsste man aber, falls das automatisch eingefügt wird, einen Diff aller geänderten Units for
dem Einchcken machen nur weil deExpress (wenn die was automatisch tun) keinen besseren Lösungsansatz
gefunden hat der Projekte welche deren Controls nicht benutzen in Ruhe lässt!

**himitsu**

Ja, DevExpress, da werden öfters Units eingebunden, wenn man ein Formular bearbeitet. (Units der Skins, GridFilter, GraphicZeugs, ...)
Viele davon sind garnicht "direkt" nötig, aber wird irgendwas aus der Unit als Subkomponente "eventuell" verwendet oder es könnte sein, dass es verwendet würde ... blubb isses drin.

immer wiederkehrendes Problemchen:

https://supportcenter.devexpress.com...nents-are-used

https://supportcenter.devexpress.com...or-units-used/
...

Es gibt da irgendein Package, wo der meiste Code für dieses automatische Einfügen drin ist (weiß grad nicht mehr welches es war), aber wenn dein Kollege das in seiner IDE deinstalliert/deaktiviert, dann passiert sowas fast nicht mehr. (der Support von DevExpress kann ihm da eventuell helfen)

Vermutlich kannst diesen Eintrag ohne Probleme aus den Uses entfernen.

Ich vermute mal, du hast sonst keine weiteren cx/dx-Units im Uses, wenn bei dir DevExpress nicht installiert ist?

**Delphi.Narium**

Auch wenn ich nix vom oben genannten nutze:

Mein Vorgehen unter Delphi 7 ist:

In einem Projekt sind in der IDE nur die Packages aktiv, die ich für dieses Projekt benötige.

Wenn der Kollege mit DevExpress also vor der Bearbeitung Deines Projektes in seiner IDE alles von DevExpress deaktiviert, sollte das Problem nicht mehr auftreten. (Bei Delphi 7 muss man dann halt unter "Komponenten/Packages installieren" halt ein paar Häkchen wegmachen.)

Wenn er dann eines seiner Projekte nutzt, muss er halt die Packages von DevExpress aktivieren.

Das dürfte insgesammt dann weniger Aufwand sein, als ein Diff vorm Commit, Unit-Alias, der vergessen werden könnte oder sonstige "Krücken", um irgendwie an dem Problem vorbeizukommen.

Ob's bei aktuellen Delphis auch so einfach ist, wie in meinem ollen Delphi 7, weiß ich nicht.

**himitsu**

Nja, das "Package Installieren"-Fenster hat eine geheime Funktion.

machst du das, während ein Projekt geladen ist, dann werden die deaktivierten Packages im Projekt (DPROJ) gespeichert
machs es, während kein Projekt geladen ist, dann wird es in der Registry gespeichert
Es gibt aber unten auch noch den Haken "als Standard für neue Projekte",
da sollte es auch in der Registry landen (und vielleicht nicht zusätzlich im geöffneten Projekt gespeichert)

Zumindestens ist es in XE noch so, aber vermutlich wurde das nicht geändert (in neueren Delphis noch nicht dazu gekommen es machen zu wollen).

Aber wenn TurboMagic das Projekt dann speichert, dann könnte es sein, dass diese Einstellung wieder aus der DPROJ rausfliegt, weil sein Delphi diese Packages nicht kennt und sie somit nicht deaktivieren kann.

Wenn man das Projekt wechselt/lädt, soger rechts in einer Projektgruppe, dann werden diese Packages jeweils (de)aktiviert.

**Uwe Raabe**

Zitat von himitsu:

Es gibt aber unten auch noch den Haken "als Standard für neue Projekte",

Den gibt es schon eine ganze Weile nicht mehr. Bleibt also nur die Möglichkeit, dies ohne geöffnetes Projekt einzustellen.

Projekt-bezogene Design-Packages sind sowieso eine Wissenschaft für sich.

**stOrM**

Ich hab jetzt hier nicht alles gelesen aber soweit mir bekannt ist, kommt das ganze noch aus Zeiten wo die IDE nativ noch keine PNG Images unterstütze. Devexpress hat dann seinerseits was eigenes gebastelt und sind dabei geblieben. Sprich sobald es um Images geht (png, jpeg usw. wird die Unit sofern man die Devexpress Komponenten benutzt automatisch eingebunden.)

Lt. Devexpress kann man dies unterbinden in dem man die Datei <DevExpressInstallationFolder>\ExpressCore Library\Sources\cxVer.inc editiert. Die Vorgehensweise wäre:

//{$DEFINE DXREGISTERPNGIMAGE} Save the file and run our <DevExpressInstallationFolder>\Setup\Setup.exe file in Recompile (not Repair) mode.

Solltte dies nicht gehen dann:

Comment out {$DEFINE DXREGISTERPNGIMAGE} in the dxGDIPlusClasses unit

Run our VCL Product Setup in Recompile mode.

Nachträglich ohne komplettes recompile der Suite wirds wohl nicht so einfach gehen. Wichtig ist vorher wirklich alles von Devexpress zu entfernen sonst scheint es Probleme zu geben bzw. funktioniert die Methode.nicht.

Zum restlosen entfernen wäre

hier die entsprechende Info wohl hilfreich.

**TiGü**

Zitat von TurboMagic:

Und ja: besser nix unpassendes einchecken ist gut.
Dazu müsste man aber, falls das automatisch eingefügt wird, einen Diff aller geänderten Units for
dem Einchcken machen...

Aber das sollte doch Standard sein!

Sonst commiten die Entwickler ja sonst irgendetwas, was vielleicht gar nicht zum Feature oder Bugfix dazugehört.

**dummzeuch**

Zitat von TurboMagic:

Und ja: besser nix unpassendes einchecken ist gut.
Dazu müsste man aber, falls das automatisch eingefügt wird, einen Diff aller geänderten Units for
dem Einchcken machen

Also zumindest ich schaue mir das Diff aller Units an, die ich committe. Geht ja mit TortoiseSVN + BeyondCompare auch einfach. Ich drehe da auch immer wieder mal automatische Änderungen der IDE in den Uses-Listen, DFMs oder dproj-Dateien zurück oder mache auch manuelle Änderungen, die ich so gar nicht gewollt (oder vergessen) habe, rückgängig.
(Änderungen an den Hex-Codes von Bitmaps in den DFMs sind total nervig, da die schon durch andere Bildschirmauflösungen oder auch nur andere Grafiktreiber ausgelöst werden können. Die mache ich, wenn es nicht absichtliche Änderungen waren, komplett rückgängig. Das macht es auch einfacher, echte Änderungen zu erkennen.)

Aber ich committe auch immer ziemlich kleinteilig, also auch mal nur eine Zeile, wenn es keine Abhängigkeiten zu anderem Sourcecode gibt. Im Gegensatz zu meinen Kollegen, denen ich nicht abgewöhnen kann, erst nach tagelangen oder gar wochenlangen Änderungen zu committen. Die beschweren sich dann immer über Merge-Konflikte. Passiert mir nur selten und wenn, sind sie leicht zu beheben. Aber da habe ich kein Mitleid. Selbst schuld.

**TiGü**

Zitat von dummzeuch:

Aber ich committe auch immer ziemlich kleinteilig, also auch mal nur eine Zeile, wenn es keine Abhängigkeiten zu anderem Sourcecode gibt. Im Gegensatz zu meinen Kollegen, denen ich nicht abgewöhnen kann, erst nach tagelangen oder gar wochenlangen Änderungen zu committen. Die beschweren sich dann immer über Merge-Konflikte. Passiert mir nur selten und wenn, sind sie leicht zu beheben. Aber da habe ich kein Mitleid. Selbst schuld.

OT:
Ja, schreckliche Angewohnheit. Ich kämpfe da auch gegen Windmühlen.
Ich glaube, dass ist aber auch viel Faul- und Gewohnheit dabei.
Die wollen einfach nicht mehrfach das Commit-Fenster in TortoizeSVN öffnen. Zuviel Geklicke.

Oft ist ein SVN-Revsionseintrag fünf verschiedene Sachen (New, Bug, Feature, Übersetzung...) und 5 bis 12 Units angepackt.

Ob hier Gewalt eine Lösung ist? So wie bei den Yakuza?

https://de.wikipedia.org/wiki/Yubitsume