Problem bei Devmode und Schachtansteuerung

Mit dem Beispielprogramm DevMode (Verändern der Druckerdatei LSP Drucker, Kopien, Schacht usw. LSP mit SetprinterinPrintfile)
habe ich folgendes Problem:
Es funktioniert NICHT:
Ich habe einen physischen Drucker zweimal installiert. Einmal mit Schwarzweiß, einmal mit Farbe.
Mit Devmode sollte ich den Drucker entsprechend auswählen können. Das funktioniert leider NICHT.
Irgendwie nimmt er Einstellungen laut Disign oder laut Standarddrucker.
Das gleich Problem ergibt sich, wenn ich verschiedene Schächte den zwei Druckern zuordne.
Es wird zwar der richtige physische Drucker “getroffen” allerdings ignoriert das Programm die
Einstellungen von Schacht bzw. Farbe.
Die Ansteuerung eines physisch anderen Druckers funktioniert.

Dieses Problem tritt in folgenden Konfigurationen auf:
LL 16, akutelles SP, Windows 7 - Admin (und zwar wirklch echter Admin) VB6 SP5

Mehr, als dass ähnliche Probleme schon andere Programmierer hatten, habe ich leider noch nicht herausgefunden.
Ein Debug-Listing habe ich an den Combit-Support schon geschickt. Vielleicht finden die was raus.

Oder hat doch wer von Euch Erklärungen oder Lösungen?

Sollte jemand ein ähnliches Problem haben. Die Lösung sieht so aus:
Es wurden die letzten Druckertreiber heruntergelanden und die Drucker unter einem sehr kurzen Druckernamen gespeichert.
Danach funktionierte alles wie gewünscht.
Es waren zu 99% die neuen Druckertreiber. Die zuvor installierten waren sehr alt.
Die kurzen Druckernamen wurde nur sicherheitshalber vergeben, da das - laut Forenbeiträgen - ebenfalls zu Problemen führen kann, da LL-Intern ab einer gewissen Länge der Name abgeschnitten wird.

Hallo Norbert,

danke für den Hinweis!

Das Problem hatte ich bis eben auch. Dabei habe ich nichtmal Devmode verwendet, sondern in den Druckereigenschaften im System eien Schacht fest eingestellt. LL hat das einfach ignoriert, egal ob Standarddrucker oder nicht. Tatsächlich wird das Problem mit einem neuen Treiber gelöst, die Länge des Druckernamens scheint dabei keine Rolle zu spielen. Seltsam ist nur, dass mit dem alten Treiber aus anderen Anwendungen heraus problemlos auf den richtigen Schacht gedruckt wurde. Wäre mal interesant die Ursache zu kennen, aber die Antwort vom Support ist noch nicht da :wink:

Gruß, Michael

Servus Michael,

freut mich, dass ich Dir da weiterhelfen konnte.
Ich muss zugeben, dass ich schon vor Jahren einige Probleme mit LL hatte, die mit neuen Treibern
gelöst werden konnten. Damals kam auch der Hinweis vom Support, generell nur die neuesten Druckertreiber zu verwenden.
Nur diesmal habe weder ich noch der Support daran früher gedacht.
Erst mit dem Debug-Protokoll (falls Du das noch nicht verwendetst, das ist es Wert, sich damit zu beschäftigen)
tauchten Fehler auf, die auf nicht aktuelle Treiber hingewiesen haben.

Viele Grüße
Norbert

Hallo Norbert,

das ist ja interessant. Ja das gute Debug Protokoll - das verrät mir immer, welchen Feldnamen ich mal wieder falsch übergeben habe :slight_smile:

Hab eben mal geschaut: “Driver Date: 01.01.1601” - ja, das ist alt. Außerdem ist mir aufegfallen, dass “dmDefaultSource = 15” (in meinem Fall) nicht korrekt ist. Gibt es noch etwas auf das man achten sollte/kann? Nicht dass es nötig wäre, ein neuer Treiber hilft ja. Ist nur so aus Interesse :slight_smile:

Gruß, Michael

Hallo Michael,

bezüglich Druckeransteuerung wärs das gewesen. War eh zeitraubend genug.
Aber eine hab ich noch …
Ich hatte beim Umstieg von LL14 auf LL16 auf einmal gröbste Probleme mit dem Zeitverhalten.
Sprich, es dauerte um ca 40 sec. länger, bis ein einseitiges Formular in der Preview oder am Drucker
auftauchte.
Ursache: Der Parameter, ob alle Drucker im System überprüft werden sollen, war auf true (default).
Dieser Parameter (irgendwas mit PrinterCheck - siehe Handbuch) war auf “nicht überprüfen” zu setzen.
Damit war die Geschwindigkeit wieder OK.

Viel Grüße
Norbert