Alles richtig, trotzdem "Incompatible Types TString List and Integer"?

[pmros]

Der Code entstand bei meinem erste Test mit DLL's. Deswegen sind da noch einige Brocken drin, die schlichtweg nicht mehr gebraucht werden, bzw. keinen Sinn ergeben.

Deswegen auch das überflüssige

Delphi-Quellcode:

Liste:=
    Liste.Add(s1);

Zitat:

Das dürfte aber nur gehen, wenn du die Sharemem.dll einbindest.

Hab ich nicht, läuft trotzdem?!

[pmros]

Zitat von nahpets:

Wann, und wie, wenn überhaupt, wird die Stringliste denn wieder freigegeben?

Natürlich mit Liste.free; Steht nur leider erst seit 20 Sekunden da

[Luckie]

Hm: http://www.delphipraxis.net/90814-ob...l-kapseln.html

[pmros]

Gerade gelesen.

Zitat:

Ein Objekt in einer DLL zu instantiieren ist problemlos. Man muss es halt nur explizit machen.
Probleme treten erst auf wenn man das Objekt an das Hauptprogramm gibt. DLL und Hauptprogramm haben separate Memorypools. Die Einbindung von ShareMem beseitigt diese Probleme.

Aber trotzdem sitze ich hier, habe kein ShareMem eingebunden und mein Hauptprogramm gibt mir anstandslos die in der DLL erzeugte Stringliste aus.

Ich lass mir das testweise in einer Messagebox ausgeben

Delphi-Quellcode:

teststring:=commands('test');
showmessage(teststring[0]+' '+teststring[1]+' '+teststring[2]);

Funktioniert.

[mschaefer]

Moin,

Daten in so eine Stringliste bekommt man durcch die verschiedensten Türen:

Liste.AddStrings(Liste, ['car', 'cat', 'dog']);
Liste.DelimitedText := 'Zeile1,Zeile2,in mehrere Zeilen';
Liste.AddStrings('Mal wieder eine neue Zeile');
Liste.Text:='Ein Text mit Zeilenumbruch geht in mehrere Zeilen';

also glatter Viertürer.

Grüße in die Runde // Martin

[pmros]

Zitat von mschaefer:

Liste.AddStrings(Liste, ['car', 'cat', 'dog']);

Aber
Liste.AddStrings(Liste, [s1,s2,s3]); Ergibt
[Error] Project2.dpr(23): Too many actual parameters

[Blup]

Zitat von pmros:

Gerade gelesen.

Zitat:

Ein Objekt in einer DLL zu instantiieren ist problemlos. Man muss es halt nur explizit machen.
Probleme treten erst auf wenn man das Objekt an das Hauptprogramm gibt. DLL und Hauptprogramm haben separate Memorypools. Die Einbindung von ShareMem beseitigt diese Probleme.

Aber trotzdem sitze ich hier, habe kein ShareMem eingebunden und mein Hauptprogramm gibt mir anstandslos die in der DLL erzeugte Stringliste aus.

Ich lass mir das testweise in einer Messagebox ausgeben

Delphi-Quellcode:

teststring:=commands('test');
showmessage(teststring[0]+' '+teststring[1]+' '+teststring[2]);

Funktioniert.

So lange DLL und Anwendung durch den gleichen Compiler erzeugt wurden, kann das funktionieren.
Die Methode Destroy ist "virtual" und wird somit über die Klassenreferenz des Objektes in der DLL aufgerufen.
Aber schon der Vergleich "(teststring is TStringList)" dürfte in der Anwendung "False" ergeben.

Der Stringliste dürfen auch nur einzelne String-Konstanten hinzufügt werden.
Für diese wird keine Referenzzählung und keine automatische Freigabe durchgeführt.
Wird ein String in der DLL mit dem Speichermanager der DLL erzeugt, wird bei der Freigabe unter Umständen der Speichermanager der Anwendung aufgerufen, der für diesen Speicherbereich nicht zuständig ist.
Gefährlich wäre z.B.:

Delphi-Quellcode:

 {in der DLL:}
 Liste.Add('function' + IntToStr(i)); 

 {in der Anwendung mit der selben Liste:}
 s := teststring[0];
 teststring.Free;
 s := ''; // <- Hier könnte es dann einen Fehler geben, da Referenzzähler des Strings auf 0 fällt

[himitsu]

Zitat:

So lange DLL und Anwendung durch den gleichen Compiler erzeugt wurden, kann das funktionieren.

Kann, muß aber nicht.

Der eine Compiler braucht sich nur zu denken, "oh geil, das braucht keiner, also lass ich es weg".
In dem anderen Modul (EXE/DLL) wird das aber benötigt und dann knallt es, z.B. beim Zugriff auf das Feld, bzw. auch auf alle nachfolgenden Felder.

Auch alle Prüfungen mit IS gehen dann in die Hose, da jedes Modul seine eigene RTTI hat und dann TObject (EXE) nicht das Selbe ist, wie TObject (DLL).


Laufzeitpackages sind da die einzige wirkliche Lösung.