Projekt mit Runtime-Packages compilieren - BPL nicht gefunden

[Codehunter]

Hallo!

Ich taste mich zum ersten Mal an ein Projekt heran, das mit Runtime-Packages erzeugt werden soll. Hab mir ein neues leeres VCL-Projekt angelegt,"Mit Laufzeitpackages linken" eingestellt und STRG-F9 kompiliert problemlos.

Wenn ich als Zielplattform dann Win-64 einstelle, dann bekomme ich beim STRG-F9 den Compilerfehler "Package PngComponents wird benötigt, konnte aber nicht gefunden werden".

Was mich jetzt wundert: Warum wird die PngComponents.bpl nur bei Win64 angefordert? Auf meiner Test-VM läuft die Win32-Version dann auch OHNE PngComponents.bpl im Verzeichnis. Also braucht er die wirklich nicht.

Grüße
Cody

[himitsu]

Es werden nur die Packages verlinkt, welche in den Projektoptionen "Packages" angegeben sind.
Und dort kann man natürlich für jede Plattform einzeln angeben was wo rein kommt.

Alle nicht angegebenen Packages werden weiterhin direkt in die EXE/DLL eincompiliert/reingelinkt.

[Codehunter]

Hmmm, das erschließt sich mir grade nicht. Wenn ich in die Projektoptionen schaue, dann habe ich unter "Entwurfs-Packages" jede Menge Häkchen drin. Ebenso wenn ich unter "Laufzeit-Packages" nachschaue, dann habe ich da auch eine laaange Liste angegeben. Also nicht ICH selbst sondern per Default schon drin.

Eigentlich hätte ich in dem Fall erwartet dass meine Test.exe dann auf der Test-VM jede Menge .BPLs anfordern würde. Aber außer rtl180.bpl und vcl180.bpl wird da nichts weiter benötigt. :gruebel:

[Uwe Raabe]

Du kannst in den Projektoptionen unter Laufzeitpackages für jede Build-Konfiguration bzw. Zielplattform getrennt einstellen, welche Packages zur Laufzeit verwendet werden sollen. Überprüf mal, ob da in beiden Fällen das gleiche drin steht.

[Codehunter]

Ja, ich habe mir angewöhnt eine saubere Ordnerstruktur für die Projekte zu bilden. Ich leite gewohnheitsmäßig alle Projektkonfigurationen von "Alle Konfigurationen - Alle Plattformen" ab. Die Ausgabeverzeichnisse trenne ich durch Pfadvariablen wie $(Platform) und $(Config). Dadurch kann ich identische Konfigurationen für alle Plattformen fahren. Zumindest hatte ich noch nicht den Fall dass ich abweichende Konfigurationen brauchte. Damit habe ich mir auch schon so manchen DCU-Schlamassel vom Hals gehalten ;)

Insofern JA: Steht überall das selbe drin.

[mkinzler]

Existiert eine 64Bit Version des Packages?

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1274964)

Existiert eine 64Bit Version des Packages?

Hmmmmmm... Existierte tatsächlich NICHT. Komponentenpackage für x64 neu erstellt, Fehler weg.

Also muss ich das Ganze so verstehen, dass die IDE per Default erstmal jedes erdenkliche in der IDE registrierte Package in die Liste der Laufzeit-Packages einträgt und man dann her gehen muss und die nicht benötigten wieder abwählen muss?

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1274969)

Also muss ich das Ganze so verstehen, dass die IDE per Default erstmal jedes erdenkliche in der IDE registrierte Package in die Liste der Laufzeit-Packages einträgt und man dann her gehen muss und die nicht benötigten wieder abwählen muss?

Genau so ist es! Bei der Installation eines Design-Packages werden die dafür benötigten Runtime-Packages in diese (interne) Liste mit aufgenommen. Diese wird dann für neue Projekte herangezogen und sollte jeweils angepasst werden. Man will ja nicht alle möglichen Runtime-Packages mitliefern, nur weil man vielleicht eine Handvoll Units daraus braucht.

[Codehunter]

Ok da sieht man erst mal wie viel Arbeit einem die IDE doch abnimmt wenn man ohne Laufzeit-Packages kompiliert :D

Ich bin darauf gekommen weil ich mich mal an einer modularen Anwendung mit Plugins versuchen will. Nach etlichen Anläufen auf DLL-Basis, die alle zwar viel Arbeit machten aber nicht so richtig funktionierten, sieht das mit den BPLs doch ganz vielversprechend aus.

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1274975)

Ich bin darauf gekommen weil ich mich mal an einer modularen Anwendung mit Plugins versuchen will.

In dem Fall musst du nur die Packages eintragen, die von den Plugins gebraucht werden. Den Rest kannst du auch in die Exe rein compilieren.

[Codehunter]

Wie ist das dann eigentlich, wenn Plugin-BPLs ihrerseits wieder BPLs laden wollen. Ich habe vor, meine Plugins in einem Plugin-Ordner der Anwendung zu sammeln und von dort dynamisch zu laden. Statisch gelinkte BPLs werden doch aber entweder von dem Verzeichnis geladen wo die Exe vom Hauptprogramm liegt oder aus einem der %PATH%-Verzeichnisse.

Wo suchen denn meine Plugin-BPLs dann nach ihren eigenen statisch gelinkten BPLs? Im Ordner der Hauptanwendung die das Plugin aufgerufen hat oder im Ordner, in dem das Plugin-BPL liegt?

[Bernhard Geyer]

Zitat:

Zitat von Codehunter (Beitrag 1274978)

Wo suchen denn meine Plugin-BPLs dann nach ihren eigenen statisch gelinkten BPLs? Im Ordner der Hauptanwendung die das Plugin aufgerufen hat oder im Ordner, in dem das Plugin-BPL liegt?

statisch gelinkte BPL sind für Windows erstmal DLLs. D.h. Du musst dein Windows bzw. MS fragen wie suchreihenfolge bezüglich der DLLs ist.

[Codehunter]

Ok, dann bastel ich mal weiter. Die Frage an sich ist ja damit beantwortet. Danke an alle die geholfen haben.

[Codehunter]

Sooo... da wäre das nächste Problemchen. Plugin auf BPL-Basis gebastelt, für Win32 kompiliert - Funktioniert. Wenn ich aber für Win64 kompiliere, dann bekomme ich unmittelbar beim "LoadPackage()" vom Debugger ein "Disconnected Session" mit folgendem Inhalt:

Code:

[2039534C]{dbkdebugide180.bpl} Debug.TDebugKernel.msgBox (Line 5931, "Debug.pas" + 30) + $0
[03F16EB3]{bordbk180.dll} Unbekannte Funktion bei DllUnregisterServer + $5037
[03F8B8A8]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $619D0
[03F8B927]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $61A4F
[03F8C36D]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $62495
[03F8C5BD]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $626E5
[03FBC3E3]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $9250B
[03F29D72]{bordbk180.dll} Unbekannte Funktion bei DllUnregisterServer + $17EF6
[03F8B8CC]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $619F4
[50455D4A]{vcl180.bpl  } Vcl.Controls.TWinControl.GetControl (Line 9131, "Vcl.Controls.pas" + 4) + $A
[5057C713]{vcl180.bpl  } Vcl.Forms.TraverseClients3 (Line 7261, "Vcl.Forms.pas" + 5) + $29
[03F8C7FC]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $62924
[03F34263]{bordbk180.dll} Unbekannte Funktion bei @isDbkLoggingOn$qv + $A38B
[505777F9]{vcl180.bpl  } Vcl.Forms.TCustomForm.WndProc (Line 4388, "Vcl.Forms.pas" + 201) + $5
[50452734]{vcl180.bpl  } Vcl.Controls.TControl.Perform (Line 7002, "Vcl.Controls.pas" + 10) + $8
[50582B07]{vcl180.bpl  } Vcl.Forms.TApplication.DispatchAction (Line 11494, "Vcl.Forms.pas" + 9) + $C
[505801E3]{vcl180.bpl  } Vcl.Forms.TApplication.WndProc (Line 9857, "Vcl.Forms.pas" + 98) + $B
[50170090]{rtl180.bpl  } System.Classes.StdWndProc (Line 16860, "System.Classes.pas" + 8) + $0
(00037995){CnWizards_DXE4.dll} [0F428995]
(000379FC){CnWizards_DXE4.dll} [0F4289FC]
(00035275){CnWizards_DXE4.dll} [0F426275]
(00037995){CnWizards_DXE4.dll} [0F428995]
(000379FC){CnWizards_DXE4.dll} [0F4289FC]
(00037AAD){CnWizards_DXE4.dll} [0F428AAD]
(000352EE){CnWizards_DXE4.dll} [0F4262EE]
[500630C0]{rtl180.bpl  } System.@FinalizeArray (Line 29800, "System.pas" + 139) + $0
[500630B0]{rtl180.bpl  } System.@FinalizeArray (Line 29788, "System.pas" + 127) + $0
[50580E8F]{vcl180.bpl  } Vcl.Forms.TApplication.ProcessMessage (Line 10290, "Vcl.Forms.pas" + 25) + $1
[50580ECA]{vcl180.bpl  } Vcl.Forms.TApplication.HandleMessage (Line 10318, "Vcl.Forms.pas" + 1) + $4
[50581205]{vcl180.bpl  } Vcl.Forms.TApplication.Run (Line 10456, "Vcl.Forms.pas" + 26) + $3

Was ich sicher sagen kann: Die zu ladende .bpl existiert, liegt zusammen mit der Host.exe im selben Verzeichnis und ist auch passend dazu als Win64-Debug kompiliert. Eine andere gleichnamige BPL bekommt er nicht zu fassen, hab sicherheitshalber alle gelöscht.

Kann jemand was mit der Meldung anfangen?

[Stevie]

Hau deine exe und bpl mal in den Dependency Walker rein, der sagt dir dann schon, welche anderen statisch gebundenen Module nicht vorhanden sind.

[Codehunter]

Danke für den Tip. Der sagt mir dass bei Win64 so ziemlich alles fehlt was nur fehlen kann. Sprich die ganzen Komponenten-BPLs. Alles was so schön in der IDE verschraubt ist.

Seltsam ist dabei nur, dass sich da die Win32- und Win64-Versionen meines Testprogramms unterschiedlich verhalten. Während meine Plugin.bpl auf Win32 außer vcl180.bpl und rtl180.bpl gar nichts weiter haben will, mokiert sich die Win64-Version so ziemlich über alles.

Getestet jeweils auf 100% "BPL-freien" Test-VMs.

[Stevie]

Zitat:

Zitat von Codehunter (Beitrag 1275101)

Danke für den Tip. Der sagt mir dass bei Win64 so ziemlich alles fehlt was nur fehlen kann. Sprich die ganzen Komponenten-BPLs. Alles was so schön in der IDE verschraubt ist.

Seltsam ist dabei nur, dass sich da die Win32- und Win64-Versionen meines Testprogramms unterschiedlich verhalten. Während meine Plugin.bpl auf Win32 außer vcl180.bpl und rtl180.bpl gar nichts weiter haben will, mokiert sich die Win64-Version so ziemlich über alles.

Getestet jeweils auf 100% "BPL-freien" Test-VMs.

Sicher, dass du Uwes Hinweis

Zitat:

Zitat von Uwe Raabe (Beitrag 1274972)

Zitat:

Zitat von Codehunter (Beitrag 1274969)

Also muss ich das Ganze so verstehen, dass die IDE per Default erstmal jedes erdenkliche in der IDE registrierte Package in die Liste der Laufzeit-Packages einträgt und man dann her gehen muss und die nicht benötigten wieder abwählen muss?

Genau so ist es! Bei der Installation eines Design-Packages werden die dafür benötigten Runtime-Packages in diese (interne) Liste mit aufgenommen. Diese wird dann für neue Projekte herangezogen und sollte jeweils angepasst werden. Man will ja nicht alle möglichen Runtime-Packages mitliefern, nur weil man vielleicht eine Handvoll Units daraus braucht.

auch für die 64-bit Version deines Packages durchgeführt hast? Ansonsten sorge dafür, dass die ganzen 3rd Party Komponenten Packages auch in der 64-bit Version zur Verfügung stehen.

[Codehunter]

Also in meiner IDE gibt es bei den Projekteinstellungen keine nach Win32 und Win64 getrennte Package-Auswahl. Entweder man machts für alle Plattformen oder gar nicht. Was mich aber grad richtig nervt: Die abgewählten Packages speichert Delphi nicht in den Projekteinstellungen. Sprich nach dem nächsten Öffnen des Projektes kann man die ganze Auswahl wiederholen.

Mich würde interessieren, ob man nicht eine BPL so erstellen kann dass alle nötigen Laufzeit-BPLs direkt eingebunden sind (so wie wenn man in der IDE ohne Laufzeit-BPLs kompilieren einstellt) und man trotzdem eine eigene BPL dynamisch zur Laufzeit mit LoadPackage laden kann. Ist doch ein bisschen affig, die halbe VCL mit in die Distri zu packen...

[Stevie]

Zitat:

Zitat von Codehunter (Beitrag 1275108)

Also in meiner IDE gibt es bei den Projekteinstellungen keine nach Win32 und Win64 getrennte Package-Auswahl. Entweder man machts für alle Plattformen oder gar nicht.

Stimmt, eine der wenigen Einstellungen die für alles gleich ist.

Zitat:

Zitat von Codehunter (Beitrag 1275108)

Was mich aber grad richtig nervt: Die abgewählten Packages speichert Delphi nicht in den Projekteinstellungen. Sprich nach dem nächsten Öffnen des Projektes kann man die ganze Auswahl wiederholen.

Sollte eigentlich nicht der Fall sein, sondern die nicht angehakten sollten in der dproj unter <Excluded_Packages> gespeichert werden.

Zitat:

Zitat von Codehunter (Beitrag 1275108)

Mich würde interessieren, ob man nicht eine BPL so erstellen kann dass alle nötigen Laufzeit-BPLs direkt eingebunden sind (so wie wenn man in der IDE ohne Laufzeit-BPLs kompilieren einstellt) und man trotzdem eine eigene BPL dynamisch zur Laufzeit mit LoadPackage laden kann. Ist doch ein bisschen affig, die halbe VCL mit in die Distri zu packen...

Es gibt 2 Sachen, einmal die required Klausel in deinem Package. Dort wird angegeben, welche Dinge aus anderen Packages kommen, alles andere wird explizit in die BPL aufgenommen - da kommt bei Nichtbeachtung manchmal die Meldung nach dem Motto, hey du machst da grad VCL Zeugs in dein Package, was aber auch in Package XYZ enthalten ist. Dabei werden alle von der IDE geladenen Packages berücksichtigt. Im requires ist mindestens die RTL aufgelistet.
In deiner Hostanwendung stellst du ein, gegen welche Runtime packages gelinkt wird. Also eine Mindestkonfiguration würde dort nur dein Package auflisten - die RTL wird implizit benutzt, weil sie in deinem Package als requires steht.

[Codehunter]

Moment, ich krieg grad irgendwie Hirnerweichung :D Also der Hostanwendung könnte ich beibiegen dass sie alle Laufzeitbibliotheken direkt eingebunden bekommt. Mein Package dagegen wird die entsprechenden BPLs immer anfordern? Denn eine Auswahl von Laufzeitbibliotheken ist bei meinem Package-Projekt gar nicht vorgesehen.

Ich dachte bisher, wenn die Hostanwendung das entsprechende Laufzeitpackage bereits enthält, würde sich mein dynamisch geladenes Package daraus bedienen. Scheint aber nicht so zu sein :(

[Stevie]

Package requires Klausel

Was da drin steht, wird als Package benötigt. Was nicht drin steht und im Package Code benutzt wird, wird implizit ins Package kompiliert (siehe W1033). Oder auch der Popup Dialog der dann kommt und dir sinngemäßg mitteilt "Hör mal, du nutzt hier nen paar Units, die schon in nem anderen Package sind und eine Unit kann nicht in 2 Packages gleichzeitig sein und wenn das andere Package auch in deiner Anwendung ist, knallts. Willste nicht lieber das andere Package in dein requires aufnehmen?"

Hostanwendung

Bei Projekt Optionen->Packages->Runtime packages den Haken setzen und dort alle Packages eintragen, aus der sich die Anwendung (also die exe) bedienen soll. Alles andere, was die Anwendung benutzt und nicht aus diesen Packages bezogen werden kann, wird hineinkompiliert.

[Codehunter]

Ok so langsam wirds klarer. Hostanwendung verstanden. Sieht man ja auch an den Dateigrößen der Host.exe wenn man RTL und VCL einkompiliert oder nicht.

Zu meinem Package: Wenn ich dich richtig verstehe, dann muss ich gemeinsam genutzte Units, die in Host und Package gleichzeitig verwendet werden, in einem externen Package unterbringen. Ok ergibt auch Sinn wenn man sich überlegt was der interface-Abschnitt einer Unit so alles macht.

Was ich noch nicht so ganz durchschaue ist, wie die ganzen implizit eingebundenen Units/Packages zustande kommen. Als Beispiel nenne ich mal UniDAC, das ich zwar in der IDE installiert habe, aber in einem völlig "nackten" VCL-Projekt mit Sicherheit nicht verwendet würde. Trotzdem will die IDE das erstmal in die EXE verbauen. Und ich muss dass quasi in einer Art Blacklist explizit unterbinden. Wäre es nicht sinnvoller, eine Art Whitelist mit den gewollten Packages anzugeben?

[Stevie]

Zitat:

Zitat von Codehunter (Beitrag 1275124)

Was ich noch nicht so ganz durchschaue ist, wie die ganzen implizit eingebundenen Units/Packages zustande kommen. Als Beispiel nenne ich mal UniDAC, das ich zwar in der IDE installiert habe, aber in einem völlig "nackten" VCL-Projekt mit Sicherheit nicht verwendet würde. Trotzdem will die IDE das erstmal in die EXE verbauen. Und ich muss dass quasi in einer Art Blacklist explizit unterbinden. Wäre es nicht sinnvoller, eine Art Whitelist mit den gewollten Packages anzugeben?

Machst du doch

[Codehunter]

Gibts bei mir nicht in der Form. Andere IDE?

Bei meinem XE4 läuft die Sinnigkeit anders herum: Entweder ich gebe bei den Laufzeit-Packages diejenigen an die ich nicht dabei haben will (und wo ich dann eine .bpl beipacken muss) oder ich lasse die weg, wann werden die Packages direkt in die EXE eingebunden. Am Beispiel von UniDAC: Ich habe bei meiner IDE noch keinen Weg gefunden, eine EXE zu backen, in der kein UniDAC verbaut wäre. Und mir kann doch keiner erzählen dass ein absolut leeres Test-Projekt, das nichts außer dem TForm1 enthält, irgendwo implizit ein Package wie UniDAC einbinden würde.

PS: UniDAC ist nur ein Beispiel und stellvertretend für wirklich jedes Package das meine IDE kennt.

[Uwe Raabe]

Nicht da! Im Unterzweig Laufzeit-Packages kannst du in der (gleichnamigen) Eigenschaft Laufzeit-Packges Plattform- und Konfigurations-spezifisch die gewünschten Runtime-Packages auflisten.

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1275128)

Bei meinem XE4 läuft die Sinnigkeit anders herum: Entweder ich gebe bei den Laufzeit-Packages diejenigen an die ich nicht dabei haben will (und wo ich dann eine .bpl beipacken muss) oder ich lasse die weg, wann werden die Packages direkt in die EXE eingebunden. Am Beispiel von UniDAC: Ich habe bei meiner IDE noch keinen Weg gefunden, eine EXE zu backen, in der kein UniDAC verbaut wäre. Und mir kann doch keiner erzählen dass ein absolut leeres Test-Projekt, das nichts außer dem TForm1 enthält, irgendwo implizit ein Package wie UniDAC einbinden würde.

Ich kann das Problem hier nicht nachvollziehen:

- Neues VCL-Projekt
- Unter Projekt-Optionen, Laufzeit-Packages, Mit Laufzeit-Packages linken auf True setzen
- Compilieren
- Projekt - Infos über ... zeigt rechts die Liste der verwendeten Packages an (rtl210, vcl210)

[Codehunter]

Jaaaaaa genau da liegt das Problem das ich nicht verstehe. Hier die Infos zu meinem "Plugin-Package" namens Modul1.Module.bpl. Sobald ich das aber auf der Test-VM dynamisch per LoadPackage lade, wird nach diversen anderen BPLs verlangt (z.B. mal wieder unidac180.bpl)

Und jetzt verrat mir mal einer, warum?

[Stevie]

Zitat:

Zitat von Codehunter (Beitrag 1275134)

Sobald ich das aber auf der Test-VM dynamisch per LoadPackage lade, wird nach diversen anderen BPLs verlangt (z.B. mal wieder unidac180.bpl)

Und jetzt verrat mir mal einer, warum?

Vermutlich ganz einfach, weil du in deiner Modul1.Module.bpl irgendwo Units von Unidac nutzt und irgendwann beim Kompilieren mal bei der von mir in den obigen Beiträgen erwähnten Dialogbox "JA, ich will!" gesagt hast und die IDE die entsprechenden Packages in die requires Klausel deines Packages eingetragen hat.

Dass die Exe diese Packages nicht verlangt, müsste dir ja klar, sein sonst würds schon beim Starten des Programms ne "Modul blabla nich gefunden..." Fehlermeldung geben und es einfach nicht starten. Als Beweis lade die Modul1.Module.bpl ins Depends und er zeigt dir, dass er unidac und Konsorten braucht. Es wird dort auch aufgelistet welche Methoden er dort denn genau aus diesen anderen Modulen importiert hat.

P.S. Moment... du macht nen LoadPackage obwohl du die Anwendung doch schon gegen das Package gelinkt hast? Wieso?

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1275142)

P.S. Moment... du macht nen LoadPackage obwohl du die Anwendung doch schon gegen das Package gelinkt hast? Wieso?

Ich hatte das so verstanden, daß es sich bei der BPL um ein PlugIn handelt, das dynamisch geladen wird. Wäre es statisch gebunden, würde ja ebenfalls beim Start der EXE das fehlende UniDAC-Modul angemeckert.

Die IDE gibt merkwürdigerweise beim Compilieren eines Package auch dieses Package höchstselbst in der Liste der verwendeten Packages an.

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1275145)

Die IDE gibt merkwürdigerweise beim Compilieren eines Package auch dieses Package höchstselbst in der Liste der verwendeten Packages an.

Ah, hatte nich richtig geschaut, dachte der Screenshot war von der Exe.
Das macht dann meine obige Diagnose hinfällig. Dann kann ich dir noch anbieten, das Projekt mal hier anzuhängen oder mir zu schicken sofern möglich, damit wir nich noch nen halben Tag rumraten müssen :)

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1275145)

Die IDE gibt merkwürdigerweise beim Compilieren eines Package auch dieses Package höchstselbst in der Liste der verwendeten Packages an.

Das ist mir auch aufgefallen. Also mir hat die Sache über Feierabend dann doch keine Ruhe gelassen und ich habe das Projekt versuchsweise mal auf einem frisch installierten Delphi kompiliert. Resultat: Verhält sich völlig normal.

Zitat:

Zitat von Uwe Raabe

Ich hatte das so verstanden, daß es sich bei der BPL um ein PlugIn handelt, das dynamisch geladen wird. Wäre es statisch gebunden, würde ja ebenfalls beim Start der EXE das fehlende UniDAC-Modul angemeckert.

Exakt richtig. Mein BPL soll ein Plugin werden. Alle anderen wie RTL und VCL sind mir dagegen spitz ausgedrückt schnurzegal ob direkt einkompiliert oder dagegen gelinkt.

Also werde ich heute mal hier nachschauen wo da der Wurm drin ist. Ich befürchte fast, mir hat es hier irgendwie RTL und VCL zerlegt. Zumal die Probleme ja nur auftreten wenn ich für x64 kompiliere.

Zitat:

Zitat von Stevie (Beitrag 1275152)

Ah, hatte nich richtig geschaut, dachte der Screenshot war von der Exe.

Wo? Was? Screenshot? Mist, jetzt brauch ich schon wieder einen neuen Monitor :(

[Codehunter]

Also nach mehreren Stunden Sucherei ohne nennenswertes Ergebnis (außer der Erkenntnis dass die vcl180.bpl aus dem x64-Zweig selbst die anderen BPLs eingebunden hat) habe ich mir ein Backup von meiner Entwicklungsmaschine gezogen und das Delphi-Setup nochmal drüberlaufen lassen. Bisher funktioniert das Ding wieder. Sieht so aus als hätte irgendwas meine VCL verbogen.

Praktischerweise sind jetzt auch meine x64-EXEn viel kleiner als vorher :D