Typen zur Verwendung in Librarys

[theo]

Diesen Fall gibt es natürlich, das grenzt für mich aber schon an Missbrauch der TStringList.
Das hält auch anderen Betrachtungen nicht Stand. z.B.

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
var sl:TStringList;
begin
 sl:=TStringList.create;
 sl.Add('eins'+LineEnding+'zwei'+LineEnding+'drei');
 Caption:=inttostr(sl.Count); //->1
 Memo1.Lines.Assign(sl);
 Caption:=Caption+' '+Inttostr(Memo1.Lines.Count); //->3  
 sl.free;
end;

[Hitman]

Diesen Fall gibt es natürlich, das grenzt für mich aber schon an Missbrauch der TStringList.
Das hält auch anderen Betrachtungen nicht Stand. z.B.

Aber genau darum ging es doch, dass TStringList (um marcov's Worte zu benutzen) Limitierungen einführt, die eigentlich unnötig sind. In einem array of string können eben die einzelnen Strings Zeilenumbrüche enthalten. Über eine TStringList geht das dann verloren. (genau darum hab ich vorhin das Beispiel auch so gewählt)

[theo]

Diesen Fall gibt es natürlich, das grenzt für mich aber schon an Missbrauch der TStringList.
Das hält auch anderen Betrachtungen nicht Stand. z.B.

Aber genau darum ging es doch, dass TStringList (um marcov's Worte zu benutzen) Limitierungen einführt, die eigentlich unnötig sind. In einem array of string können eben die einzelnen Strings Zeilenumbrüche enthalten. Über eine TStringList geht das dann verloren. (genau darum hab ich vorhin das Beispiel auch so gewählt)

So stimmt das nicht. Du kannst einem TStringList Item durchaus LineEndings speichern, genau wie bei array of string.
Aber wenn du das als Text abholst, sind da nachher mehr Zeilen. Bei sl gehen die LineEndings aber nicht verloren.

Ihr habt ja recht, wenn man davon ausgeht, dass ein Item Text mit LineEndings enthalten soll.

Ich finde die generelle Warnung aber übertrieben. Mann muss einfach wissen, womit man es zu tun hat.
Ich hätte keine Probleme, z.B. eine Liste von Font.Names etc. als TStringList.Text zu übergeben.
Genauso könnte man davor warnen, LineEndings in Items zu speichern, da passiert im Austausch mit Memo.Lines dasselbe.
Man muss halt wissen was man tut.

[RSE]

Gibt es einen programmiersprachenübergreifenden und betriebssystemunabhängigen Ersatz für TFont für die Verwendung als Parameter in einem Library-Interface? Ansonsten müsste ich Größe, Schriftart, Farbe etc. alles einzeln abfragen... Der Ersatztyp soll natürlich automatisch in TFont umgewandelt werden können.

[theo]

Gibt es einen programmiersprachenübergreifenden und betriebssystemunabhängigen Ersatz für TFont für die Verwendung als Parameter in einem Library-Interface?

Träum weiter....

Sowas würde ich u.U. mit XML oder JSON als PChar austauschen.

[RSE]

Träum weiter....

Hab ich mir schon gedacht. Also doch alles einzeln...

[theo]

Am standardisiertesten wäre evtl. noch die CSS Notation.

Beispiele Font
{ font:bold .9em Times; }
{ font:italic 1cm Helvetica; }
{ font:small-caps 110% Verdana; }
{ font:2em/180% Courier; }

Oder einzelne Attribute:

font-family (Schriftart)
font-style (Schriftstil)
font-variant (Schriftvariante)
font-size (Schriftgröße)
font-weight (Schriftgewicht)

[RSE]

CSS kenne ich, aber das müsste ich auch wieder nur erst parsen, da kann ich auch einzelne Parameter übergeben. Ist ja kein Beinbruch.

[theo]

CSS kenne ich, aber das müsste ich auch wieder nur erst parsen, da kann ich auch einzelne Parameter übergeben. Ist ja kein Beinbruch.

Ja klar, kommt halt auf den gewünschten Standardisierungsgrad an.
Ich meine nur, wenn du das möglichst für alle Systeme / Compiler machen willst, und nicht dein eigenes Format "erklären" willst, wäre es eine Möglichkeit. Du sagst dann einfach:
"Die Funktion exportiert Font-informationen im CSS Font Format."

z.B. afaik trennt nicht jedes System Font.height und Font.size als zwei separate Parameter.
In CSS entspricht das px vs pt.

Standard ist immer gut.

[mschnell]

Was sind "log string"?

Sorry: "Long String"

[mschnell]

Wie stellt man in Librarys sicher, dass die andere Aufrufkonvention (z.B. stdcall) auch bei Events Anwendung findet?

In C musst Du das alles von Hand machen, sonst nimmt der Compiler den Default. Es stehen Keywords für verschiedene Aufruf-Konventionen zur Wahl (u.A. auch "Pascal", was nicht FPC, sondern GNU Pascal meint. Die Keywords hab ich aber nicht im Kopf.)
-Michael

[RSE]

Wie stellt man in Librarys sicher, dass die andere Aufrufkonvention (z.B. stdcall) auch bei Events Anwendung findet?

In C musst Du das alles von Hand machen, sonst nimmt der Compiler den Default. Es stehen Keywords für verschiedene Aufruf-Konventionen zur Wahl (u.A. auch "Pascal", was nicht FPC, sondern GNU Pascal meint. Die Keywords hab ich aber nicht im Kopf.)
-Michael

Öhm, das ist nicht was ich meinte... war aber auch nicht präzise genug gestellt, meine Frage. Mein Interface hat einen Event OnLog vom Typ TLogEvt. TLogEvt ist ebenfalls im Interface definiert und zeigt so den Prozedurkopf incl. der Aufrufkonvention. Da ich diesen Typ für eine Variable verwende, die ich mit der Adresse einer Prozedur belege, die mit dem Typ TLogEvt übereinstimmt, muss diese ja auch die entsprechende Aufrufkonvention haben. Auf der Aufrufenden Seite ist der Typ TLogEvt natürlich auch bekannt. So ist die Einhaltung auf beiden Seiten also sichergestellt. Ich weiß irgendwie gar nicht mehr, wie mir die Frage aufgekommen ist... War wohl zu viel relativ neues auf einmal...

[mschnell]

Ich habe vor ein paar Monaten 'mal (testhaber) eine GNU-C-DLL mit einer Funktion gemacht, die von einem Delphi-Programm aufgerufen wurde, das im Aufruf ein eine Referenz auf eine (Delphi-) Prozedur übergeben hat, die die in der C-Funktion dann aufgerufen wurde.

Meinst Du so was ?

Das hat jedenfalls auf Anhieb geklappt. Als SAufrufkonvention habe ich STDCALL verwendet Heißt in GNU_C, glaube ich "__STDCALL__" oder so ähnlich.

Ich kann 'mal schauen, ob ich den Sourcecode irgendwo finde.

-Michael

[RSE]

Also ich hab mir meine Frage oben selbst beantwortet Die war wohl blos entstanden, weil mir der Kopf vor neuen Sachen geraucht hat.