[VBA] Drucken heutzutage

Computer: Software & Programmierung Visual Basic
#1

Liebe ExpertInnen,

meine Erfahrungen mit dem Drucken liegen schon etwas länger zurück, deshalb die Frage: Wie druckt der Programmierer heutzutage?

Konkret sitze ich an Access, erzeuge damit Berichte, aber auch Auswertungen, deren Ergebnisse ich nicht speichern möchte. Als Abfragen lassen sie sich eher nicht formulieren, dafür ist (mir zumindest) die Berechnung viel zu aufwendig: Sequentielles Lesen sortierter Bestände, Mischen, Gruppenwechsel - wie früher halt :smile:.

Courier, fehlende Absatzkontrolle, keine Seitenwechsel1 - mit der Formatierung ist es nicht weit her, wenn nur die Anweisung "Print #ff, [Ausgabeliste]"zur Verfügung steht, damit kriege ich nichts Vorzeigbares hin.

Wie macht Ihr das? Geht das aus VBA nicht besser schöner?

Gruß Ralf

1Sowas wurde in der Steinzeit mit Zeilenzählen gesteuert: nächster Absatz hat 17 Zeilen, auffem Blatt sind nur noch 15 Rest - also Fuß drucken, Seitenvorschub, Kopf drucken, jetzt kommt er endlich, der Absatz :smile:

#2

Hallo Ralf,

meine Erfahrungen mit dem Drucken liegen schon etwas länger
zurück, deshalb die Frage: Wie druckt der Programmierer
heutzutage?

er klickt auf Drucken.

Konkret sitze ich an Access, erzeuge damit Berichte, aber auch
Auswertungen, deren Ergebnisse ich nicht speichern möchte. Als
Abfragen lassen sie sich eher nicht formulieren, dafür ist
(mir zumindest) die Berechnung viel zu aufwendig:
Sequentielles Lesen sortierter Bestände, Mischen,
Gruppenwechsel - wie früher halt :smile:.

K.A. was du meinst.

Courier, fehlende Absatzkontrolle, keine
Seitenwechsel1 - mit der Formatierung
ist es nicht weit her, wenn nur die Anweisung "Print #ff,
[Ausgabeliste]"zur Verfügung steht, damit kriege ich nichts
Vorzeigbares hin.

?

Wie macht Ihr das? Geht das aus VBA nicht

Endlich mal was verständliches :smile: Klar geht das, du kannst mittels Vba dem Drucker sagen was er zu tun hat. Das ist easy im Textbereich, bei Grafiken geht das auch ist aber immens aufwendig.

Gruß
Reinhard

besser schöner?

Gruß Ralf

1Sowas wurde in der Steinzeit mit
Zeilenzählen gesteuert: nächster Absatz hat 17 Zeilen, auffem
Blatt sind nur noch 15 Rest - also Fuß drucken,
Seitenvorschub, Kopf drucken, jetzt kommt er endlich, der
Absatz :smile:

#3

Hallo Ralf.

Also ich weiß ja nicht, ob ich mich nun als Experte bezeichnen soll, aber wenn ich irgendetwas drucken möchte, dann schreibe ich mir die Prozedur dafür komplett selbst und wie ich vermute, verhalte ich mich damit wahrscheinlich dann steinzeitlich; eben sehr ähnlich, wie Du es beschrieben hast. Ich denke mir aus, wie die gedruckte Seite aussehen soll und fange dann an, jedem einzelnen Text Koordinaten zuzuweisen. Ich persönlich war bisher lediglich dazu ‚genötigt‘, so etwas für Tabellen bzw. Listen in der Art von Rechnungen zu programmieren und ich habe, für mich, folgendes festgestellt:
Das Prinzip ist einfach, der Aufwand ist enorm, das Ergebnis rechtfertigt den Aufwand.

Vielleicht solltest Du Dir die Druckprozedur auch selbst schreiben.

Viele Grüße
Carsten

#4

Moin, Carsten,

dann schreibe ich mir die Prozedur dafür komplett selbst

also tatsächlich wie in der Steinzeit - Platzbedarf ausrechnen, Zeilen zählen, Blattvorschub mit xx Leerzeilen? Wie schaut’s dann mit den verschiedenen Gerätetypen aus? Auf dem Nadeldrucker passten keineswegs immer 72 Zeilen auf ein Blatt :smile:))

Gruß Ralf

#5

Hallo Ralf,

also tatsächlich wie in der Steinzeit - Platzbedarf
ausrechnen, Zeilen zählen, Blattvorschub mit xx Leerzeilen?
Wie schaut’s dann mit den verschiedenen Gerätetypen aus? Auf
dem Nadeldrucker passten keineswegs immer 72 Zeilen auf ein
Blatt :smile:))

nur als Beispiel: ich drucke Etiketten in der Art …
http://www.layoutwriter.de/img/vda.png
… mit VB6. Daß man da keine Zeilen zählt, leuchtet ein? ScaleMode = VBMillimeters :smile:

Gruß, Rainer

#6

Moin, Rainer,

… mit VB6. Daß man da keine Zeilen zählt, leuchtet ein?

erstmal arbeite ich mit VBA, genauer gesagt mit Access, das größere Problem ist aber, dass ich kein Objekt namens Report oder Bericht habe. Zumindest fehlt mir jede Idee, wie ich mein zusammengerechnetes Zeug, das ja nirgends als Abfrage oder Tabelle gespeichert ist, in einem Report unterkriege.

Gruß Ralf

#7

Hallo Ralf,

… mit VB6. Daß man da keine Zeilen zählt, leuchtet ein?

erstmal arbeite ich mit VBA, genauer gesagt mit Access, das
größere Problem ist aber, dass ich kein Objekt namens Report
oder Bericht habe. Zumindest fehlt mir jede Idee, wie ich mein
zusammengerechnetes Zeug, das ja nirgends als Abfrage oder
Tabelle gespeichert ist, in einem Report unterkriege.

wie ich mit Access zu einem Report komme weiß ich, wie der dann auf’s Papier kommt auch. Das hat aber mit Programmieren nichts zu tun. Wie das mit VBA geht, habe ich keine Ahnung. Mein Kommentar hat sich nur auf ‚Zeilen zählen‘ bezogen.

Grundsätzlich kann man das mit VBA ähnlich wie mit VB6 erledigen, aber die Sysntax ist völlig verschieden, deshalb kann ich Dir leider nicht helfen.

Gruß, Rainer

#8

Hallo Ralf,

wenn du schon so ein Gefummel machen willst, dann uwerde ich an deiner Stelle mir ein DC-Handle ueber die API erzeugen und auf diesen Context meine Druclelemente plazieren (mittels TextOutExm DrawLineEx etc). Allerdings musst du beachten, das die Zeit des Zeilezaehlens seit Win3.1 eigentlich vorbei ist, denn die Printer-DCs bei Windows Seitenorientiert.

In der MSDN findest du einige Beispiele wie man ein PrinterDC ereugt und verwendet.

Tschau
Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#10

Hallo Ralf,

na ja so schlimm is es auch nicht witklich.

Als ein DC ist ein DeviceContext, der je nach Ausgabegeraert = Device(z.B. Drucker, Bildschirm etc.) gewisse Eigenschaften und Paramertisierung hat.

Solch einen DC holt man sich mittels
Declare Function CreateDC Lib „gdi32“ Alias „CreateDCA“ (ByVal lpDriverName As String, ByVal lpDeviceName As String, ByVal lpOutput As String, lpInitData As DEVMODE) As Long

Dazu sollte aber einiges in der MSDN vorhanden sein. Allerdings habe ich mir solch ein Fummelei bisher noch nicht angetan, den Ausdrucke sind halt die Staerke von Access und warum das Rad neu erfinden.
Mit 16Bit C++ und MFC koennte ich dienen, da habe ich sowas haeufiger gemacht.

Besorge dir mal das Programm API-Guide, das hilft da auch schon weiter.

Anosnsten wenn du schon sowas machen musst, dann verpacke die Druckroutine doch einfach in eine C/C++ DLL und uebergib ihr den Namen der MDB-Datei, dann ist das API-Handling etwas einfacher, den die MFC bietet einige vordefinierte Klassen fuer das Druckhandling.

Tschau
Peter

1 Like
#11

Moin, Peter,

na ja so schlimm is es auch nicht witklich.

ha!

warum das Rad neu erfinden.

meine Leidenschaft ist das auch nicht. In diesem Fall geht es darum, redundante Speicherung unbedingt zu vermeiden, weil nachträgliche Änderungen der Grunddaten (im einfachsten Fall Korrekturen von Erfassungsfehlern) damit unmöglich gemacht würden.

Besorge dir mal das Programm API-Guide, das hilft da auch
schon weiter.

Das habe ich schon, sogar schon verwendet, um den FileDialog (in Access2000 nicht verfügbar) nachzubilden. Aber: Selbst wenn mir die Function namens CreateDC zufällig begegnet wäre, hätte ich wohl nicht erkannt, wozu die gut ist.

verpacke die Druckroutine doch einfach in eine C/C++ DLL

Na ja - C++ lernen als Hobby? Da hebe ich mir wohl nen Bruch, ich hab schon an VBA und API zu beißen :smile: Aber wer weiß, vielleicht packt mich der Ehrgeiz doch noch.

Gruß Ralf