dxGDIPlusClasses überall in uses injiziert

[TurboMagic]

Hallo,

ein Kollege und ich arbeiten gemeinsam in einer Projektgruppe.

Nach dem letzten Zusammenführen wollte ich das Projekt, an dem er Änderungen
vorgenommen hat, compilieren und habe festgestellt, dass in die interface uses
aller Units die er zuletzt bearbeitet hat (die letzte Aufgabe war das Ersetzen
eines Logos auf diversen Formularen) eine Unit dxGDIPlussClasses hinzugefügt
wurde die ihc nicht habe.

Er ist auch noch in einem Projekt mit einer anderen Abteilung für das diese
auf seinem PC wohl weitere Drittanbieter Komponenten installiert haben.

Frage: woher kommt die Unit und warum ist diese ohne sein aktives Zutun in
alle bearbeiteten Units eingefügt worden?

Grüße

TurboMagic

[Bernhard Geyer]

Er kanns doch kompilieren?
Dann soll er doch mal schauen in welchen Packages/Verzeichnis die Datei bei im zu finden ist.

Dann kann man weiter schauen was ist.
Es gibt Möglichkeiten das Units sich so Registrieren um das o.g. verhalten zu verursachen.

[hoika]

Hallo,
der der kompilieren kann:
die Datei dxGDIPlusClasses.pas umbenennen, Rebuild,
und man findet schnell die Units, die diese Unit eingebunden haben.

[dummzeuch]

Zitat:

Zitat von TurboMagic (Beitrag 1464598)

Frage: woher kommt die Unit und warum ist diese ohne sein aktives Zutun in
alle bearbeiteten Units eingefügt worden?

dxGdiPlusClasses ist eine Unit aus DevExpress

https://stackoverflow.com/questions/...ses-dcu-delphi

[TurboMagic]

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.

Es ist ja auch nur diese generische Unit in den Uses zu finden und entfernt
man die compiliert es. Daher die Überlegung, dass da temporär ein devExpress
Control in der betreffenden Form war, wieder entfernt wurde und dabei diese
Unit nicht mehr aus den Uses entfernt wurde.

Nur wie gesagt halte ich das für unplausibel. Wenn's bei einer Form gewesen
wäre hätte er evtl. mal testhalber ein devExpress Control drauf gezogen gehabt
und wieder gelöscht. Aber bei mehreren Forms? Unplausibel.

Also wie kann diese Unit noch in die Uses kommen? Manuelles hinzufügen ist
auch unplausibel.

[dummzeuch]

Zitat:

Zitat von TurboMagic (Beitrag 1464611)

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.

[TiGü]

Zitat:

Zitat von TurboMagic (Beitrag 1464617)

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.

[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. :stupid:

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

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1464628)

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.

[dummzeuch]

Zitat:

Zitat von TurboMagic (Beitrag 1464617)

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:

Zitat von dummzeuch (Beitrag 1464637)

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? :twisted:
https://de.wikipedia.org/wiki/Yubitsume

[himitsu]

Du kannst bei SVN und Git auch Commit/Push-Events registrieren.
Werden z.B. beim Commit solche Dinge gefunden, dann knallst denen automatisiert das um die Ohren und sie müssen es erst anpassen.

:stupid:



Man kann zwar auch automatisch Replaces damit bauen, aber das ist ja auch keine Lösung ... ohne Rückmeldung den Code zu verändern.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1464648)

Werden z.B. beim Commit solche Dinge gefunden, dann knallst denen automatisiert das um die Ohren und sie müssen es erst anpassen.

Ich fürchte, daß wird die Häufigkeit der Commits nur noch weiter reduzieren. Insbesondere, wenn devExpress die Units immer wieder in die uses-Clause schreibt.

Zitat:

Zitat von dummzeuch (Beitrag 1464637)

Also zumindest ich schaue mir das Diff aller Units an, die ich committe. Geht ja mit TortoiseSVN + BeyondCompare auch einfach.

Das finde ich so toll bei der TortoiseHG Workbench: da sieht man die Änderungen direkt und kann die ungewollten Teile einfach aus dem Commit ausschließen (Häkchen weg - fertig). Das hat nebenbei noch den Vorteil, daß man die aktuelle Source-Datei dadurch gar nicht ändert und Delphi nicht meckert, wenn es die geänderten Dateien laden muss - und das womöglich nicht kann, weil noch ein abhängiges Form geöffnet ist.