Bibliothekspfade - DevExpress

[lxo]

Hallo,

mir ist heute aufgefallen, wenn ich die DevExpress-Pfade aus den "Tools" -> "Optionen" -> "Sprache" -> "Delphi" -> "Bibliothek" -> "Bibliothekspfad" entferne.
Das meine Projekte deutlich schneller erzeugt werden.

Debuggen kann ich trotzdem die DevExpress-Units.
Also kann ich beim installieren den Haken für "Source path" entfernen und "Debug Info" drin lassen? (siehe Screenshot)


Wozu stehen die da dann drin?
Würde doch nur Sinn machen wenn ich den DevExpress Code verändere.
Verstehe ich das richtig?
Oder was kann das noch für einen Sinn haben.

[lxo]

Und was mir noch aufgefallen ist.
Wenn ich die Pfade rausnehme aus den Bibliothekspfaden ist das erzeugen schneller aber die .EXE ist ca. 3-4 MB größer.

[himitsu]

Beim Kompilieren deiner Anwendung, werden da der PAS mit kompiliert?

Die Umgebungsvariablen DXLIB braucht man eigentlich auch nicht, aber ohne funktioniert der Hinzufügen-Button für ihre eigenen Bilder im ImageList-Editor nicht.


Wir kompilieren gegen deren Packages, da geht das noch schneller und ist noch kleiner (die EXE und die DLLs)
Allerdings nutzen wir auch nicht mehr deren schrottiges Setup, sondern kompilieren selbst.
(und ich weiß jetzt, warum sie behaupten das ginge nicht .... damit niemand sieht, was für ein Grauen die Compiliermeldungen ausgeben)

[lxo]

Wenn die Pfade im Bibliothekspfad sind dann kompiliert er auch die Devepxresss Units mit, ansonsten nicht.

Was soll das für ein Unterschied sein die Packages selber zu installieren statt den Installer zu verwenden?

[MyRealName]

Zitat:

Zitat von lxo (Beitrag 1549905)

Was soll das für ein Unterschied sein die Packages selber zu installieren statt den Installer zu verwenden?

Andere Compiler/Projekt-Einstellungen ?

[lxo]

Ok und zum Beispiel, welche Gründe hat das DevExpress mit anderen Einstellungen zu kompilieren?

[Uwe Raabe]

Zitat:

Zitat von lxo (Beitrag 1549905)

Was soll das für ein Unterschied sein die Packages selber zu installieren statt den Installer zu verwenden?

Die Setups der Hersteller installieren in der Regel für einen Standard-Nutzer. Sobald man aber z.B. mit mehreren Delphi-Versionen, unterschiedlichen Bibliotheksversionen und anderen Registry-Zweigen um diese in der IDE zu verwalten arbeitet, sind die Setups den Anforderungen nicht mehr gewachsen.

Beispiel: Bei TMS wird beim Update einer Bibliothek erstmal neben den Source-Dateien die alte Version aus allen Delphi-Versionen entfernt, allerdings nur im BDS-Zweig. Dann werden alle Delphi-Versionen auf den neues Stand gebracht. Nun verwende ich alte Delphi-Versionen in der Regel für die Pflege alter Programme, die nicht auf neue Versionen gezogen werden können oder sollen. Da muss/möchte ich aber auch weiterhin mit einer alten TMS-Bibliothek arbeiten. Ohne die Packages selbst zu installieren würde das nicht gehen. Ich denke bei DevExpress ist das ähnlich.

[MyRealName]

Zitat:

Zitat von lxo (Beitrag 1549912)

Ok und zum Beispiel, welche Gründe hat das DevExpress mit anderen Einstellungen zu kompilieren?

Diese Frage hört sich an wie : Warum würden die es denn falsch machen wollen, wenn ich doch den richtigen Weg nutze...

[himitsu]

Es sind keine besonderen Einstellungen. Fast alles Standard.
ABER,
* einige bestimmte Packages kompilieren nicht/nie (das wird ignoriert)
* bei zwei Packages sind die Imports im Arsch, weil die Units im "falschen" Verzeichnis liegen, eines anderen Packages, weswegen man dafür an den Suchpfaden rumpfuschen muß
* und es gibt sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr viele Kompilerwarnungen, die wir nicht sehen sollen (obwohl man sie leicht hätte beseitigen können, aber womöglich schauen die sie selbst nicht an)

[Sinspin]

Zitat:

Zitat von himitsu (Beitrag 1549915)

sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr viele Kompilerwarnungen

Die scheinen aber Sauber umschift zu werden wenn es nicht um Packages geht. Denn ich bekomme die nicht zu sehen wenn ich mit Quelltexten übersetzt, was ich permanent mache um ordentlich Reindebuggen zu können.

[himitsu]

Kompilierst du deren PAS wirklich selbst?
Normal werden ja deren vorkompilierte DCUs verwendet, oder die Packages.

OK, man kann ja im Setup sagen ob mit oder ohne Debuginfos.
Das Setup aber doppelt auszuführen und es sich kopieren zu müssen, um beide Versionen zu bekommen, ist aber auch eine bescheuerte Lösung.

Wir kompilieren es uns mit externen TDS und können dann entscheiden, ob mit oder ohne Debuginfos (also TDS im Verzeichnis oder nicht).

[lxo]

Zitat:

Zitat von MyRealName (Beitrag 1549914)

Zitat:

Zitat von lxo (Beitrag 1549912)

Ok und zum Beispiel, welche Gründe hat das DevExpress mit anderen Einstellungen zu kompilieren?

Diese Frage hört sich an wie : Warum würden die es denn falsch machen wollen, wenn ich doch den richtigen Weg nutze...

Ich möchte nur verstehen aus welchen Gründen sowas gemacht wird.
Weil ich selber keine Idee dazu habe.
Daher die Frage.

[lxo]

Noch mal zur ursprünglichen Frage.
Was macht es für einen Unterschied ob ich nun die Pfade in den Bibliothekspfaden behalte oder nicht?
Das einzige was mir auffällt, Debuggen kann ich in beiden Fällen, es ist langsamer beim kompilieren wenn die Pfade drin sind und die Größe der EXE.

[haentschman]

@Sinspin:

Zitat:

was ich permanent mache um ordentlich Reindebuggen zu können.

DevExpress debuggen...echt jetzt? Dafür gibt es spezielle Ärzte. :zwinker::lol:

Die blicken in ihrem eigenem Code nicht durch! Ich habe ein schwarzes Grid wenn ich eine normale Form drüberlege! :evil: Ticket hat nix gebracht. Video, Screenshots Quellcode der Form, des Aufrufes etc...Die wollen nicht! :evil:

PS: Ich bin nicht der Einzige!
https://supportcenter.devexpress.com...d-black-screen

PS: Das mußte mal raus...:P

[himitsu]

Wie machen das leider zu oft.
DevExpress, pgDAC, ....

[Sinspin]

Zitat:

Zitat von haentschman (Beitrag 1549922)

DevExpress debuggen...echt jetzt? Dafür gibt es spezielle Ärzte. :zwinker::lol:

:nerd:

Zitat:

Zitat von haentschman (Beitrag 1549922)

Die blicken in ihrem eigenem Code nicht durch! Ich habe ein schwarzes Grid wenn ich eine normale Form drüberlege! :evil: Ticket hat nix gebracht. Video, Screenshots Quellcode der Form, des Aufrufes etc...Die wollen nicht! :evil:

Denen scheint da was ein bisschen über den Kopf gewachsen zu sein.
Aber man muss schon sagen das die Grid Komponente auch absolut irre ist.

Ich habe denen schon massig Bugreports mit Demoprogramm geschickt und als Antwort nur bekommen das es so bleibt wie es ist.
Ein besonders harter Fall ist ein Grid in einem Dialog in einer DLL, zeigt man das Fenster einfach an funktioniert der Grid. Bettet man das Fenster in das Hauptprogram ein, gehen dynamische Elemente im Grid nicht mehr anzucklicken.

Sieht so aus als haben die aktuell keinen Delphientwickler, oder jedenfalls keinen mehr von denen die das alles mit aufgebaut haben. Die sind vermutlich alle in der Ukraine SFU mit Kreuz drauf. Was für eine Verschwendung!

Der liebe schwarze Grid. Habe da auch einen Kandidaten der einfach nicht weichen will. Zum Glück ist der nur sichtbar wenn man schon an anderer Stelle die Fehlersuche aktiviert hat.
Das muss irgendwas mit Aktualisierungszeitpunkt der Daten sein und der Fähigkeit bestimmte Events zu dem Zeitpunkt zu verarbeiten.