AccessViolation-Error mit DLL

[SirThornberry]

es ist nicht egal, auch nicht wenn DLL und Hauptprogramm die gleichen Objecte der gleichen Version nutzen. Wenn das ganze so gemacht wird muss mindestens noch die ShareMem verwendet werden. Denn wenn in der DLL die Caption aus dem Hauptprogramm geändert wird so weiß der Speichermananger aus dem Hauptprogramm nix und der Speichermanager aus der DLL weiß auch nicht woher der speicher kommt.

[chaosben]

So, jetzt habt ihr mich so weit ("auf die Palme") gebracht, das ich ne Demo geschrieben habe. Und ... wer hätte das gedacht ... es geht (via Pointer).
Und wer es nicht glaubt, der sauge sich bitte den Anhang. :stupid:

Natürlich funktioniert diese Vorgehensweise nur ganz sauber, wenn man für die DLL und das Programm den gleichen Compiler und die gleichen Units verwendet.

Und noch ein Wort zu Objekten und Pointern. Eine Objektreferenz ist ungleich der Adresse im Speicher. Das was Integer(Objekt) liefert ist nur eine ID, die innerhalb der VCL-Umgebung eines bestimmten Programms gültig ist. Somit kann ich nicht diese ID an eine DLL übergeben, da diese ja in einer anderen Umgebung läuft. Dagegen ist die Adresse des Objektes im Speicher eindeutig.

[Bernhard Geyer]

Zitat:

Zitat von chaosben

So, jetzt habt ihr mich so weit ("auf die Palme") gebracht, das ich ne Demo geschrieben habe. Und ... wer hätte das gedacht ... es geht (via Pointer).
Und wer es nicht glaubt, der sauge sich bitte den Anhang. :stupid:

Natürlich funktioniert diese Vorgehensweise nur ganz sauber, wenn man für die DLL und das Programm den gleichen Compiler und die gleichen Units verwendet.

Das geht vieleicht, aber ist es sinnvoll bei einer "normalen" DLL den Compiler und die Version der DLL's vorzuschreiben. Dann kann man ja gleich Packages nehmen.
Auch gehen in diesem Fall nicht alle Objekte korrekt in 'ner DLL verwenden.

Kannst Du mal dein Programm so erweitern das eine aus der DLL erzeugtes TFont-Objekt in der Exe einem Button zugewiesen wird. Meine Versuche nach deinem Schema scheitern immer an einem Absturz.

Zitat:

Zitat von chaosben

Und noch ein Wort zu Objekten und Pointern. Eine Objektreferenz ist ungleich der Adresse im Speicher. Das was Integer(Objekt) liefert ist nur eine ID, die innerhalb der VCL-Umgebung eines bestimmten Programms gültig ist. Somit kann ich nicht diese ID an eine DLL übergeben, da diese ja in einer anderen Umgebung läuft. Dagegen ist die Adresse des Objektes im Speicher eindeutig.

OK. Habe ich auch nicht so im Details so gewußt. Aber lößt das auch unser Problem komplett (siehe TFont)?

[chaosben]

Naja ... grundsätzlich kann man mit meinem Vorschlag die eigentliche Frage dieses Threads beantworten (Captions für BitBtns setzen).
Natürlich kann ich mit dieser Methode nicht alles machen. Zum Beispiel kann ich dem Font-Objekt des Buttons keinen Namen zuweisen, da der Speicherbereich des Strings, in dem der neue Name steht, ja gleich wieder mit der DLL freigegeben wird. Solche Zuweisungen funktionieren nur, wenn sich das Objekt mittels einer Setter-Routine den Inhalt schnappt und selbst speichert. (z.B. Caption).

Nun noch ein Gedanke betreffs der Lokalisierung, die ja der Ausgangspunkt dieser Diskussion war. Ich halte es für ungebräuchlich, die Zuweisung der Texte von der Sprach-DLL erledigen zu lassen. Eher halte ich einen Zugriff auf die Resourcen der DLL für sinnvoll, um aus diesen die gewünschten Texte zu lesen. Noch besser ist aber imho die Idee, die Lokaliesierungsdaten in einer XML-Struktur zu hinterlegen. Falls jetzt das Argument kommt: "Das kann ja dann jeder ändern" ... will ich folgendes behaupten: Wer da was ändert und nicht mehr mit dem Programm klarkommt ist selber schuld. Wer aber das Programm in eine andere Sprache übersetzen will, dem wird es durch dieses Vorgehen sehr leicht gemacht, was dazu führen sollte, das das Programm noch bekannter wird.

Sorry, falls ohne Absicht der Oberlehrer zu sehr durchgekommen ist.