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

[pmros]

Kann da mal schnell jemand drüber schauen und mir sagen, warum

Delphi-Quellcode:

function commands (request:string):TStringList; stdcall;
var
s1, s2, s3: String;
Liste: TStringList;

begin
s1:='H';
s2:='G0';
s3:='G1';
Liste := TStringList.Create;
Liste:=
    Liste.Add(s1);
    Liste.Add(s2);
    Liste.Add(s3);

result:=Liste;
end;

exports commands;

Das hier ausgibt?!:

Code:

[Error] Project2.dpr(24): Incompatible types: 'TStringList' and 'Integer'

Ich habe doch s1 - s3 als strings definiert und nicht als integer, wo ist denn das Problem?

[Luckie]

Du willst ein Objekt aus einer DLL zurückgeben? Das wird so nichts. Informiere dich mal über "DLL und Objekte".

[BadenPower]

Zitat:

Zitat von pmros (Beitrag 1315355)

Delphi-Quellcode:

function commands (request:string):TStringList; stdcall;
var
s1, s2, s3: String;
Liste: TStringList;

begin
s1:='H';
s2:='G0';
s3:='G1';
Liste := TStringList.Create;
Liste:=  //schau mal hier
    Liste.Add(s1);  // und hier
    Liste.Add(s2);
    Liste.Add(s3);

result:=Liste;
end;

exports commands;

Du weist der Stringliste mit dem Namen "Liste" den Rückgabewert der Funktion Liste.Add zu. Und dies ist der Index des eingefügten Wertes, also ein Integer, denn die markierten Zeilen Deines Quelltextes ergeben:

Delphi-Quellcode:

Liste := Liste.Add(s1);

Ob das mit der Übergabe funktioniert, wie Luckie moniert, hat ersteinmal nichts mit dem jetzt erzeugten Fehler zu tun.

[mkinzler]

Das auch, aber der Fehler ist in hier:

Delphi-Quellcode:

Liste:=
    Liste.Add(s1);

Liste.Add gibt den Index des neu hinzugefügten Eintrages zurück ( ein Integer) welchen Du dann der Liste zuweisen willst.

[pmros]

Zitat:

Zitat von BadenPower (Beitrag 1315357)

Du weist der Stringliste mit dem Namen "Liste" den Rückgabewert der Funktion Liste.Add zu. Und dies ist der Index des eingefügten Wertes, also ein Integer, denn die markierten Zeilen Deines Quelltextes ergeben:

Ob das mit der Übergabe funktioniert, wie Luckie moniert, hat ersteinmal nichts mit dem jetzt erzeugten Fehler zu tun.

Gnah, natürlich. Übersehen. Vielen Dank. Und ja, doch. Es funktioniert jetzt. Ich kann die Stringliste übergeben.

[nahpets]

Auch wenn ich nicht weiß, ob mein Vorschlag auch nur ansatzweise sinnvoll erscheinen könnte, vermutlich hätte ich es so gemacht:

Delphi-Quellcode:

function commands (request:string):TStringList; stdcall;
begin
Result := TStringList.Create;
Result.Add('H');
Result.Add('G0');
Result.Add('G1');
end;

Was soll denn hier passieren?

Delphi-Quellcode:

Liste:=
    Liste.Add(s1);

Add ist eine Methode von Liste, aber die weist man doch nicht bei dem Aufruf gleichzeitig wieder der Liste zu?

Auch dashier verstehe ich nicht:

Delphi-Quellcode:

result:=Liste;

mit einem

Delphi-Quellcode:

result.AddStrings(Liste);

und dem dann zwingend folgende

Delphi-Quellcode:

Liste.Free

könnte ich ja noch leben.

[Luckie]

Zitat:

Zitat von BadenPower (Beitrag 1315357)

Ob das mit der Übergabe funktioniert, wie Luckie moniert, hat ersteinmal nichts mit dem jetzt erzeugten Fehler zu tun.

Ich als Visionär sehe nur das große Ganze. :mrgreen:

[Luckie]

Zitat:

Zitat von pmros (Beitrag 1315359)

Ich kann die Stringliste übergeben.

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

[nahpets]

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

[BadenPower]

Zitat:

Zitat von Luckie (Beitrag 1315361)

Zitat:

Zitat von BadenPower (Beitrag 1315357)

Ob das mit der Übergabe funktioniert, wie Luckie moniert, hat ersteinmal nichts mit dem jetzt erzeugten Fehler zu tun.

Ich als Visionär sehe nur das große Ganze. :mrgreen:

Dafür war ich mal schneller als mkinzler.

Aber auch der Einwand von nahpets hat seine Berechtigung und sollte berücksichtigt werden.

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

Zitat von nahpets (Beitrag 1315363)

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

Natürlich mit

Delphi-Quellcode:

Liste.free;

Steht nur leider erst seit 20 Sekunden da :wink:

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

Delphi-Quellcode:

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

Delphi-Quellcode:

Liste.DelimitedText := 'Zeile1,Zeile2,in mehrere Zeilen';

Delphi-Quellcode:

Liste.AddStrings('Mal wieder eine neue Zeile');

Delphi-Quellcode:

Liste.Text:='Ein Text mit Zeilenumbruch  geht in mehrere Zeilen';

also glatter Viertürer.

Grüße in die Runde // Martin

[pmros]

Zitat:

Zitat von mschaefer (Beitrag 1315369)

Delphi-Quellcode:

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

Aber

Delphi-Quellcode:

Liste.AddStrings(Liste, [s1,s2,s3]);

Ergibt

Delphi-Quellcode:

[Error] Project2.dpr(23): Too many actual parameters

[Blup]

Zitat:

Zitat von pmros (Beitrag 1315368)

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.