dxGDIPlusClasses überall in uses injiziert

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