Win 2000 SP2
Office XP SP1
Ich habe in einer Access Anwendung einige Berichte die auch Bilder
beinhalten.
Die Anwendung ist auf verschiedensten Computern mit den unterschiedlichsten
Kofigurationen installiert und läuft ohne Probleme.
Nur auf diesem einen PC mit der o.g. Konfiguration werden die Berichte
komischerweise nur in Schwarz-Weiss gedruckt.
Normalerweise biete ich dem Anwender vor dem Druck einer Druckerauswahl an,
wo ich den Standarddrucker mit API umstelle und nach dem Druck wieder
zurückstelle. Diese Funktion habe ich jetzt mal deaktiviert und drucke nur
über
DoCmd.OpenReport stDocName, acViewNormal
Auch wieder nur in SW
Nächster Versuch über die Druckvorschau, und dann von dort auf den Drucker
gedruckt. Diesmal werden die Fotos überhaupt nicht gedruckt, der Rest des
Berichtes allerdings schon.
Bin ziemlich ratlos, wo ich das Problem suchen kann. Hat jemand eine Idee
oder Lösung für mich?
Grüsse
Franz
Dass das wohl kaum von Access abhängt, sollte Dir doch bereits
aufgefallen sein. Schau' mal den Druckertreiber und dessen Einstellungen
an (für den Standard Drucker oder eben für den, auf dem Du ausdrucken
willst). Dort steht wahrscheinlich irgendwo in den Geräte Optionen drin,
dass er Graustufen oder Schwarzweiss drucken soll. In Access kann man
das nur über API Gewürge einstellen, sonst wird's einfach so genommen,
wie's halt drinsteht.
Gruss
Henry
--
Keine E-Mails auf Postings in NGs senden!
Don't send e-mails to postings in newsgroups!
KB: http://support.microsoft.com/default.aspx
FAQ: http://www.donkarl.com/FAQ/FAQStart.htm
OH: Online Hilfe von Microsoft Access (Taste F1)
Downloads: http://www.dbdev.org
Danke für die rasche Antwort
"Henry Habermacher [MVP Access]" <DontSp...@psp-online.com> schrieb im
Newsbeitrag news:c3966e$23qf0b$1...@ID-30649.news.uni-berlin.de...
> Hallo Franz
> Franz Schamberger wrote in
> news:405814f5$0$28420$91ce...@newsreader01.highway.telekom.at:
> >
> > Nur auf diesem einen PC mit der o.g. Konfiguration werden die Berichte
> > komischerweise nur in Schwarz-Weiss gedruckt.
>
> Dass das wohl kaum von Access abhängt, sollte Dir doch bereits
> aufgefallen sein. Schau' mal den Druckertreiber und dessen Einstellungen
> an (für den Standard Drucker oder eben für den, auf dem Du ausdrucken
> willst). Dort steht wahrscheinlich irgendwo in den Geräte Optionen drin,
> dass er Graustufen oder Schwarzweiss drucken soll. In Access kann man
> das nur über API Gewürge einstellen, sonst wird's einfach so genommen,
> wie's halt drinsteht.
Hatte ich eigentlich auch vermutet, aber in Word oder Excel druckt derselbe
Drucker brav in Farbe. Also vermutete ich, dass eventuell doch das Problem
bei Access liegt.
Werd mal probieren entweder über API oder das Printer Objekt dem
Standarddrucker die Farbeinstellung zu setzen.
Grüsse
Franz
Franz Schamberger wrote in
news:40582bbb$0$17238$91ce...@newsreader02.highway.telekom.at:
> Hatte ich eigentlich auch vermutet, aber in Word oder Excel druckt
> derselbe Drucker brav in Farbe. Also vermutete ich, dass eventuell
> doch das Problem bei Access liegt.
>
> Werd mal probieren entweder über API oder das Printer Objekt dem
> Standarddrucker die Farbeinstellung zu setzen.
Wenn das so ist, da legt sich Access irgendwo noch zu jedem Druckbaren
Objekt die PrtDev und PrtSonstnochwas Einstellungen ab. Wie man diese
wieder loswird, habe ich bisher noch nicht rausgefunden, ausser auf
folgendem Umweg:
Zuerst das Objekt (in Deinem Fall den Report, der betroffen ist) als
Text speichern. Das geht mittels der verborgenen Funktion
Application.SaveAsText ...
Dann dieses Textfile öffnen und den entsprechenden Passus (steht glaube
ich ganz oben) rausputzen und anschliessend mittels
Application.LoadFromText ...
Wieder in die DB laden.
Wäre interessant zu versuchen, ob's dann geht.
Du kannst auch den Report mal versuchshalber auf einen Nicht-Standard
Drucker stellen und den gleichen Drucker auswählen und dort die
Einstellungen für den Farbdruck vornehmen. Vielleicht geht's dann. Falls
ja, sollte eigentlich mit der Einstellung des Standard Druckers auf
Schwarzweiss, dann sichern und anschliessend wieder auf Farbe das
Problem behoben sein. Vielleicht nimmt Access ja auch nur einen
Standardwert an, weil es noch nicht bemerkt hat, dass der Drucker auch
farbig drucken kann.
> Zuerst das Objekt (in Deinem Fall den Report, der betroffen ist) als
> Text speichern. Das geht mittels der verborgenen Funktion
>
> Application.SaveAsText ...
>
> Dann dieses Textfile öffnen und den entsprechenden Passus (steht glaube
> ich ganz oben) rausputzen und anschliessend mittels
Hab ich probiert, finde allerdings keinen verdächtigen Eintrag.
> Du kannst auch den Report mal versuchshalber auf einen Nicht-Standard
> Drucker stellen und den gleichen Drucker auswählen und dort die
> Einstellungen für den Farbdruck vornehmen. Vielleicht geht's dann. Falls
> ja, sollte eigentlich mit der Einstellung des Standard Druckers auf
> Schwarzweiss, dann sichern und anschliessend wieder auf Farbe das
> Problem behoben sein. Vielleicht nimmt Access ja auch nur einen
> Standardwert an, weil es noch nicht bemerkt hat, dass der Drucker auch
> farbig drucken kann.
Werd ich morgen abend beim Kunden mal probieren, vielleicht finde ich den
Fehler.
Grüsse
Franz
Henry Habermacher [MVP Access] schrieb:
> Wenn das so ist, da legt sich Access irgendwo noch zu jedem Druckbaren
> Objekt die PrtDev und PrtSonstnochwas Einstellungen ab. Wie man diese
> wieder loswird, habe ich bisher noch nicht rausgefunden, ausser auf
> folgendem Umweg:
>
> Zuerst das Objekt (in Deinem Fall den Report, der betroffen ist) als
> Text speichern. Das geht mittels der verborgenen Funktion
>
> Application.SaveAsText ...
>
> Dann dieses Textfile öffnen und den entsprechenden Passus (steht glaube
> ich ganz oben) rausputzen und anschliessend mittels
>
> Application.LoadFromText ...
>
> Wieder in die DB laden.
>
> Wäre interessant zu versuchen, ob's dann geht.
Habs nochmals probiert
Bericht exportiert
PrtMip
PrtDevMode
PrtDevNames
komplett rausgelöscht und Bericht wieder eingelesen. Das verdammte an
der Sache ist, dass es jetzt funktioniert.
Das Fürchterliche ist allerdings, das ich jetzt 95 Berichte vor mir hab
(mir kommen die Tränen).
Jetzt wäre eine gute Gelegenheit, dass mir jemand sagt, wie es kürzer
geht, sonst brech ich zusammen.
Eine kleine Hoffnung hab ich noch. Ich werd mal wieder die
Objektnamen-Autonamenkorrektur vorübergehend einschalten und versuchen
ob er die Änderung vielleicht an alle Berichte weitergibt. Viel Hoffnung
hab ich zwar nicht, aber man klammert sich an jeden Strohhalm.
Trotzdem würde mich interessieren, wie sowas passieren kann?
Grüsse
Franz
Franz Schamberger wrote in news:5n56c.150388$Or1....@news.chello.at:
> Habs nochmals probiert
> Bericht exportiert
> PrtMip
> PrtDevMode
> PrtDevNames
>
> komplett rausgelöscht und Bericht wieder eingelesen. Das verdammte an
> der Sache ist, dass es jetzt funktioniert.
>
> Das Fürchterliche ist allerdings, das ich jetzt 95 Berichte vor mir
> hab (mir kommen die Tränen).
Das kann ich gut verstehen! Würde mir auch so gehen.
Den Export und Import als Text geht noch ziemlich einfach, das kannst Du
mit ein paar CodeZeilen über die
CurrentDB.Containers("Reports").Documents Collection machen und dort die
.Name Eigenschaft auslesen.
Nur wirst Du jetzt all diese 95 erzeugten Textdateien einzeln öffnen
müssen um die entsprechende Sektionen rauszulöschen. Das würde zwar auch
per VBA gehen, aber der Aufwand, das sauber auszuprogrammieren scheint
mir nun doch grösser zu sein, als das händisch zu machen. Allenfalls
kannst Du diese DAteien ja in Word öffnen und dort ein Makro
aufzeichnen, welches diese Sektionen findet und löscht. Anschliessend
dann einfach das Makro für alle diese Textdateien laufen lassen.
>
> Das kann ich gut verstehen! Würde mir auch so gehen.
> Den Export und Import als Text geht noch ziemlich einfach, das kannst Du
> mit ein paar CodeZeilen über die
> CurrentDB.Containers("Reports").Documents Collection machen und dort die
> .Name Eigenschaft auslesen.
> Nur wirst Du jetzt all diese 95 erzeugten Textdateien einzeln öffnen
> müssen um die entsprechende Sektionen rauszulöschen. Das würde zwar auch
> per VBA gehen, aber der Aufwand, das sauber auszuprogrammieren scheint
> mir nun doch grösser zu sein, als das händisch zu machen. Allenfalls
> kannst Du diese DAteien ja in Word öffnen und dort ein Makro
> aufzeichnen, welches diese Sektionen findet und löscht. Anschliessend
> dann einfach das Makro für alle diese Textdateien laufen lassen.
>
Habs jetzt so gelöst, dauert für 96 Berichte knapp 3 Minuten.
Public Sub berichte_aufarbeiten()
Dim cnt As Container
Dim doc As Document
Set cnt = db.Containers("Reports")
For Each doc In cnt.Documents
Debug.Print doc.Name
Application.SaveAsText acReport, doc.Name, "d:\" & doc.Name
Open "d:\" & doc.Name For Input As #1
Open "d:\" & doc.Name & ".txt" For Output As #2
While Not EOF(1)
Line Input #1, a
If InStr(a, "PrtMip") <> 0 Then
Do
Line Input #1, a
If InStr(a, "End") <> 0 Then
Line Input #1, a
Exit Do
End If
Loop
End If
If InStr(a, "PrtDevMode") <> 0 Then
Do
Line Input #1, a
If InStr(a, "End") <> 0 Then
Line Input #1, a
Exit Do
End If
Loop
End If
If InStr(a, "PrtDevNames") <> 0 Then
Do
Line Input #1, a
If InStr(a, "End") <> 0 Then
Line Input #1, a
Exit Do
End If
Loop
End If
Print #2, a
Wend
Close #1
Close #2
Application.LoadFromText acReport, doc.Name, "d:\" & doc.Name & txt"
Next
End Sub
Grüsse
Franz
Franz Schamberger wrote in news:vb27c.188801$Or1....@news.chello.at:
> Habs jetzt so gelöst, dauert für 96 Berichte knapp 3 Minuten.
Freut mich, dass das geklappt hat.
Weiterhin viel Spass mit Access
On Sat, 20 Mar 2004 20:53:47 GMT, Franz Schamberger wrote:
> Habs jetzt so gelöst, dauert für 96 Berichte knapp 3 Minuten.
[gekuerzt]
> Application.SaveAsText acReport, doc.Name, "d:\" & doc.Name
> ...
> Application.LoadFromText acReport, doc.Name, "d:\" & doc.Name & txt"
Bist du sicher, dass das funktioniert?
Abgesehen vom fehlenden (") vor (txt") duerfte diese Vorgehensweise daran
scheitern, dass LoadFromText die Checksum ueberprueft und somit einen
Fehler bringen muesste, wenn du modifizierte Textfiles importierst.
Gruss - Peter
--
Ich beantworte keine Fragen per Email.
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
Peter Doering schrieb:
> Hallo,
>
> On Sat, 20 Mar 2004 20:53:47 GMT, Franz Schamberger wrote:
>
>
>>Habs jetzt so gelöst, dauert für 96 Berichte knapp 3 Minuten.
>
>
> [gekuerzt]
>
>
>> Application.SaveAsText acReport, doc.Name, "d:\" & doc.Name
>>...
>> Application.LoadFromText acReport, doc.Name, "d:\" & doc.Name & txt"
> Bist du sicher, dass das funktioniert?
Funktioniert einmalig, habs jetzt bei zwei Datenbanken laufen lassen,
ohne Probleme.
> Abgesehen vom fehlenden (") vor (txt") duerfte diese Vorgehensweise daran
> scheitern, dass LoadFromText die Checksum ueberprueft und somit einen
> Fehler bringen muesste, wenn du modifizierte Textfiles importierst.
ups, hat sich wohl beim Kopieren verabschiedet. Ist im Original aber
vorhanden.
Hab die Routine aus dem Direktfenster laufen lassen, ohne jegliche
Fehlermeldungen. Die Berichte funktionieren wie vorher, jedoch ohne das
Problem des Schwarz-Weiss druckes.
Trotz allem würde mich interessieren, warum dieses Problem nur unter
Access XP (Vollversion als auch Runtime) und überdies nur auf Druckern
der Marke HP auftritt.
Grüsse
Franz
Peter Doering wrote in
news:c3knnn$299uut$1...@ID-204768.news.uni-berlin.de:
> Abgesehen vom fehlenden (") vor (txt") duerfte diese Vorgehensweise
> daran scheitern, dass LoadFromText die Checksum ueberprueft und somit
> einen Fehler bringen muesste, wenn du modifizierte Textfiles
> importierst.
Wo hast Du das beobachtet? Ich habe schon oft solche Textfiles editiert
und wieder geladen aber noch nie bemerkt, dass da die Checksume
überprüft würde, obwohl sie drin ist. Ich vermute, diese wird eher für
Visual Source Save benötigt, welches tendentiell auch über diese
Funktionen arbeitet, um zu kontrollieren, ob die Kopie noch ok ist.
On Mon, 22 Mar 2004 11:44:43 +0700, Henry Habermacher [MVP Access] wrote:
> Peter Doering wrote in
> news:c3knnn$299uut$1...@ID-204768.news.uni-berlin.de:
>
>> Abgesehen vom fehlenden (") vor (txt") duerfte diese Vorgehensweise
>> daran scheitern, dass LoadFromText die Checksum ueberprueft und somit
>> einen Fehler bringen muesste, wenn du modifizierte Textfiles
>> importierst.
>
> Wo hast Du das beobachtet? Ich habe schon oft solche Textfiles editiert
> und wieder geladen aber noch nie bemerkt, dass da die Checksume
> überprüft würde, obwohl sie drin ist. Ich vermute, diese wird eher für
> Visual Source Save benötigt, welches tendentiell auch über diese
> Funktionen arbeitet, um zu kontrollieren, ob die Kopie noch ok ist.
Ich hab's gerade mehrfach probiert: A02, kleines Formular namens "StdForm"
(ein paar Buttons und Labels, Klasse mit ein bisschen Code ist vorhanden).
- SaveAsText, keine Aenderung am Textfile.
- LoadFromText als "StdForm2" - funktioniert.
- Danach im Textfile nur 1 Zeichen in der Caption eines Labels geaendert.
- LoadFromText als "StdForm3": RT 3011 ... could not find the object
'~sq_fStdForm3'. Make sure the object exists ...
Ich glaube eher, es war Zufall, wenn du's wieder laden konntest.
> Ich hab's gerade mehrfach probiert: A02, kleines Formular namens "StdForm"
> (ein paar Buttons und Labels, Klasse mit ein bisschen Code ist vorhanden).
>
> - SaveAsText, keine Aenderung am Textfile.
> - LoadFromText als "StdForm2" - funktioniert.
> - Danach im Textfile nur 1 Zeichen in der Caption eines Labels geaendert.
> - LoadFromText als "StdForm3": RT 3011 ... could not find the object
> '~sq_fStdForm3'. Make sure the object exists ...
>
> Ich glaube eher, es war Zufall, wenn du's wieder laden konntest.
>
Besteht die Möglichkeit, das es nur bei Reports ohne Probleme funktioniert?
Grüsse
Franz
Franz Schamberger wrote in news:80A7c.207221$Or1.1...@news.chello.at:
>>
>> Ich glaube eher, es war Zufall, wenn du's wieder laden konntest.
>>
>
> Besteht die Möglichkeit, das es nur bei Reports ohne Probleme
> funktioniert?
Mir ist bisher noch kein Fall untergekommen, bei dem es in Access nicht
funktioniert hätte.