Hallo,

ich habe eine Delphi Anwendung die direkt ESC/POS Kommandos zum Drucker schickt. Bisher ging alles gut, bis ich gelesen habe, dass WritePrinter eine blockierende Anweisung ist und das dann in einen Thread verlagert habe. Seit dem wird nur noch Müll gedruckt.

Hat jemand eine Idee?
Delphi berlin, die zu druckenden Testdaten kommen sauber in der Drucken methode die über die Execute-Methode aufgerufen wird an.

Grüße

Turbomagick

Und das openprinter ist im gleichen thread?

Gruß
k-H

Wie ich gerade sehe ist es das nicht. Das wird vorab mal "irgendwann" aufgerufen. Wenn ich später zum programmieren komme versuche ich mal, das in die Execute zu verlagern. Musds ich aber erst prüfen welche anderen Konsequenzen das hat.

Habe jetzt das Open Printer testhalber in den Thread verlagert, Drucker druckt aber immer noch Schrott!
Ich ziehe mal die alte Drucken Unit aus der Quelltextverwaltung und probier's mal ohne Thread.

So, Drucken wieder auf alten Stand mit Drucken aus VCL GUI Thread heraus umgestellt. Druck klappt wieder. Außerdem eben nochmal die These mit "Open Printer im Druck Thread aufrufen" getestet und wiederlegt.

Ich habe meine Unit kopiert und sowohl die Unit als auch die Klasse umbenannt. Dann im Hauptprogramm einen Testmenüpunkt zum Ausdruck des Testbons eingebaut und die Klasse auf TThread so umgestellt, dass diese suspended erzeugt wird (im Constructor wird das Druckerhandle besorgt!). Den Code aus der Testdruck Methode in die Execute verlagert und in der Testdruck Methode Start; aufgerufen.

Druckt prima und keinen Quatsch.

=> Besorgung des Handles via OpenPrinter muss nicht im thread selbst erfolgen
=> Mein Fehler muss woanders liegen, vermutlich in der Übergabe der Daten an den Thread, wobei die eigentliche Druckausgabe Routine sauber aussah. Mal sehen.

So, nach dem ich es wieder auf die alte Fassung umgestellt hatte, damit das Druckern überhaupt funktioniert, bin ich es nochmals angegangen. Ich habe es jetzt erfolgreich auf Multithreaded umgestellt und OpenPrinter befindet sich nicht im Thread selbst.

Warum überhaupt Drucken mit dieser Methode? Macht eigentlich nur noch Sinn wenn man alte Drucker mit seriellem Anschluss einsetzt.

Man kann bei Druckern mit "modernen" Schnittstellen wie USB oder Ethernet auch problemlos über den Windows-Druckertreiber drucken und die Bons z.B. mit Fastreports erstellen.

Das bringt dann viele Freiheiten bei der Gestaltung, wie Schriftart und Größe, Ränder, und weiteren Formatierungen sowie die Verwendung von Scripten im Report.

Drucken mit dieser Methode kommt daher, dass das Programm ursprünglich auf einer Windows version laufen sollte für die es keinen Druckertreiber mehr gibt. Außerdem ist mir noch nicht klar, wie ich die Sonderfunktionen wie den Cutter aus FastReports bzw. mittels TPrinter basiertem Drucken benutzen kann.

Mit FastReports habe ich auch noch nicht viel gemacht (will ich ändern, Zeit ist aber auch immer ein Thema).
Ist es möglich in fastReports auch Reports zu erstellen, deren Daten nicht aus einer Datenbank oder einer In-memory Tabelle kommen?
Meine Daten liegen schließlich schon als Business Objete vor.

=> diese Version nochmal wie gehabt und jetzt funktioniert's ja auch wie gewünscht,
dann jedoch alternativ auswählbare Umsetzung mittels FastReports oder normalem Drucken.
Das muss auch mal Geschwindigkeitsmäßig getestet werden, da ich bisher "im Textmodus" drucken
kann, was recht schnell geht, Grafikdrucken (habe ich auch mal testhalber umgesetzt) im
Vergleich aber langsammer geht.

Grüße

TurboMagic