hat jemand einen tipp, wie ich auf meinen eigenen formular einen barcode abhängig von einem gegebenen datenfeld erstellen kann?

habe von fastreport die komponente frxbarcodeobject gefunden.

kann ich diese komponente dafür benutzen, ohne dass ich gleich die komplette fastreport engine mit verwenden muss??

wäre echt dankbar für eure hilfe

Die lapidare Antwort lautet, nutz einen Barcodefont.

Gruß
K-H

Oder verrate uns, welchen Code du erstellen willst...

Datamatix?
QR-Code?
EAN?
Code39?

Um nur einige zu nennen...

Mavarik

Zitat von Mavarik:

Datamatrix?
QR-Code?
EAN?
Code39?

Sei mir nicht böse, aber Datamatrix und QR-Code sind keine Barcodes.

Anmerkungen:
Einige Barcodes sind zudem nicht frei als Font erhältlich.

Allerdings sei angemerkt, das die weitaus meisten Barcode-Rendering Engines nicht in der Lage sind, einen Barcode pixelgenau zu erstellen. Bei niedrigen Auflösungen ist es dann nämlich möglich, das der Barcode vom Scanner nicht erkannt wird.

Fonts sind -sauber umgesetzt- pixelgenau. Auch die FastReport-Engine gehört dazu.

Ich persönlich würde einen Font nehmen, und wenn das nicht geht, eben die FR-Engine. Was ist schlimmes dabei, die paar 100k mit zu linken?

Barcodefont: sorry das macht man nicht .....

Wenn Du dann das Prg auslieferst, so musst Du immer den Font mitliefern und je nach Windows; XP,Vista,WIN8; WIN Server, Terminalserver, usw. wirst Du erhebliche Probleme beim Installieren deiner App bekommen.

Das kann man machen, wenn man mit 90% seiner Kunden in persönlichen Kontakt treten will

Auf meinem Github Account gibt es eine Barcode Komponente.
https://github.com/sx2008/FBarcode
Allerdings ist der Code noch nicht auf Delphi XE angepasst (string -> AnsiString, usw).

@arnof: Abgesehen davon, dass ich liebend gerne mit 100% meiner Kunden in Kontakt stehe - wo genau liegen da die Fallstricke? Ich hatte mit Barcodes (zumindest dem Erstellen) bislang nur in wenig Projekten zu tun, wobei auch nur 1x das ganze im Report geschah. Ansonsten bin ich mit einem Font gut gefahren.

Zitat von Furtbichler:

Allerdings sei angemerkt, das die weitaus meisten Barcode-Rendering Engines nicht in der Lage sind, einen Barcode pixelgenau zu erstellen. Bei niedrigen Auflösungen ist es dann nämlich möglich, das der Barcode vom Scanner nicht erkannt wird.

Fonts sind -sauber umgesetzt- pixelgenau.

Für Fonts gelten dieselben Bedingungen wie für errechnete Striche (Barcode-Rendering Engines) - die Breite des Barcodes muß an die Auflösung (schrittweise) angepaßt werden. Und bei Fonts weiß man nie, was das System in der Canvas mit Kantenglättung etc. treibt, da es ja Fonts sind und das System sie eben als solche behandelt. Deshalb bin ich der Meinung, es ist genau umgekehrt: Nur bei errechneten Strichen kann man sich auf eine saubere Ausgabe verlassen.

Und da bei fehlendem Font dann der ganze Druck abgebrochen werden muß (weil es ja zB sinnlos ist, dann nur den Barcode-Druck wegzulassen und Tausende Etiketten OHNE Barcode auszudrucken - um sie dann zu entsorgen) oder ein anderer Font mit gleichem Namen installiert wurde ...

Deshlab habe ich von Barcodefonts bisher die Finger gelassen - und die Striche lieber selber passend zur Endgeräte-Auflösung selber berechnet - ist auch System- und Geräte-unabhängig. Das mache ich seit DOS-Zeiten so und ein Test vorkurzem mit Barcodefonts hat dies wieder bestätigt: Man erreicht keine saubere Ausgabe bei minimalem Raum - nur riesen Barcodes funktionieren mit Fonts einigermaßen.

Die einzigen Barcodefonts, die sauber rauskommen, sind im Drucker installierte Fonts bzw. Algorithmen, auch weil die Drucker zu geringe oder falsche Größenvorgaben einfach ignorieren und diese dann selber setzen.

Zitat von MeierZwoo:

Für Fonts gelten dieselben Bedingungen wie für errechnete Striche (Barcode-Rendering Engines)

Soweit ich mich erinnere, kann man für TTF sog. Hints angeben, d.h. Hilfsinformationen, die beim Rendern in geringen Auflösungen die Pixelgenauigkeit gewährleisten. Deshalb 'sauber umgesetzt', denn man muss die Hints schon angeben.

Aber im Grunde genommen hast Du Recht: Während ein korrekt gerenderter Barcode -umgerechnet- eben einfach nicht als 6pt Font darstellbar ist, würde ein auf 6pt gepresster BC-Font vermutlich grenzwertige Ergebnisse liefern, die umso besser ausfallen, je konkreter die Hints sind, aber eben nicht 100% korrekt sind und sogar zu Lesefehlern führen können (bzw. ist der BC dann gar nicht lesbar).

Ich drucke aber grundsätzlich nicht so kleine Barcodes (außer mit Thermotransfer).

Zitat:

und ein Test vorkurzem mit Barcodefonts hat dies wieder bestätigt: Man erreicht keine saubere Ausgabe bei minimalem Raum - nur riesen Barcodes funktionieren mit Fonts einigermaßen.

In den Grenzsituationen würde ich das auch so sehen. Allerdings finde ich 8pt nicht 'riesig' und mit diesen Größen -oder sagen wir lieber- Breite des schmalsten Balkens >= 3pxl geht das imho schon.

Ich korrigiere mich also: Lieber ne FR-Engine und Fonts nur als Notlösung bzw. bei Druckern mit genügender Auflösung oder normalgroßen Barcodes.

Geht die Ausgabe über einen Laserdrucker, reicht i.a. ein Font. Geht sie über Tintentrahler oder Industriedrucker mit < 150dpi würde man sich mit Fonts die Karten legen.

Wenn der Drucker nativ Barcodes drucken kann (z.B. Zebra-Drucker), dann würde ich hier sowieso eine Lösung anstreben, die dieses Feature nutzt. Und das geht selbst mit einer FR-Engine nicht.

Zitat von MeierZwoo:

Die einzigen Barcodefonts, die sauber rauskommen, sind im Drucker installierte Fonts bzw. Algorithmen, auch weil die Drucker zu geringe oder falsche Größenvorgaben einfach ignorieren und diese dann selber setzen.

Das ist allerdings nur die halbe Wahrheit (oder misverständlich): Ein BC-Renderer, der die konkrete Auflösung des Zieldruckers zum Rendern in Betracht zieht, wird auch korrekte BC erstellen. Allerdings können die dann erheblich vom im Design hinterlegten abweichen.

@sx2008

danke dir! das ist genau das, nachdem ich gesucht habe!
noch ne noobie frage dazu:
barcodes können wohl GRUNDSÄTZLICH nur aus ziffern gebildet werden?