BarCode erstellen??

[Serienchiller]

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 ;)

[p80286]

Die lapidare Antwort lautet, nutz einen Barcodefont.

Gruß
K-H

[Mavarik]

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

Datamatix?
QR-Code?
EAN?
Code39?

Um nur einige zu nennen...

Mavarik

[Furtbichler]

Zitat:

Zitat von Mavarik (Beitrag 1222696)

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?

[arnof]

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

[sx2008]

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).

[Medium]

@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.

[MeierZwoo]

Zitat:

Zitat von Furtbichler (Beitrag 1222698)

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.

[Furtbichler]

Zitat:

Zitat von MeierZwoo (Beitrag 1222727)

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:

Zitat von MeierZwoo (Beitrag 1222727)

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.

[Serienchiller]

@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? :P

[Patito]

Zitat:

Zitat von Serienchiller (Beitrag 1222740)

barcodes können wohl GRUNDSÄTZLICH nur aus ziffern gebildet werden? :P

Das hängt vom BarcodeTyp ab. Im Code128 gibt es z.B. sogar die Möglichkeit innerhalb des Barcodes
zwischen Zahlen und Buchstaben-Codierung umzuschalten.

Noch etwas zur Barcode-Größe: Normalerweise hat ein Barcode-Typ noch Standards
für Mindestgröße, mimimale Abstände, ...
Wenn man den Standard nicht beachtet (und z.B. einfach irgendwelche Fonts skaliert)
ist es Glückssache welche Scanner das dann lesen können.

[Furtbichler]

Zitat:

Zitat von Patito (Beitrag 1222745)

Noch etwas zur Barcode-Größe: Normalerweise hat ein Barcode-Typ noch Standards
für Mindestgröße, mimimale Abstände, ...
Wenn man den Standard nicht beachtet (und z.B. einfach irgendwelche Fonts skaliert)
ist es Glückssache welche Scanner das dann lesen können.

Oder einfacher ausgedrückt: Jeder Standard definiert das Verhältnis zwischen dünnen und dicken Strichen und Abständen. Beim Code-39 wäre das 1:1.8 - 1:2.4, ein dünner Strich ist also in etwa halb so dünn wie ein dicker.

Wenn der Renderer nun den dünnen Strich mal 2 und mal 3 Pixel, und den dicken Strich dafür mal 4 und mal 5 Pixel breit macht, dann haben wir ein verhältnis von 2:4 = 1:2 bis 3:4 = 1:1.3 . Und das ist dann klar außerhalb der Spec. Kein Scanner (nun ja, fast keiner) wird das dann lesen können.

Daraus folgt:
1. Der Renderer darf nicht einfach skalierte Rechtecke zeichnen, sondern muss die Pixelbreiten einmalig berechnen und dann pixelgenau füllen.
2. Ein Barcode kann nicht beliebig breit sein, d.h. er lässt sich vertikal nur diskret vergrößern.

[matashen]

ich werwende ZINT,
zu der Lib gibts auch einige Threads hier.
Läuft ganz gut. Hat zwar ein paar Bugs, aber im großen und ganzen ists OK für ne kostenlose komponente.

hier der Link zur Kompo-Sammlung hier in der dp
http://www.delphipraxis.net/143986-[komponente]-barcode-fuer-delphi-zint.html

[Patito]

Zitat:

Zitat von Furtbichler (Beitrag 1222755)

Oder einfacher ausgedrückt: Jeder Standard definiert das Verhältnis zwischen dünnen und dicken Strichen und Abständen.

Für die Logistik gibt es zum Teil auch recht feste Angaben in mm.

http://www.gs1-germany.de/fileadmin/...equalitaet.pdf
(dünnste Strichbreite von GS1-128 liegt zwischen mindestens 0,495 mm und maximal 1,016 mm)

Laut Wikipedia ist im Code128 eine Ruhezone links und rechts von 6,4 mm vorgesehen und der kleinste Strich sollte
nicht kleiner als 1/10 der Ruhezone sein (Richtwert).
https://en.wikipedia.org/wiki/Code_128

[Perlsau]

Zitat:

Zitat von arnof (Beitrag 1222720)

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

Geht alles, wenn man will: Font ohne Installation verwenden

[p80286]

Zitat:

Zitat von Perlsau (Beitrag 1222769)

Geht alles, wenn man will: Font ohne Installation verwenden

Du willst ihn wohl veralbern, das könnte man doch unter Allgemeinwissen abhaken oder nicht?

Gruß
K-H

[Perlsau]

Zitat:

Zitat von p80286 (Beitrag 1222771)

Zitat:

Zitat von Perlsau (Beitrag 1222769)

Geht alles, wenn man will: Font ohne Installation verwenden

Du willst ihn wohl veralbern, das könnte man doch unter Allgemeinwissen abhaken oder nicht?

Mitnichten! Ich wollte lediglich darauf hinweisen, wie man einen nicht installierten Font zur Laufzeit verwenden kann und somit die Aussage, "wirst Du erhebliche Probleme beim Installieren deiner App bekommen" widerlegen.

[MeierZwoo]

Zitat:

Zitat von Furtbichler (Beitrag 1222734)

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

Ich hab das leider ständig - weil Etiketten, vorallem auf Sondermaterialien ganz schön ins Geld gehen können und dort um jeden mm gefeilscht wird.

Perlsau, einen nicht installieren (also im System angemeldeten) Font kann man aber nur verwenden, wenn die Font-Datei auch auf der Kiste vorhanden ist und niemand dran rumgefummelt hat. Und einige Benutzer treiben die merkwürdigsten Dinge - wobei das den Programmersteller ansich nicht berührt, wohl aber seinen Ruf ruiniert, vorallem wenn die Benutzer auch noch zu feige sind, zuzugestehen, daß sie rumgefummelt haben.

Das Problem bei Barcodes ist ja aber, daß niemand der Benutzer einen Fehler so einfach wie bei falschem Text erkennen kann - und auch beim wieder einscannen für Kontrollen die Zeit und Lust oder auch Möglichkeit meist nicht vorhanden ist - und dann landen völlig falsche Daten im Zielsystem.

Aus den Gründen versuche ich alle Fehlerquellen auszuschließen. Und dazu gehören Fonts, also externe Drittdateien, über die ich keinerlei Kontrolle habe.

[Perlsau]

Zitat:

Zitat von MeierZwoo (Beitrag 1222780)

Perlsau, einen nicht installieren (also im System angemeldeten) Font kann man aber nur verwenden, wenn die Font-Datei auch auf der Kiste vorhanden ist und niemand dran rumgefummelt hat. Und einige Benutzer treiben die merkwürdigsten Dinge - wobei das den Programmersteller ansich nicht berührt, wohl aber seinen Ruf ruiniert, vorallem wenn die Benutzer auch noch zu feige sind, zuzugestehen, daß sie rumgefummelt haben.

Um einen Font zu verwenden, von dem du nicht weißt, ob er auf der Zielkiste installiert ist, kopierst du die benötigte Fontdatei beim Installieren deiner Anwendung in den Anwendungsordner, genau so, wie du auch die Exe-Datei dort hineinkopierst. Damit ist die benötigte Font-Datei auf der Kiste verfügbar. Wo ist das Problem :?:
Wenn du's nicht glaubst, dann probier's doch einfach mal aus :!:

Daß Fonts zum Ausdrucken eines Barcodes nicht das Gelbe vom Ei sind, ist eine andere Geschichte.

[MeierZwoo]

Zitat:

Zitat von Perlsau (Beitrag 1222787)

Um einen Font zu verwenden, von dem du nicht weißt, ob er auf der Zielkiste installiert ist, kopierst du die benötigte Fontdatei beim Installieren deiner Anwendung in den Anwendungsordner, genau so, wie du auch die Exe-Datei dort hineinkopierst. Damit ist die benötigte Font-Datei auf der Kiste verfügbar. Wo ist das Problem :?:

Sorry, aber ich bin weder der Benutzer noch der dort zuständige Admin - ICH kann NICHTS auf die Zielkiste DAUERHAFT kopieren. Dann muß ich wie oben auch schon erwähnt, den Druck abbrechen, wenn diese Datei nicht mehr vorhanden ist oder verändert wurde (also auch noch hashen).

[Perlsau]

Zitat:

Zitat von MeierZwoo (Beitrag 1222788)

Sorry, aber ich bin weder der Benutzer noch der dort zuständige Admin - ICH kann NICHTS auf die Zielkiste DAUERHAFT kopieren. Dann muß ich wie oben auch schon erwähnt, den Druck abbrechen, wenn diese Datei nicht mehr vorhanden ist oder verändert wurde (also auch noch hashen).

Natürlich kannst du dort nichts dauerhaft kopieren, auch nicht deine Anwendung. Aber das ist alles halb so wild, denn erstens kannst du eine unbedingt benötigte Font-Datei in einer Ressurce lagern, und zweitens haben Anwender ohne Admin-Status gewöhnlich keinen Zugriff auf die Programmordner, außer sie setzen noch Win XP ein. Wenn der Anwender deine Anwendung deinstallieren möchte, kannst du natürlich nichts dagegen unternehmen ;-)

Anwendungsfall: Ein Kunde hat sich Rechnungsvordrucke in einer Druckerei drucken lassen und möchte nun, daß seine Rechnungs-Anwendung genau denselben Font verwendet, um ein einheitliches Druckbild zu gewährleisten. Das funktioniert aber nur, wenn der Anwender den benötigten Font installiert hat – oder wenn ich die Fontdatei mitliefere und für die Dauer der Anwendungs-Sitzung genau diesen Font zur Verfügung stelle. Wenn der Anwender XP einsetzt, könnte er im Grunde die Fontdatei im Anwendungsordner löschen, was zwar eine blöde Idee wäre, aber es soll ja keinen DAU geben, den es nicht gibt. Also verwahre ich die Fontdatei in der Exe (eingebunden als Resource) und kopiere sie bei jedem Anwendungsstart in den Anwendungsordner, wenn sie fehlen sollte oder verändert wurde. Wo ist das Problem :?:

Übrigens können Anwender, die mit Win XP arbeiten, auch leicht andere benötigte Dateien aus dem Programmordner löschen, z.B. DLLs wie z.B. bei einer Datenbankanwendung, die Firebird Embedded verwendet. Vielleicht löschen sie auch die Datenbank oder gar die Exe ("... ich hab halt kürzlich gelesen, daß Exe-Dateien gefährlich sind ..."), wer weiß das schon? Mit anderen Worten: Du kannst nicht alle Eventualitäten, die ein DAU herbeiführen könnte, berücksichtigen. Ein Bekannter von mir arbeitet bei einer Hotline, der könnte dir Geschichten erzählen, das glaubst du nicht ...

[Furtbichler]

Also:
1. Wenn es geht, den Barcodegenerator des Druckers verwenden (z.B. Zebra-Druckersprache)
2. Sonst einen guten Reportgenerator verwenden, der Barcodes anhand der Zieldruckerauflösung pixelgenau rendert.
3. Sonst nach einer Delphi-VCL Barcodekomponente suchen (Andreas Schmidt, siehe torry.net) und auf die Zieldruckerauflösung rendern.
4. Oder eben einen Font verwenden (nur für 'große' Barcodes mit einer minimalen Balkenbreite von 3-4pxl)

Auch, und bitte *immer* die Druckerqualität berücksichtigen, mein Tintendrucker z.B. druckt auf normalem Papier Barcodes aus, die zwar pixelgenau sind, aber wegen des Verlaufens der Tinte von keinem Scanner der Welt gelesen werden können. Na gut, Interleaved 2 aus 5 mit einem 6 stelligen Code über die Seitenbreite geht dann doch.

[Satyr]

Wenns schnell gehen soll, keine 100%ige Datensicherheit braucht und Internet verfügbar ist, lässt es sich auch mit der Google API generieren.
In Delphi habe ich damit bisher nur als Spielerei QR Codes generiert. Aber Barcodes sind wohl auch möglich. Zumindest macht dies diese Seite so -> http://www.barcodes4.me/apidocumentation

Zwar in PHP aber das lässt sich für Delphi bestimmt adaptieren. Geht ja bei QR Codes auch.

[Mavarik]

Also QR-Code ist ein 2D barcode... Aber egal...


Code 39 und EAN lassen sich doch mit wenigen Zeilen selber erzeugen...

Hab ich mal in einem Nachmittag mit Turbo pascal 2.0 schon gemacht.

[Furtbichler]

Zitat:

Zitat von Mavarik (Beitrag 1222817)

Also QR-Code ist ein 2D barcode... Aber egal...

Da ist sich die Gemeinde mittlerweile wohl nicht mehr sicher, was ein Barcode (Balken/Strichcode) ist. Aber wirklich egal.

Zitat:

Zitat von Mavarik (Beitrag 1222817)

Code 39 und EAN lassen sich doch mit wenigen Zeilen selber erzeugen...Hab ich mal in einem Nachmittag mit Turbo pascal 2.0 schon gemacht.

Och bitte nicht *noch* eine Implementierung, die dann vielleicht nicht alle Spezifikationen (Clearzone etc.) umsetzt. Das geht ja nicht gegen dich, aber was ich in der Zwischenzeit für Schrottimplementierungen gesehen habe, geht auf keine Kuhhaut. Bitte bitte eine professionelle, ausgereifte Lösung.

Niemand druckt Barcodes als Hobby, dann kann man sich die paar Kröten für eine anständige Lösung auch leisten.

[Mavarik]

Zitat:

Zitat von Furtbichler (Beitrag 1222829)

Zitat:

Zitat von Mavarik (Beitrag 1222817)

Also QR-Code ist ein 2D barcode... Aber egal...

Da ist sich die Gemeinde mittlerweile wohl nicht mehr sicher, was ein Barcode (Balken/Strichcode) ist. Aber wirklich egal.

Zitat:

Zitat von Mavarik (Beitrag 1222817)

Code 39 und EAN lassen sich doch mit wenigen Zeilen selber erzeugen...Hab ich mal in einem Nachmittag mit Turbo pascal 2.0 schon gemacht.

Och bitte nicht *noch* eine Implementierung, die dann vielleicht nicht alle Spezifikationen (Clearzone etc.) umsetzt. Das geht ja nicht gegen dich, aber was ich in der Zwischenzeit für Schrottimplementierungen gesehen habe, geht auf keine Kuhhaut. Bitte bitte eine professionelle, ausgereifte Lösung.

Niemand druckt Barcodes als Hobby, dann kann man sich die paar Kröten für eine anständige Lösung auch leisten.

Ich habe Code 39 in unserem Ladenlokal eingesetzt. Natürlich war das nicht zum Spass... Aber ich wollte auch gar nicht meine Unit hier Posten :stupid:

Mavarik

[Furtbichler]

War blöd von mir formuliert. :oops: Du sollst nur bitte bitte niemanden dazu animieren, sich seine Barcodekomponente selbst zu schreiben, die er dann in in die freie Wildbahn entlässt. Das das aus Übungsgründen und zum Verständnis des Aufbaus von Barcodes ganz sinnvoll sein kann und Spaß macht, steht auf einem anderen Blatt.

[Patito]

Zitat:

Zitat von Furtbichler (Beitrag 1222853)

Du sollst nur bitte bitte niemanden dazu animieren, sich seine Barcodekomponente selbst zu schreiben, die er dann in in die freie Wildbahn entlässt.

In Delphi habe ich leider so viele fehlerhafte Implementierungen von Barcodes gesehen, dass ich dazu aufrufen würde, bitte mehr Barcodekomponenten zu schreiben. Ich denke mal jeder Anfänger hat es da leicht der Beste am Markt zu werden.

Mit Fast-Reports funktioniert Code128 mittlerweile einigermaßen (vermutlich?) (wenn man ein paar nicht dokumentierte Features selbst errät).
Bug Reports gibt es dazu seit vielen vielen Jahren. Und ich habe bereits mehr Zeit damit verloren irgendwelche Test-Versionen auszuprobieren als wenn ich das ganze selbst gemacht hätte.

[MeierZwoo]

Zitat:

Zitat von Patito (Beitrag 1222894)

.. dass ich dazu aufrufen würde, bitte mehr Barcodekomponenten zu schreiben. Ich denke mal jeder Anfänger hat es da leicht der Beste am Markt zu werden.

Zitat:

Zitat von Patito (Beitrag 1222894)

..ich habe bereits mehr Zeit damit verloren irgendwelche Test-Versionen auszuprobieren als wenn ich das ganze selbst gemacht hätte.

Damit widersprichst Du dir aber selber - obwohl das letztere wahr ist. Vorallem, wenn die Lösung besonders elegant ist - such dann mal nach Fehlern oder auch nur der Funktionsweise.

Zitat:

Zitat von Patito (Beitrag 1222894)

(wenn man ein paar nicht dokumentierte Features selbst errät)

Was mich an den meisten veröffentlichten Units (nicht nur zu Barcodes) stört: Dokumentation fast gleich Null. Und sich durch fremden Quellcode wühlen, um die Funktion zu begreifen, ist viel Arbeit. Bei den wenigen Dingen, die ich veröffentlicht habe oder einem Programm beifüge, hat die Dokumentation meist mehr Arbeit gemacht als das Programm(teil) selbst.

Ich dokumentiere meist nur für mich selbst - denn wenn ich es ordentlich beschreiben muß, fallen mir meine Unzulänglichkeiten auf.

[matashen]

...nachdem ganzen Fontgeplänkel möcht ich nochmal auf meine Antwort hinweisen.

probiert mal zint
Das liefert so ziemlich jeden Barcode oder 2D-Code den es so gibt... und alles ohne font und mit Visueller Komponente.

[p80286]

Zitat:

Zitat von MeierZwoo (Beitrag 1222898)

Ich dokumentiere meist nur für mich selbst - denn wenn ich es ordentlich beschreiben muß, fallen mir meine Unzulänglichkeiten auf.

Was meinst Du wohl warum es so wenig (gute)Dokumentation gibt:stupid:

Gruß
K-H

[MeierZwoo]

Zitat:

Zitat von p80286 (Beitrag 1222911)

Was meinst Du wohl warum es so wenig (gute) Dokumentation gibt:stupid:

... weil die ja doch niemand liest. Werden ja als erstes entsorgt :roll:

[Patito]

Zitat:

Zitat von matashen (Beitrag 1222901)

probiert mal zint
Das liefert so ziemlich jeden Barcode oder 2D-Code den es so gibt... und alles ohne font und mit Visueller Komponente.

Welche Lizenz hat denn die zint.dll?

In den interessanten SourceCode-Files sehe ich überall nur GPL.

[matashen]

Zint ist GPL

[Mavarik]

Zitat:

Zitat von Furtbichler (Beitrag 1222853)

War blöd von mir formuliert. :oops: Du sollst nur bitte bitte niemanden dazu animieren, sich seine Barcodekomponente selbst zu schreiben, die er dann in in die freie Wildbahn entlässt. Das das aus Übungsgründen und zum Verständnis des Aufbaus von Barcodes ganz sinnvoll sein kann und Spaß macht, steht auf einem anderen Blatt.

Ohh... Da bin ich aber ganz anderer Meinung...

Ich gebe Dir Recht, dass es super nervig ist, fehlerhafte Implementierungen zu verwenden, aber...

Wenn Du dir anschaust, wie viele Sourcen es in C++ gibt und wie wenig in Delphi, bin ich froh um jede weitere Implementierung in Delphi.

Und das gilt nicht nur für Barcodes sondern für alle Bereiche.

Wenn ich sehe wie viele Fragen hier beantwortet werden mit: Nutze doch die Komponente oder kauf doch die Library...

Wir sind doch Programmierer und nicht Library "zusammenklicker", oder?

Mavarik

[p80286]

Zitat:

Zitat von Mavarik (Beitrag 1222921)

Wenn ich sehe wie viele Fragen hier beantwortet werden mit: Nutze doch die Komponente oder kauf doch die Library...

Wir sind doch Programmierer und nicht Library "zusammenklicker", oder?

Aber man kann doch nicht jeden S**** selber machen. Vor 2 Jahren hab ich mal einen Barcode benötigt, der Font den ich gefunden hatte war brauchbar also Problem gelöst.

Wenn Dein tägliches Brot immer mal wieder Barcodes enthält, dann ist es sicher sinnvoll da was eigenes zu stricken.

Gruß
K-H

[MeierZwoo]

Zitat:

Zitat von Mavarik (Beitrag 1222921)

Wir sind doch Programmierer und nicht Library "zusammenklicker", oder?

Dann darfst Du aber auch keine Hochsprache und deren umfangreiche Sammlung mehr benutzen, sondern nur noch einen Assembler und Linker - vorallem keine IDE. :lol: Also ich bezeichne mich als Anwendungsprogrammierer - deshlab bin ich auch damals bei Turbo-PASCAL gelandet (a PASCAL, b erste IDE) und kümmere mich mehr um die fachliche Seite der Anwendung als um besonders eleganten Quellcode. Da bin ich froh über jede Unit, die ich nicht selber neu erfinden muß - nur korrekt funktionieren muß sie auch!

Zitat:

Zitat von Mavarik (Beitrag 1222921)

Wenn Du dir anschaust, wie viele Sourcen es in C++ gibt und wie wenig in Delphi, bin ich froh um jede weitere Implementierung in Delphi.

Es kommt aber auf die Qualität und nicht auf die Quantität an!

[Furtbichler]

Zitat:

Zitat von Mavarik (Beitrag 1222921)

Wir sind doch Programmierer und nicht Library "zusammenklicker", oder?

Also ich weiß nicht, was Du bist oder sein willst. Ich bin professioneller Problemlöser und ich verwende zum Lösen des Problems und damit zur Zufriedenstellung des Kunden die besten und geeignetsten Mittel, um das Problem (oder die Aufgabe) innerhalb des finanziellen und terminlichen Rahmens optimal zu lösen bzw. umzusetzen.

Ob ich selbst programmiere oder programmieren lasse, oder Libraries selbst schreibe, schreiben lasse oder fertige Komponenten kaufe, entscheide ich situativ. Ehrlich gesagt versuche ich, so wenig wie möglich selbst zu programmieren. Ich bin doch nicht so blöd und erfinde jedesmal das Rad neu oder arbeite mich zwangsweise in Dinge ein, die andere aus dem Ärmel schütteln.

Sofern ich professionelle Hilfsmittel dafür einsetze, also RDBMS, Reportgeneratoren, Barcodekomponenten. fertige TCP-Protokolle etc., dann mache ich das eben. Eine kurze Überschlagsrechnung zeigt mir, das ich z.B. für eine professionelle und ausgereifte Barcodekomponente z.B. 500 Euro ausgeben muss (Beispiel). Das entspricht 1-2 Tagessätzen, wenn ich es entwickeln lasse. Also wer mir dafür eine fertige Komponente fehlerfrei mit Support und Garantie programmiert, muss schon ein toller Hecht sein.

Als Jugendlicher fand ich es geil, alles selbst zu programmieren, auch noch, als ich anfing, Geld damit zu verdienen, mir aber der Stundensatz egal war. Aber mittlerweile muss ich anders denken und daher bin ich eben -wie Du es so schön nennst- "Libraryzusammenklicker", wobei ich mich frage, was der Delphi-Programmierer, der die VCL, die Indies, ADO, Zeos, xxxDAC etc. verwendet, denn anderes ist.

[arnof]

Deshalb benutzt man ja Delphi, weil es hier viele gute Komponenten gibt. Andere Systeme haben hier zwar aufgeschlossen, vielleicht aber überholt.

Es kommt immer darauf an möglichst schnell eine möglichst gute Lösung zu erreichen. Dem Kunde ist es egal, ob im Hintergrund z.B. ein unsichtbares Memo, Listbox oder so zum schnellen Laden und speichern liegt oder ob man alles schön sauber programmiert. Das Aldiprinzip ist gefordert "gut und preiswert".

Es gab Zeiten, wo ich mit meinem guten GFA-Basic (auch unter C++) noch die Grids und die EDITboxen selbst auf dem Bildschirm gemalt habe (incl. Schatteneffekte und den Cursor in die Form gemalt habe), sowas will man einfach nicht mehr ......

[Mavarik]

[OT]

Zitat:

Zitat von Furtbichler (Beitrag 1222952)

Sofern ich professionelle Hilfsmittel dafür einsetze, also RDBMS, Reportgeneratoren, Barcodekomponenten. fertige TCP-Protokolle etc., dann mache ich das eben. Eine kurze Überschlagsrechnung zeigt mir, das ich z.B. für eine professionelle und ausgereifte Barcodekomponente z.B. 500 Euro ausgeben muss (Beispiel). Das entspricht 1-2 Tagessätzen, wenn ich es entwickeln lasse. Also wer mir dafür eine fertige Komponente fehlerfrei mit Support und Garantie programmiert, muss schon ein toller Hecht sein.

Dein finanzieller Ansatz ist sicherlich richtig...

Wenn dann die Library auch noch im Source daher kommt... OK...

Ich habe für meine Programme einen Grundsatz...

Es kommt nur rein, was ich auch im Sourcecode habe...

Grüsse Mavarik :coder:

[/OT]