OpBitmap mit Formaten Version 1.0

[theo]

Gibt es irgendwo ne kurze Doku, um die einzelnen Möglichkeiten kurz zu erfassen, die es noch gibt?

Also ich wüsste davon nichts!

Prinzipiell funktioniert OPBitmap eher wie ein VCL Bitmap, also mit Scanlines und die Pixelformat Umwandlungen funktionieren auch. Der Canvas ist aber nur ganz schwach unterstützt. Wenn man Canvas Funktionen wie Font etc braucht, muss man's halt einem TBitmap zuweisen.
Was das Lazarus interface angeht, gibt es verschiedene Ebenen.
Wenn du's wie in "lclintegrationdemo" einsetzt, musst du eigentlich gar nichts machen. Am besten Kompilierst du das Package und nimmst es als Anforderung ins Projekt auf. Dann hast du alle Bildformate zur Verfügung.
In "lazformatsdemo" siehst du, wie man etwas mehr Kontrolle bekommt.

Die Demos zeigen eigentlich das Wesentliche. Und sonst frag mich!

[monta]

Werd ich machen

Hab da gleich was.
Was genau bewirgt denn die Streamgeschichte?
Wird dort der Mimetyp gesetzt?

Code: Alles auswählen

Strm := TMemoryStream.Create;
  fOp.SaveToStream(Strm, MIME_TIF);
  fOp.LoadFromStream(Strm); //Some formats like Targa need a MimeType like fOp.LoadFromStream(Strm, MIME_TGA);
  fOp.DrawImage;
  cbPixelFormat.ItemIndex := Ord(fOP.Bitmap.PixelFormat) - 1;
  Caption := fOp.MimeType + ' (' + inttostr(fOP.Bitmap.Width) + ' x ' + inttostr(fOP.Bitmap.Height) + ')';
  Strm.free;

[theo]

Hab da gleich was.
Was genau bewirgt denn die Streamgeschichte?
Wird dort der Mimetyp gesetzt?

Genau, dort kannst du das Stream-Speicherformat angeben.
Von Stream lesen wird meistens automatisch erkannt.
Es gibt aber Ausnahmen, welche schwierig bis gar nicht am Header zu erkennen sind.
Diese sollte man dann beim Stream lesen angeben (z.B. MIME_TGA).
Dabeit ist MIME_TGA = 'image/x-tga';
Wenn man also z.B. von einem Webserver einen Content-Type bekommt, kann man den gleich so mitangeben.
Bei Files geht's über die Extension.

Aus Spass hab ich mal pasdoc drüber gejagt, ...kleine Übersicht über Typen usw. halt

Super! Geht doch! Dann hat sich das auch schon erledigt...

[monta]

ah, danke für die Erklärung.

[theo]

Vielleicht habe ich dich auch falsch verstanden.
Wenn du wissen wolltest, was der Democode oben soll, dann heisst die Antwort: Nur zeigen dass und wie es geht.
Ansonsten ist dieser Teil der Demo sinnfrei.
Sinn würde es erst machen wenn man zwischen Save.. und Load.. etwas mit dem Stream anstellen würde, z.B. mit TCP/IP übertragen.

[monta]

Na, war schon recht.

Woltte generell wissen, was die Streamschae bewirkt. Das es dort dann keinen Sinn macht, hab ich mir dann zusammengedichtet .

[theo]

Übrigens: Gute Sache mit dem Pasdoc.
Kann mich da jemand mal ein bisschen erhellen?
Ich sehe es gibt verschiedene Tools die was mit Doc zu tun haben:

Pasdoc
FPDoc
Lazarus Documentation Editor - Using "lazde" to create documentation
LazDoc - An integrated editor for documentation files

Kennt sich da jemand aus? Aus dem LazDoc Wiki werde ich nicht schlau.

[monta]

PasDoc ist ein selbstständiges Projekt, Opensource und in PasCal geschrieben
Läuft unter allen Plattformen und müsste mit sämtlichen Pascalquelltexten funzen. Funktioniert normalerweise mit Kommendozeile, aber es gibt in der 0.10er auch ne Gui, die zwar als Experimentell eingestuft ist, aber ohne probleme funktioniert. Die Infos von pasdoc kommen dabei aus Kommentaren, die man entsprechend anbringen muss. (siehe WissensDB, PasDoc Teil I)
PasDoc besitzt seinen eigenen Parser, und benötigt eben die Kommentare im Code.

FPDoc verfolgt dagegen ne andere Technik. FPDoc benötigt eine Unit und eine dazugehörige XML-Datei. Diese XML-Datei enthält die Informationen, welche FPDoc dann mit den entsprechenden Items der Units verschmilzt.
Dabei müssen die Einträge der XMl den selben namen, wie der Item in der Unit besitzen.
Vorteil ist klar, man brauch keine Kommentare in der Unit, auf der anderen Seite ist die externe XML zur Entwicklungszeit kein bisschen hilfreich.
Als Parser setzt FPDoc auf den Freepascal-eigenen auf, es muss also zwingend FPC installiert sein.

LazDoc und lazde verfolgen das selbe Ziel. Ich glaube jedoch, lazde, als externer Editor ist etwas mächtiger. Hauptunterschied ist, das lazde ne standalone-Anwendung darstellt, währenddessen LazDoc in die Ide integriert ist.
Beide dienen aber dazu, (zumindest momentan) lediglich die XML-Dateien, welche FPDoc anschließend mit der Unit verschmilzt, zu erstellen (ob LazDoc das Erstellen des XML-Grundgerüstes kann, weiß ich nicht, lazde kanns auf jeden fall) und anschließend die entsprechenden Einträge der einzelnen items zu bearbeiten.
Man benötigt für Jede unit ne zusätzliche XML, mit den Informationen, wenn man etwas komentieren will. Die blanke Struktur kann FPDoc auch ohne xml extrahieren, dann geht aber der Sinn etwas verloren.
LazDoc und lazde sind qusi nur Vorstufen zu FPDoc.

Ich persönlich finde das Konzpt von PasDoc nicht schlecht, wenn man die Kommentare gut wählt und nicht ganze Romane schreiben will, dienen sie gleich der Übersicht im Quelltext bei der Entwicklung und der Dokumentation.
Wer natürlich extra XML-Dateien erstellen will/bzw. den Quelltext nicht mit Kommentaren zutextemag, muss natürlich FPDoc nehmen und die XML entweder mit lazde oder LazDoc erstellen. (Oder im Editor)

---

Edit: Nebenbei bliebe noch anzumerken, das PasDoc über sogenannte Tags zum einen auch das einbinden externer Textdateien bspw. für längere Erläuterungen erlaubt und außerdem mittels dieser Tags auch Formatiert werden kann.

FPDoc bietet in seinen XML-Dateien ebenfalls Formatierungsmöglichkeiten.

(Ich hab hier gerade die Docs rumliegen, weil ich mich letzte Woche damit etwas auseinandergesetzt hab )

[theo]

Danke für die ausführliche und erhellende Antwort!
Jetzt hab ich's auch kapiert.
Ich habe Pasdoc installiert und das sieht mir ganz vernünftig aus.
Jetzt müsste man nur noch die Kommentare schreiben. Schnarch...

[monta]

kein Problem Ich hab auch ne Weile gebraucht, das zu verstehen.

PasDoc ist schön. Weil man die Doku normalerweise ja nebenher mit schreiben kann. Und wenn es nur die übligen kurzen Kommentare sind, sollten die im Quellcode auch vertretbar sein, und es geht ja meist nicht darum ausführliche Handbücher zu schreiben.

Ich hab bei einem Projekt auch damit angefangen, alle Kommentare nachträglich zu erstellen ist bisschen zeitraubend, aber mit XML gehts auch nicht schneller, und wenn mans einmal hat, gehts ja .

[theo]

Ja, ich denke dass es immer auf's Projekt ankommt, wie interessant die Kommentare sind. z.B. bei OPBitmap selber ist's irgendwie überflüssig.
Das Funktioniert mehr oder weniger wie ein VCL Bitmap.
In diesem Projekt wäre vielleicht eine Übersicht interessanter.
Im Sinne: was macht opbitmapformats, wozu ist lazbridge da, was machen die Reader und Writer? etc.

Kommentare wie:

{Ein TBitmap einem TOPBitmap zuweisen}
AssignBitmapToOpBitmap(Bitmap: TBitmap; OpBitmap: TOpBitmap);

find ich irgendwie nicht so dringend nötig.

[pluto]

Da gebe ich dir recht. Hilfreich währe ein genaue Beschreibung der Parameter der Methoden und welche Klasse es gibt und wo für sie da sind. und evlt. ein und zwei Demos bzw. zu den Methoden jeweils ein beispiel oder so.

[theo]

und evlt. ein und zwei Demos bzw. zu den Methoden jeweils ein beispiel oder so.

Meinst du das bezüglich OpBitmap? Demos gibt's doch genug, oder? Ich wüsste gar nicht was ich noch demonstrieren sollte.

[pluto]

naja ich meinte eigentlich zu den einzelen Funktionen die es in opBitMap gibt.
Ich habe es mir noch nicht angeschaut....

[monta]

dann mach das mal, alles in den Demos