Delphi 10.1 Berlin Update 1 verfügbar

[Uwe Raabe]

Zitat:

Zitat von sh17 (Beitrag 1348118)

Es wäre schön, wenn Delphi diesbezüglich mal einen Paradigmenwechsel in der Verwaltung von Komponenten durchführt - hin zu Projekt-bezogenen Komponenten, die direkt im Source des Projektes installiert/verwaltet werden. Meinetwegen gern als "breaking change". GetIt ist da nur die halbe Lösung. So könnte man nach einer Neuinstallation das Projekt öffnen und ist fertig.

Ich habe da vor ein paar Wochen ein kleines Tool geschrieben, das ein projektbezogenes Laden von Designtime-Packages realisiert. Beim Projektwechsel werden diese Packages dann wieder entladen (vereinfacht gesagt - der reale Prozess ist etwas komplexer). Der eigentliche Anlass war die Verwendung unterschiedlicher Versionen von Packages in unterschiedlichen Projekten, die ja nicht gleichzeitig geladen sein können. Das von dir geschilderte Szenario lässt sich aber wohl auch damit realisieren. Näheres dazu in diesem Artikel: There Can Only Be One – At a Time!

[BigAl]

Hallo Uwe,

das verstehe ich nicht ganz. Beim Projekt werden doch die "aktivierten" Bibliotheken mit abgelegt. Wenn ich bestimmte Bibliotheken in Projekten deaktiviere und das Projekt speichere, dann sind beim nächsten Laden des Projekts diese Bibliotheken auch wieder deaktiviert. Das nutze ich teilweise für (ältere) eigene Komponenten, die in Kundenspezifischen Versionen vorliegen. Bei neuen Projekten habe ich allerdings - aus Gründen der Einfachheit - die Bibliotheken universeller gemacht und die Entscheidung bzw. aktiven Teile innerhalb der Bibliotheken gesteuert...

Gruß
Alex

[sh17]

Zitat:

Zitat von Uwe Raabe (Beitrag 1348126)

Zitat:

Zitat von sh17 (Beitrag 1348118)

Es wäre schön, wenn Delphi diesbezüglich mal einen Paradigmenwechsel in der Verwaltung von Komponenten durchführt - hin zu Projekt-bezogenen Komponenten, die direkt im Source des Projektes installiert/verwaltet werden. Meinetwegen gern als "breaking change". GetIt ist da nur die halbe Lösung. So könnte man nach einer Neuinstallation das Projekt öffnen und ist fertig.

Ich habe da vor ein paar Wochen ein kleines Tool geschrieben, das ein projektbezogenes Laden von Designtime-Packages realisiert. Beim Projektwechsel werden diese Packages dann wieder entladen (vereinfacht gesagt - der reale Prozess ist etwas komplexer). Der eigentliche Anlass war die Verwendung unterschiedlicher Versionen von Packages in unterschiedlichen Projekten, die ja nicht gleichzeitig geladen sein können. Das von dir geschilderte Szenario lässt sich aber wohl auch damit realisieren. Näheres dazu in diesem Artikel: There Can Only Be One – At a Time!

Danke Uwe, Dein Projekt kenne ich. Ich hab da für mich selbst auch eine ähnliche Lösung und brauch da auch nur einmal "drücken". Das sollte Embarcadero aber nicht von einer innovativen Weiterentwicklung abhalten.

[ConnorMcLeod]

Zitat:

Zitat von himitsu (Beitrag 1348020)

Ach ja, wegen den ständigen Neuinstallieren: Das Migrationtool haben inzwischen alle entdeckt?

Das Tool zum Migrieren von Einstellungen unterstützt Delphi 7 und alle neueren Versionen von RAD Studio, Delphi oder C++Builder. RAD Studio-Versionen ab Delphi 7 werden nicht offiziell unterstützt.


Bin das nur ich oder sieht da sonst noch jemand einen Widerspruch?

[Daniel]

Man kann sich auch anstellen.
Die englische Version sagt es deutlicher: "The Settings Migration Tool supports Delphi 7 and all newer versions of RAD Studio, Delphi or C++Builder. RAD Studio versions released before Delphi 7 are not officially supported."

Quelle:
http://docwiki.embarcadero.com/RADSt...Migration_Tool


Das ist letztlich auch exakt die Aussage, die man sich mit einem wenig gutem Willen hätte herleiten können.

[Uwe Raabe]

Zitat:

Zitat von BigAl (Beitrag 1348127)

Beim Projekt werden doch die "aktivierten" Bibliotheken mit abgelegt.

Das ist nicht ganz richtig. Das Projekt merkt sich lediglich die "deaktivierten" Packages. Damit kann man zwar Packages entladen, die man für das Projekt nicht braucht, aber man kann keine Packages laden, die nicht schon beim IDE-Start geladen sind. Der vorgeschaltete Artikel There Can Only Be One! beschreibt diese Problematik.

[Uwe Raabe]

Zitat:

Zitat von ConnorMcLeod (Beitrag 1348130)

Das Tool zum Migrieren von Einstellungen unterstützt Delphi 7 und alle neueren Versionen von RAD Studio, Delphi oder C++Builder. RAD Studio-Versionen ab Delphi 7 werden nicht offiziell unterstützt.

Guck doch nochmal genau hin. 8-)

[Lemmy]

Zitat:

Zitat von Uwe Raabe (Beitrag 1348133)

Guck doch nochmal genau hin. 8-)

das ist jetzt aber gemein ;-)

[himitsu]

Zitat:

Zitat von BigAl (Beitrag 1348116)

Dann geht es auch noch um einige selbst erstellte Bibliotheken, die man erstmal wieder kompilieren muss.

Neu kompilieren muß man nur, wenn sich der Compiler verändert (neue Compilierversion, meißt beim Upgrade auf die nächste Version)
oder wenn sich die gelinkten BPLs in ihrer Schnittstelle ändern, bei den verwendeten Methoden/Klassen/Typen.

Sowas sollte bei einem Update oftmals nicht zutreffen.



BPLs und DCUs sind compiler-abhängig, bzw. abhängig von den öffentlichen Schnittstellen, der gelinkten Bibliotheken (BPLs).

[ConnorMcLeod]

Zitat:

Zitat von Daniel (Beitrag 1348131)

Das ist letztlich auch exakt die Aussage, die man sich mit einem wenig gutem Willen hätte herleiten können.

Nee, das hieße dann ... Versionen vor Delphi 7 ...
Das ist das, was die englische Variante aussagt.
Guter Wille <> Glaskugel