AccessViolation-Error mit DLL

[jamma-markus]

hi,

ich bekomme jedes mal, wenn ich die prozedur "set_lang_values" aufrufe einen EAccessViolation-Error. die procedure hängt in einer dll.

Aufruf der Prozedur:

Delphi-Quellcode:

set_lang_values(language, mm_file, mm_exit, bt_add, bt_change, bt_del, bt_exit);

Prozedur

Delphi-Quellcode:

procedure set_lang_values(
  language : TLanguage_values;
  mm_file, mm_exit : TMenuItem;
  bt_add, bt_change, bt_del, bt_exit : TBitBtn); stdcall;
begin
//Mainmenü
  mm_file.Caption := string(language[0,0]);
  mm_exit.Caption := string(language[0,1]);
//Buttons
  bt_add.Caption := string(language[1,0]);
  bt_change.Caption := string(language[1,1]);
  bt_del.Caption := string(language[1,2]);
  bt_exit.Caption := string(language[1,3]);  
end;

language ist so deklariert

Delphi-Quellcode:

type
  TLanguage_values = array [0..5, 0..50] of PChar;  

var
  language : TLanguage_values;

[Bernhard Geyer]

Ich hoffe du verwendest Runtime-Packages!

Falls nein darfst Du keine Objekte TMenuItem und TBitBtn über die DLL-Schnittstelle übergeben da du dann 2 komplett getrennte Objektmodelle hast. TObject aus der Exe <> TObject aus der DLL.

[chaosben]

Verzeiht mir bitte, wenn ich jetzt ganz großen Müll erzähle, aber ich hab noch folgenden Alternativ-Vorschlag: Übergib doch nur die Adressen der Objekte und hole dir dann in der Dll die Objekte zu den Adressen.

[SirThornberry]

hast du den Textabschnitt beachtet der im DLL-Projekt ganz oben steht wenn man ein neues Projekt anlegt? Wenn nicht, dann mal durchlesen und das was dort steht auch befolgen!

[Bernhard Geyer]

Zitat:

Zitat von chaosben

Verzeiht mir bitte, wenn ich jetzt ganz großen Müll erzähle, aber ich hab noch folgenden Alternativ-Vorschlag: Übergib doch nur die Adressen der Objekte und hole dir dann in der Dll die Objekte zu den Adressen.

Bringt nicht bzw. kommt auf gleiche raus. Wenn in der Schnittstelle TBitBtn steht wird nur die Referenz (Adresse) auf das Objekt übergeben. Also genau das gleiche als wenn Pointer dort stehen würde.

[jamma-markus]

Zitat:

Zitat von Bernhard Geyer

Ich hoffe du verwendest Runtime-Packages!

Falls nein darfst Du keine Objekte TMenuItem und TBitBtn über die DLL-Schnittstelle übergeben da du dann 2 komplett getrennte Objektmodelle hast. TObject aus der Exe <> TObject aus der DLL.

sory, aber was sind Runtime-Packages :?: :?: :?:
wie binde ich die ein/wie benutze ich die :?: :?: :?:

[chaosben]

Zitat:

Zitat von Bernhard Geyer

Bringt nicht bzw. kommt auf gleiche raus. Wenn in der Schnittstelle TBitBtn steht wird nur die Referenz (Adresse) auf das Objekt übergeben. Also genau das gleiche als wenn Pointer dort stehen würde.

Ich gehe davon aus, das es seine eigene DLL ist. Also könnte er doch die Funktion dahingehend ändern, das er Integer-Werte übergibt (also die Adressen der Objekte) und sie dann in der DLL wieder auflöst.
Natürlich ist das unschöne Programmierung ... sozusagen "on the edge" ... aber es ist ja nur ein Alternativ-Vorschlag.
Wenn es ich um "Windows-Fenster" handelt, könnte man auch mit dem Handle arbeiten.

[xaromz]

Hallo,

Zitat:

Zitat von chaosben

Ich gehe davon aus, das es seine eigene DLL ist. Also könnte er doch die Funktion dahingehend ändern, das er Integer-Werte übergibt (also die Adressen der Objekte) und sie dann in der DLL wieder auflöst.

Macht er doch. Ein Objekt ist nur ein Pointer. Ein Pointer ist nur ein integer.

Gruß
xaromz

[Bernhard Geyer]

Zitat:

Zitat von chaosben

Zitat:

Zitat von Bernhard Geyer

Bringt nicht bzw. kommt auf gleiche raus. Wenn in der Schnittstelle TBitBtn steht wird nur die Referenz (Adresse) auf das Objekt übergeben. Also genau das gleiche als wenn Pointer dort stehen würde.

Ich gehe davon aus, das es seine eigene DLL ist. Also könnte er doch die Funktion dahingehend ändern, das er Integer-Werte übergibt (also die Adressen der Objekte) und sie dann in der DLL wieder auflöst.

Natürlich ist das unschöne Programmierung ... sozusagen "on the edge" ... aber es ist ja nur ein Alternativ-Vorschlag.

Gleiche Problem! TBitBtn von DLL <> TBitBtn von Exe

Zitat:

Zitat von jamma-markus

sory, aber was sind Runtime-Packages :?: :?: :?:
wie binde ich die ein/wie benutze ich die :?: :?: :?:

Lese mal in der Delphi-Hilfe unter Packages nach.

[F.W.]

Also wo liegt nun genau das Problem?

Bei den übergebenen PChars oder bei den Objekten?

Zu den PChars:

Delphi-Quellcode:

(* Anders als bei Strings müssen diese erst Speicher zugewiesen bekommen, wenn sie nicht aus dem Quelltext heraus mit Konstanten gleichgesetzt werden: *)
var
 P: PChar;
begin
 P := 'Hallo Welt!';
end;

(* wenn ich DLLs PChars übergeben hab oder in einer DLL Funktion ein variabler PChar zurück gegeben wurde, hab ich dafür erst Speicher reservieren müssen: *)
var
 P: PChar;
 S: String;//intern dürfen Strings benutzt werden //soweit ich weiß
begin
 S := DateToStr(Date);//ein Bsp, wo man nicht einfach P := PChar(DateToStr(Date)) schreiben kann
 GetMem(P, Length(S));
//oder obere Zeile und den String weglassen und direkt folgendes schreiben
// GetMem(P, 10);
 StrPCopy(P, S);
end;

Soviel zum Thema PChars, vlt liegts ja an etwas in die Richtung.

Zu den Pointergeschichten: Mir hat mal jemand gesagt, dass es egal sei, wenn man an DLLs TMenuItem s übergibt und so, so lange die Version der VCL übereinstimmt! (zu Programmierspracheübergreifenden Projekten kann ich da nicht sagen!)

[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.