Sonderfunktionen eines Drucker ermitteln und setzen?

[Xanadu]

Ich habe ein Delphi-Programm mit dem ich aus einer Dos-Box oder einem Dos-Programm ohne Dialog eine Datei auf einem Windowsdrucker ausdrucken kann. Druckerauswahl und allgemeine Druckereinstellungen werden dabei als Parameter übergeben. Das funktioniert auch bei den meisten Druckern nur habe ich nun ein paar neue Drucker "Ricoh Aficio 1232 C" ins Netz gekriegt. und die verlangenen im PrinterSetupDialog einen Anwendercode. Da die alte Dos-Anwendung meist im Vollbildmodus läuft bzw. automatisch druckt (Packscheine etc.) kann ich den Druckerdialog auch nicht einfach anzeigen weil oft garkein Anwender davor sitzt.

Meine Frage nun, wie kann ich derartige Druckerspezifische Funktionen ermitteln und vor allem auch setzen?

Mit PrinterProperties, DeviceCapabilities, GetDeviceCaps und SetDeviceCaps find ich bisher nur allgemeine Einstellungen, nicht aber diese spezielle Funktion.

Gruß, Bernd

[marabu]

Hallo Bernd,

die Eingabe eines user code ist doch wahrscheinlich nur für das accounting im interaktiven Betrieb notwendig. Wenn du darauf verzichten kannst solltest du diesen Modus wegkonfigurieren können.

Grüße vom marabu

[Xanadu]

marabu schrieb:

Zitat:

die Eingabe eines user code ist doch wahrscheinlich nur für das accounting im interaktiven Betrieb notwendig. Wenn du darauf verzichten kannst solltest du diesen Modus wegkonfigurieren können.

Hallo marabu,

leider sind die Drucker Etagendrucker und werden von mehreren Abteilungen genutzt. Daher sind die Usercodes für die Kostenverteilung nötig. Ich kann den Krempel also leider nicht wegkonfigurieren.

Habe nun schon versucht den Usercode via Escapesequenz in PCL/PJL zu setzen. Das tut allerdings auch nicht.

Delphi-Quellcode:

...
Printer.BeginDoc;
Escape(Printer.Handle, PASSTHROUGH, 0, '@PJL SET USERCODE="xy"', nil);
Printer.TextOut('Testdruck');
Printer.EndDoc;

Wenn ich allerdings vorher einen TPrinterSetupDialog ausführe dann funktioniert es.

Delphi-Quellcode:

...
if PrinterSetupDialog.Execute then
begin
  Printer.BeginDoc;
  Printer.TextOut('Testdruck');
  Printer.EndDoc;
end;

Das hilft mir nur nicht weiter da einige Programme zum Druck von Packscheinen und Arbeitspapieren ohne Anwendereingaben drucken müssen.

Ich hab daher die Funktionen des TPrinterSetupDialogs mal um den eigentlichen Dialogaufruf abgespeckt. Das hilft aber auch nicht. D.h. trotz GetPrinter/SetPrinter und dem ganzen Krempel läuft auch nix.

Auf den Seiten von Ricoh gibt es im bezahlbaren Bereich auch keine Infos und der Händler ist mit der Frage auch überfordert.

Hoffe nun auf einen Tip von jemand der mit dem Problem vielleicht schon konfrontiert war.

Gruß, Bernd

[marabu]

Hallo Bernd,

habe gerade keinen Ricoh Aficio 1232 C zur Hand. Ich habe statt dessen meinen OKI C5300DN untersucht. Das accounting feature wird über eine spezielle printer control software gesteuert, die als server und client Variante installiert wird. Wenn ich das job accounting aktiviere, dann kann ich unter anderem zwischen popup und hidden mode wählen. Im popup mode muss der user seine credentials in einen Dialog eintippen, im hidden mode legt der Admin einen control file an, der dann befragt wird.

Vielleicht arbeitet der Ricoh ähnlich?

marabu

[Xanadu]

Hallo marabu,

heissen Dank für den Tip, werde mich da in der Richtung noch schlau machen.

Gruß, Bernd

[Xanadu]

Hi marabu,

ich bin jetzt ein Stückchen weiter gekommen. Dein Lösungsansatz war mir noch nicht so genehm weil es einfach einen klareren Ansatz in Punkto Programmierung geben muss.

Von Ricoh hab ich zwar noch immer keine Antwort - spricht für den Hersteller, scheint also sehr lean oder outgesourced zu sein - also da kann man wirklich für billiges Geld kaufen zu können! - TCO!...?

Mein Händler hat mich aber zwischenzeitlich um ein "Printfile" gebeten und das Thema hat mich weiter gebracht.

Mit einem Printerdialog bzw. einem PrinterSetupDialog vor dem Druck tut es. Ich hab dann einfach mal PrinterDialog.Options := [poPrintToFile] gesetzt und in eine Datei gedruckt. Das Ergebnis war, dass nach dem Printer.BeginDoc schon Daten im Druckspooler sind bevor mit Escape(...) Sequenzen rüber gehen. das scheint den Drucker zu irritieren weil er von den beiden Dialogen (PrintDialog und PrinterSetupDialog) gewohnt ist seine PJL-Commands am Anfang des Druckstreams zu kriegen.

Habe darauf hin in der printers.pas nachgeschaut was bei BeginDoc so passiert und da geht einiges ab.

Zur Info gibt es von Borland einen Hinweis ohne TPrinter zu drucken Drucken ohne TPrinter, zum Anderen hab ich auch noch was gefunden um ohne PrinterDialog (und PrinterDialog.Options := [poPrintToFile]) etc. DialogLos in eine Datei zu drucken Druck in eine Datei Drucken

Ggf. ist bei letztem Link noch ein Refresh zu machen weil man sonst beim ersten Aufruf nicht immer auf dem Link selbst landet.

Mein Problem scheint nun irgendwo zwischen dem Dialog und direkt nach Printer.BeginDoc zu liegen. Im TPrinterSetupDialog gibt es ein Konstrukt lpszIrgendwas:= DialogHook und ich vermute, dass an dieser Stelle über ein Hook irgend ein PStringPointer vom Hersteller initialisiert wird in dem dann die ganzen @PJL-Befehle vor dem eigentlichen Printer.BeginDoc stehen.

Wenn meine Suche erfolgreich ist poste ich das natürlich, bin jetzt aber noch am suchen wo ich die Initalisierung reinbauen muss.

ImKlartext habe ich im PrintFile mit Dialog sowas wie

Zitat:

<ESC>-12345X@PJL SET USERCODE="xy"&%$...

stehen
und ohne Dialog aber mit Escape dirkt nach Printer.BeginDoc sowas wie

Zitat:

&%$..%<ESC>-12345X@PJL SET USERCODE="xy"§$&...

stehen

(&%$.. sind dabei natürlich Platzhalter und <ESC> steht für #27)

Schlussfolgerung für mich ist daher das Printer.BeginDoc schon einen Elementarstrom an Daten an den Drucker schickt und ich bisher mit meiner Escape-Sequenz soweit zu spät gekommen bin das der Drucker das einfach nicht mehr interpretiert weil es nicht am Anfang steht.

Direkt vor Printer.BeginDoc tut Escape(...) ...Use PASSTHROUGH Escape to Send Data Directly to Printer? noch nicht weil der Drucker(Treiber) bzw. der Spooler noch nicht "Printing" ist. Also kann es nur zwischen vor und direkt nach Printer.BeginDoc liegen. Nachdem da nix ist kann es also nur irgendeine wilde C-Struktur oder Printer.BeginDoc selbst sein.

Wenn irgendwo noch eine Idee zu diesem Thema da ist bin ich (geiffer :gruebel: ) gern und willentlich offen, andernfalls ist halt try und ggf. except statt finally angesagt.

Insgesamt danke an marabu für den Workaraound, will aber das Problem bewältigen und nicht umschiffen.

Gruß, Bernd

[Xanadu]

Sorry, noch was vergessen bzw. Versäumt zu erwähnen:

Zitat:

Schlussfolgerung für mich ist daher das Printer.BeginDoc schon einen Elementarstrom an Daten an den Drucker schickt und ich bisher mit meiner Escape-Sequenz soweit zu spät gekommen bin das der Drucker das einfach nicht mehr interpretiert weil es nicht am Anfang steht.

Der Drucker kann eigentlich garnicht anders weil er am Anfang des Druckjobs die Zertifizierung brauch. Denke mal und gehe davon aus dass andere @PJL-Commands im Druckjob verarbeitet werden, aber der User sich ganz zu Beginn identifizieren muss weil sonst der Job einfach wegen mangelnder Authentifizierung ge"chancel"´d werden muss.

Gruß, Bernd

[generic]

wenn es dir nur um die anwenderid geht, die kann bei jedem user explizit gesetzt werden
dazu brauchst du nur in den "druckeinstellungen" die id setzen.

[shmia]

Zitat:

Zitat von Xanadu

Meine Frage nun, wie kann ich derartige Druckerspezifische Funktionen ermitteln und vor allem auch setzen?

Du kannst über den Windows-Spooler auch direkt Roh-Daten an den Drucker senden. (aber nur senden nicht lesen)
Die Daten werden in einem eigenen Printjob übermittelt.
http://community.borland.com/dsp/ftp...e/rawprint.zip

[Xanadu]

generic schrieb:

Zitat:

dazu brauchst du nur in den "druckeinstellungen" die id setzen.

Hallo generic, ich hab in den Druckeinstellungen die Anwenderid an zwei Stellen gesetzt. Nur kommen diese Infos nicht rüber wenn ich ohne vorgeschalteten Dialog drucke.

shmia schrieb:

Zitat:

Du kannst über den Windows-Spooler auch direkt Roh-Daten an den Drucker senden. (aber nur senden nicht lesen)
Die Daten werden in einem eigenen Printjob übermittelt.

Hallo shmia, das mit dem zweiten Printjob vereitelt den Erfolg. Der Drucker prüft jeden Printjob einzeln ob er gedruckt werden "darf" oder nicht. Wenn ich nun zuerst die RAW-Daten schick hätten die dann zwar das "Recht", der nachfolgende Druck würde dann aber wieder abgewiesen.

Ich suche jetzt nach einer Möglichkeit den Druck ohne einen vorgeschaltenen Dialog in eine Datei zu kriegen und der dann die "@PJL Commands" voran zu setzen. Danach könnte ich dieses File dann im RAW-Format rüber schieben. Bin aber noch nicht weit gekommen weil alle Lösungsansätze die ich finde immer mit der PrnDlgRec schaffen die im Druckdialog aufgebaut wird.

Gruß, Bernd