Druckstart dauert ewig

[Jan]

Ich habe gerade ein merkwürdiges Phänomen: Ich drucke ein Dokument. Klappt super. Aber im Moment arbeite ich in einem Netzwerk, da hält der an der Zeile oDrucker:startDoc() minutenlang an. Woran kann das liegen? Der Ausdruck selber ist danach vollkommen OK.

Jan

[Rolf Ramacher]

Hi Jan,

woher weißt du das er bei startdoc() hängt ?? zeige uns doch mal code

[Jan]

Rolf,

woher weiß ich das wohl? Debugger? Zeile für Zeile durchgehen?

Jan

[AUGE_OHR]

Ich habe gerade ein merkwürdiges Phänomen: Ich drucke ein Dokument. Klappt super. Aber im Moment arbeite ich in einem Netzwerk, da hält der an der Zeile oDrucker:startDoc() minutenlang an. Woran kann das liegen? Der Ausdruck selber ist danach vollkommen OK.

fragst du vor o:StartDoc() den o:PrinterStatus() ab ?

Code: Alles auswählen

      oDC := oPrinter:device()
      nStatus := oDC:PrinterStatus()

ich vermute mal das er -2 zurück gibt ...

[Jan]

Hallo Jimmy,

das habe ich nicht abgegefragt. Wird diese Woche auch nix mehr werden. Aber: Ich tippe darauf, das es das nicht ist. Das gleiche Problem habe ich von zwei verschiedenen Rechnern aus auf zwei verschiedene Drucker. Und andere Dokumende werde auf diese beiden Drucker sauber (soll heißen: flott) ausgegeben.

Jan

[AUGE_OHR]

das habe ich nicht abgegefragt.

das würde bei der Lösung des Problems helfen.
wie schon gesagt tippe ich auf -2 im Netzwerk.

Aber: Ich tippe darauf, das es das nicht ist. Das gleiche Problem habe ich von zwei verschiedenen Rechnern aus auf zwei verschiedene Drucker. Und andere Dokumende werde auf diese beiden Drucker sauber (soll heißen: flott) ausgegeben.

also passiert es "nur" bei der Xbase++ Applikation und "nur" bei Netzwerk Druckern und der o:PrinterStatus() ist -2 ?
wenn ja zeigt und mal deine "PrinterPS" ( XbpPrinter():New() ... o:create() ) aussieht ... ich hab da einen "Verdacht"...

[Jan]

Jimmy,

der gesamt Codeteil sieht so aus:

Code: Alles auswählen

oDlgPrint := XbpPrintDialog():new()
oDlgPrint:create()

oDrucker := oDlgPrint:display()

IF oDrucker == NIL
   MasgBox(Kein Drucker ausgewählt", "Achtung")
   RETURN NIL
ENDIF

// Neuen Presentation-Space erzeugen
oPS := XbpPresSpace():new()

// Bedruckbarer Bereich auf dem Papier
aSize := oDrucker:paperSize()
nRandOben := aSize[4]
nRandLinks := IIf(aSize[3] < 0.5, 0.5, aSize[3])
aSize := {aSize[5] - aSize[3], aSize[6] - aSize[4]}
oPS:create(oDrucker, aSize, GRA_PU_LOMETRIC + GRA_PO_TOPLEFT)

// Schriftattribut
aAttrString := Array(GRA_AS_COUNT)       // Schriftttribut bestimmen
aAttrStringOld := GraSetAttrString(oPs, aAttrString)

// Schrift wählen
oFont := xbpFont():new(oPs)
oFont:FamilyName := "Arial"
oFont:nominalPointSize := 12
oFont:create()
GraSetFont(oPs, oFont)
nFontHeight := oPS:setFont():height      // Schrifthöhe für "Zeilenvorschub" feststellen

// Hierfür der 2. Papierschacht
oDrucker:setPaperBin(1)

// Und los gehts mit dem Ausdruck
oDrucker:startDoc("Angebot")

Andere Xbase++-Programme drucken anstandslos.

Auch wenn ich den Druckerdialog weglasse und sofort das Druckerobjekt erstelle, ändert das nichts.

Wie gesagt, ob die Rückgabe wirklich -2 ist kann ich nicht sagen, und kann ich aucherst kommende Woche herausfinden, wenn ich wieder beim Kunden bin.

Jan

[Rolf Ramacher]

Hi Jan,

werden denn andere Druckaufträge an diesem PC mit diesem Netzwerk flott ausgedruckt ??

[Jan]

Moin Rolf,

wie ich oben an Jimmy schrieb: Ja.

Jan

[AUGE_OHR]

Andere Xbase++-Programme drucken anstandslos.

wenn du die selben Routinen in anderen Xbase++ Programme auf dem selben PC / Drucker verwendest und die da funktionieren muss es ein anderes Problem sein.

wie "gross" ist den ca. das was du drucken willst was über das Netzwerk geschickt wird ?
drucken die anderen Xbase++-Programme ähnliche Grössen ? (Bilder etc ? )

btw. "druckst" du "direkt" zum Netzwerk Drucker ? Timeout (bei grössen Dateien) ?

Auch wenn ich den Druckerdialog weglasse und sofort das Druckerobjekt erstelle, ändert das nichts.

hätte ich sonst vorgeschlagen um zu sehen ob das o:create() erfolgreich war.

ich pflege den Druckernamen vorzugeben und das Printer Object so zu erstellen

Code: Alles auswählen

FUNCTION PRINTERPS( cPrinter, nCopies, nPaperBin )
LOCAL oDC    := XbpPrinter():New()
LOCAL aPrint := oDC:list()

   BEGIN SEQUENCE

      IF cPrinter != NIL                         // if NIL use Windows default?
         cPrinter := SearchPrinter( aPrint,cPrinter )
      ENDIF

      IF oDC:Create( cPrinter ) == oDC   // = self
      ELSE
         MsgBox( "! Drucker ist Offline !" )
         BREAK                                   // raus
      ENDIF

      nStatus := oDC:PrinterStatus()

Wie gesagt, ob die Rückgabe wirklich -2 ist kann ich nicht sagen, und kann ich aucherst kommende Woche herausfinden, wenn ich wieder beim Kunden bin.

es gab im Alaska Forum mal eine langen Thread mit o:PrinterStatus() von Netzwerk Druckern ...

[AUGE_OHR]

Code: Alles auswählen

oDlgPrint := XbpPrintDialog():new()
oDlgPrint:create()

oDrucker := oDlgPrint:display()

em ... äh ... hast du den Code verändert ? stand da nicht vorher XbpPrinter() statt XbpPrinterDialog() ?
deshalb ja auch mein Kommentar wegen o:create(cPrinter) was für XbpPrinter() galt

Auch wenn ich den Druckerdialog weglasse und sofort das Druckerobjekt erstelle, ändert das nichts.

... so würde die Aussage ja keinen Sinn mehr machen

mir fällt da noch o:paperbin auf. benutzen die andern Xbase++ Programme auch "den" Schacht ?

[Jan]

Jimmy,

nein, ich habe da nichts verändert. Und nein, auch wenn ich den aperBin() raus nehme, dann bringt das nichts. Hatte ich gestern auch schon probiert.

Jan

[AUGE_OHR]

auch wenn ich den aperBin() raus nehme, dann bringt das nichts.

mich wundert das o:setPaperBin(1) bei dir funktioniert ... welcher Schacht soll den das sein ?

p.s. "nach" einem XbpPrintDialog() würde ich keine Parameter setzte sondern nur "davor"

[Tom]

ProcMon von SysInternals einklinken und beobachten, was geschieht:

http://technet.microsoft.com/en-us/sysi ... s/bb842062

[Jan]

Gerade bekomm ich eine Mail vom Kunden rein. Es scheint wieder reibungslos zu funktionieren. Ohne das ich etwas geändert habe! Intern tippt man jetzt darauf, das der Panda schuld daran ist. Der Virenscanner hält wohl öfters mal innnerbetrieblichen Verkehr auf. Irgendwas in dieser speziellen .exe oder der Anforderung des Druckjobs hat da wohl eine Kaskade von Überprüfungen ausgelöst, die dann diese enorme Verzögerung bewirkt hat.

Wenn das wirklich so ist, würde sich das decken mit Erfahrungen in meiner ehemaligen Firma. Dort wurde der Panda rausgeschmissen, nachdem regelmäßig u. a. der Rechner des Geschäftsführers lahmgelegt wurde durch irgendwelche resourcenfressende Überprüfungen. Gerade Panda scheint da Probleme mit zu haben.

Warum aber gerade der :startDoc() das ausgelöst haben soll ...

Jan

[Jan]

Gute Idee! Dieses spezielle Problem scheint sich ja jetzt zum Glück gelöst zu haben. Aber für die Zukunft werde ich da mal dran denken. Immerhin habe ich das Teil schon auf dem Rechner liegen.

Jan

ProcMon von SysInternals einklinken und beobachten, was geschieht:

http://technet.microsoft.com/en-us/sysi ... s/bb842062

[Martin Altmann]

Moin Jan,

Warum aber gerade der :startDoc() das ausgelöst haben soll ...

wenn der Windows Spooler aktiv ist (also genutzt wird, man kann ja auch direkt drucken), dann wird eine Spooldatei im Filesystem erzeugt, die dann zum Drucker geht. Die muss man übrigens auch hart im Filesystem löschen, wenn man einen blockierenden Druckjob hat den man auch nicht mehr über die GUI aus der Queue gelöscht bekommt.

Viele Grüße,
Martin

[Tom]

Hallo, Jan.

Schön, dass sich das Problem gelöst hat.

Gerade Panda scheint da Probleme mit zu haben.

Alle Virenscanner sind, mit Verlaub, scheiße. Mit Streubomben wird auf Ameisen geschossen. Was dafür gedacht ist, vom extrem unvorsichtigen Internetdaddler bis hin zum Office-Arbeitsplatz alles zu schützen, erzeugt im Ergebnis jede Menge Fehlalarme - und bremst vor allem dateibasierte Datenbanksysteme, aber eben auch Applikationen, die viele Dateien bewegen/generieren, hoffnungslos aus. Ich hatte gerade auch wieder so ein Telefonat, in dem ich einem EDV-Beauftragten erklären musste, warum der Kaspersky in der Standardversion (On-Demand-Scan sämtlicher Daten) dafür sorgt, dass a) der Datenzugriff ausgebremst wird und es b) aufgrund der kaskadierenden Scans sogar zu Timeouts und Datenfehlern kommt. Avira mit seiner beschissenen Heuristik ist ein Thema für sich. Leider gibt es so gut wie keine Möglichkeit, Virenscanner aus der Applikation heraus zu manipulieren (das könnten die Viren dann schließlich auch), so dass wir inzwischen Merkblätter und Handlungsanweisungen verteilen, die mindestens unsere Daten aus dem Scanprozess ausblenden, im Optimalfall aber dafür sorgen, dass tatsächlich nur noch untersucht wird, was auch gefährlich werden kann. Virenscanner in der Standardinstallation kann man damit vergleichen, dass ein Neuwagen nicht mehr alle 20.000 km in die Werkstatt zur Wartung kommt, sondern dass bei jedem Anfahrvorgang Mechaniker herbeispringen und das Auto auf Herz und Nieren untersuchen. Dass man auf diese Weise nicht mehr vorankommt, dürfte eigentlich jedem klar sein.