Der XE8 Fehler-Thread

[Harry Stahl]

So, den Bug habe ich mal gemeldet:

https://quality.embarcadero.com/browse/RSP-11123

Die Behebung sollte m.E. auf jeden Fall noch ins Update 1 rein.

[Kralle]

Moin,

Zitat:

Zitat von himitsu (Beitrag 1300762)

Na wegen der coolen neuen Features?
http://www.delphipraxis.net/184977-c...ease-date.html

Naja ..

=== Off Topic =====

Zitat:

Zitat von himitsu (Beitrag 1300762)

Und wer für iOS entwickelt ist sowieso zum Upgrade gezwungen, inkl. Installation der Fixpacks.

Wer entwickelt denn für iOS wenn er es nicht unbedingt muss?
So mal ebend eine vorhandene Anwendung auf iOS kompilieren ist ja eh nicht.
Man braucht einen Mac zusätzlich zum PC.
Okay, für Android braucht man auch ein Android-Gerät, wird aber nicht genötigt seine Anwendungen über den Apple-Store zu vertreiben.
Aber wir schweifen ab..
==================

Gruß Heiko

[Harry Stahl]

Und weil es soviel Spaß macht, Fehlerreports zu schreiben(:(), gleich noch einer:

VCL-App calling a FMX-DLL hangs on FreeLibrary (DLLHandle)

https://quality.embarcadero.com/browse/RSP-11125

Fehler betrifft allerdings auch schon XE7, wie ich nun feststellen musste.

[Bernhard Geyer]

Zitat:

Zitat von Harry Stahl (Beitrag 1300788)

Und weil es soviel Spaß macht, Fehlerreports zu schreiben(:(), gleich noch einer:

VCL-App calling a FMX-DLL hangs on FreeLibrary (DLLHandle)

https://quality.embarcadero.com/browse/RSP-11125

Fehler betrifft allerdings auch schon XE7, wie ich nun feststellen musste.

Also du übergibst lebende Objekte über DLL-Grenzen ohne mit gemeinsamen Laufzeitbibliotheken zu arbeiten?
Falls ja (kenn jetzt nicht jede Option in der dproj-Datei) war das eher zufall das das funktioniert hat aber nix was man erwarten sollte. Lebende Objekte über DLL-Grenzen ohne gemeinsame Laufzeitbibliothek zu verwenden ist ein NoGo.

[Harry Stahl]

Was meinst Du mit "gemeinsamen" Laufzeitbibliotheken in Verbindung mit einer VCL-APP, welche eine FMX-DLL verwendet?

[jaenicke]

Wenn du eine DLL ohne gemeinsame Laufzeitpackages benutzt, hat die DLL nicht die gleichen Klassen, globale Variablen, usw. wie deine Anwendung. Deshalb funktioniert is und as usw. auch nicht.
Ohne Laufzeitpackages kannst du dann nur einfache Variablen und Interfaces in deinen DLL-Schnittstellen benutzen. (Und mit Sharemem theoretisch auch Delphistrings, ich würde es aber nicht machen.)

Objekte zu übergeben ist, selbst wenn es zufällig funktioniert, aber auch schon deshalb nicht schön, weil die DLL dann erzwungenermaßen mit der gleichen Delphiversion kompiliert sein muss. Eine standardkonforme DLL hingegen kannst du auch mit einer neuen Anwendung verwenden (und auch von anderen Sprachen wie C# aus).

Statt TMemoryStream würde ich daher z.B. IStream verwenden, besser noch aber ein eigenes Interface, da ich gerade erst feststellen musste, dass sich diese Standardinterfaces in Delphi ebenfalls ändern...

[Mavarik]

Zitat:

Zitat von jaenicke (Beitrag 1300797)

Wenn du eine DLL ohne gemeinsame Laufzeitpackages benutzt, hat die DLL nicht die gleichen Klassen,

Darum geht es doch nicht... In der DLL ist doch die Laufzeitumgebung von FMX drin...

Somit kannst Du in Deiner VCL-Anwendung - "geile FMX Formulare" oder andere Fancy-FMX Features nutzen...

[Harry Stahl]

Als einzige gemeinsame Klasse verwende ich TMemoryStream. Diese stammt aus System.classes und wird sowohl von der VCL als auch von FMX verwendet.
Wenn ich also sowohl VCL-APP und FMX-DLL mit der gleichen Delphi-Version kompiliere, sollten technisch gesehen keine Probleme auftauchen.

Von der Funktionalität funktioniert ja auch alles, wie gewünscht.

Nur eben das entladen der FMX-DLL eben nicht.

Auch bei dem Beispiel, das EMBA mal selber für den VCL to FMX-DLL Access veröffentlicht hat, funktioniert nicht das Entladen der DLL.

Hier muss also ein Problem in Delphi XE7/XE8 liegen.

Wenn ich die DLL mit Delphi <= XE6 kompiliere, klappt es auch mit den entladen der DLL, auch wenn ich die VCL-App mit XE7 oder XE8 kompiliert habe.

[Sir Rufo]

Auch wenn die beiden Klassen aus der gleichen Unit stammen, sind die Klassen in der EXE und DLL anders und du darfst die nicht einfach so übergeben. Was geht wäre das Übergeben eines Pointers auf den Speicherbereich oder wenn du alles in ein Interface kapselst.

Alles andere führt zu komischen Ergebnissen.

Ob es da trotzdem ein Problem mit XE7/XE8 gibt kann man also pauschal nicht sagen, erst wenn man alles richtig gemacht hat und es nicht funktioniert, dann kann man von einem Fehler sprechen.

Die Beispiele von Emba sind auch nicht als Perlen der Programmierung bekannt, daran würde ich gar nichts messen.

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1300822)

Die Beispiele von Emba sind auch nicht als Perlen der Programmierung bekannt

Die findet man übrigens hier: Programming Pearls