# Visual C++ - Drucken aus dialogbasierenden Anwendung



## Matrim (8. September 2003)

Hallo,

ich habe folgendes Problem und trotz einige Recherche im Netz hab ich es noch nicht lösen können.

Ich programmiere mi dem MS Visual C++ Windows halt und habe schon eine dialogbasierende Anwendung fertig gestellt zu deren Glück nur noch das Drucken verschiedener Daten fehlt.

Ich hab davon leider einfach mal gar keine Ahnung, stelle mir das aber im Endeffekt so vor:
Den Knopf, zum Drucken hab ich quasi schon.
Dort sollen gewisse Vorberechnungen stattfinden, aus deren Ergebnis dann das Drucken hervorgeht. 

Ich definiere mit einen Header/Footer, ebenso wie einer 1. und letzte Seite und halt die "normalen" Seiten.
Diese kann ich jeweils individuell designen.
Was meine ich damit? Eigentlich ganz einfach, dass ich Text (erstmal) genau dort auf die Seite hindrucken kann, wie ich das will.

Genauer geht es mir darum aus einem Listcontrol ein Teil der Daten herauszudrucken, in meiner eigenen Optik und mit ein wenig Zeug halt dazu...

Über Hilfe wäre ich wirklich dankbar.

Mat.

ps Soetwas wie das Bedrucken einer Seite mit Text wäre mir erstmal ausreichen, dass ich die Seite, quasi bedrucke/mal und sie dann halt an den Drucker zum ausdruchen abschicke...
Das ich quasi alles allein formatiere.


----------



## x_Red_Eagle_x (8. September 2003)

ich hoffe dass hier hilf dir
mehr hab ich mit druckern nicht gemacht


```
CPrintDialog dlg(FALSE);         // Objekt für Dialog konstruieren
  if (dlg.DoModal()==IDOK)         // Dialog modal aufrufen
  {                                // abfragen ob mit "OK" verlassen
    CDC dc;                        // "leeren" CDC konstruieren
    dc.Attach(dlg.GetPrinterDC()); // DC für den gewählten Drucker zuweisen

    DOCINFO di;                    // Die folgende Struktur beschreibt das
    di.cbSize=sizeof(DOCINFO);     // zu druckende Dokument. In diesem
    di.lpszDocName="Testdokument"; // Beispiel wird nur der Name des
    di.lpszOutput=NULL;            // Dokuments ausgefüllt.
    di.lpszDatatype=NULL;
    di.fwType=0;

    dc.StartDoc(&di);              // StartDoc muß vor dem Ausdruck eines
                                   // Dokuments aufgerufen werden
    dc.StartPage();                // StartPage muß vor dem Ausdruck
                                   // jeder Seite aufgerufen werden
    dc.Ellipse(0,0,400,300);       // Ausgabe der Grafik: Üblicherweise
                                   // wird hier eine Methode aufgerufen,
                                   // der der DC übergeben wird, um die
                                   // selbe Methode zur Ausgabe am Bild-
                                   // schirm und am Drucker verwenden
                                   // zu können
    int erg =dc.EndPage();         // EndPage muß nach dem Ausdruck
                                   // jeder Seite aufgerufen werden
    if (erg>=0)                    // EndDoc muß nach dem Ausdruck eines
      dc.EndDoc();                 // Dokuments aufgerufen werden
    else                           // jedoch nur dann, wenn keine Fehler-
      dc.AbortDoc();               // meldungen von EndPage geliefert
                                   // wurden. Sonst muß das Drucken sofort
                                   // mittels AbortDoc abgebrochen werden!
    dc.Detach();                   // DC aus Objekt entfernen
  }
```


----------



## Matrim (9. September 2003)

Hey danke,

das bringt mich schon mal einen großen Schritt voran =)


----------



## chibisuke (10. September 2003)

und schon wieder MFC... die kann ich einfach net leiden....

laut winapi musst du mit CreateDC einen gerätekontext für den printer erstellen
und dann kannste mit den GDI funktionen rein zeichen...sobal du DeleteDC sagt fängt er an zu drucken..

HDC hDc = CreateDC("WINSPOOL", "Epson FX-80", NULL,  NULL);
// hier zeichnen
DeleteDC(hDc);


----------



## Matrim (11. September 2003)

*HDC vs DCD*

Ich hab es nun mit DCD gemacht, und kann nun drucken \o/.

Sicher geht es auch mit HDC, aber bin eigentlich mit DCD glücklich.
Wo genau liegen eigentlich die Unterschiede und welche wäre besser zu benutzen? 

Soweit wie ich das sehe, erlaubt DCD ebenfalls Zeichenoptionen, wie das GDI, somit bleibe ich wohl sicher erstmal beim dem mir mehr vertrauten.


ps Warum ist MFC nicht gut? Man kann doch bequem eine Menge mit machen, solange man halt weiss wie.


----------



## chibisuke (11. September 2003)

nun der hauptunterschied ist, das die MFC bibliotheken zwangsläufig 1.) langsamer sind als die API funktionen, das sind schließlich nur wraper für die API funktionen...
2.) MFC apps sind nich portabel, können nur auf dem compiler kompiliert werden für den die geschrieben sind...
3.) schonmal nen user gesehen der alle MFC DLLs mal eben so auf der platte hatt (ich meine nicht coder)? nein? ich auch net, zwangsläufig musst du die mitliefern...
4.) einiges mehr schreibarbeit... bis du z.B. für n fenster die klassen und handler alle registriert hast, haste im winapi dein progy schon fast fertig...
natürlich is alles klasse was MFC betrifft... auf den ersten blick, auf den zweiten blick allerdings stellt man fest das das MFC eigendlich gar net so toll is wie es aussieht.... 

faszit.. lern das API das is um einiges besser, auch wenn die MSDN net viel über das winapi hergibt, und für allem mfc empfieht...

auch der umgang mit DLLs und so weiter... eine MFC-Dll kann nur von MFC progys benutzt werden... eine API-Dll kann von allen anwendungen benutzt werden, egal ob MFC oder API... und so weiter...

hast du ne ahnung was du anstellen musst damit du auf dem desktop rumzeichnen kannst in MFC? nein? nun doch einiges... weil du dir zuerstmal das desktop objekt besorgen musst...
im winapi... CreateDC("SCREEN", NULL, NULL, NULL,); oder so ähnlich...

naja aber musste selbst wissen ob du dir dieses MFC unbedingt antun willst, ober ob du gleich ordendlich arbeitest...;-)


----------



## Matrim (14. September 2003)

Ist okay, ich glaub dir gern =)

Das gute ist, dass die Funktionen quasi genauso heißen und das Gleiche machen, dass ich es dann (ggfs) 1:1 übertragen kann.

Im Moment bin ich noch ganz glücklich, werd es aber dann mal auf deinem Weg probieren, dann hab ich auch den genauen Performancevergleich.


----------



## Vaethischist (19. September 2003)

> _Original geschrieben von chibisuke _
> *nun der hauptunterschied ist, das die MFC bibliotheken zwangsläufig 1.) langsamer sind als die API funktionen, das sind schließlich nur wraper für die API funktionen...
> 2.) MFC apps sind nich portabel, können nur auf dem compiler kompiliert werden für den die geschrieben sind...
> 3.) schonmal nen user gesehen der alle MFC DLLs mal eben so auf der platte hatt (ich meine nicht coder)? nein? ich auch net, zwangsläufig musst du die mitliefern...
> ...




Deine Aussagen klingen sehr nach geschmacksoriertierter Argumentation. Wenn Du die MFC nicht leiden kannst, dann schreib es auch hin. Verschone uns aber bitte mit mehr oder weniger falschen, persönlichen Geschmack betreffenden oder von Mangel an Wissen und Einarbeitung geprägten Argumenten. 

P.S.: Wenn Du gerne genauere Aussagen zu Deinem Posting willst, laß ich mich gern zu einem f'up hinreißen...


----------



## chibisuke (19. September 2003)

nun ich kann dir jede aussage in dem posing begründen.. 

1.) langsamer... 2x stack mehr bei einem funktionsausruf is zwangsläufig langsamer... wenn du zeitkritische aufgaben hast fällt das ins gewicht (hab es selbst erlebt) bei games beispielsweise sind das bis zu 3FPS die du durch MFC wraper aufrufe einbüßt...

2.) klassen aus dateien laden is immer ganz nett... weil du eine MFC klasse ganz einfach nicht aus einer datei laden kannst, du kannst die DLL maximal ein objekt davon erstellen lassn... damit is klar das ich beispielsweise keine MFC klassen in DLLs auslagern kann ohne das ich lange und breit mit funktionen für das erstellen und zerstören von objekten rum bastle...und alloca varianten von klassen sind damit so und so unmöglich.....

im gegensatz zu klassischen DLLs die im normalfall entweder eine COM schnittstelle haben oder nur funktionen enthalten...

3.) hab es selbst erlebt das ich erst megabyte weise MFC DLLs mit zu meinen progys kopieren musste um die erstmal lauffähig zu bringen auf anderen rechner.... eigendlich der hauptgrund wiso ich aufgehöhrt hab mit MFC zu arbeiten...

4.) nun ob ich nun erstmal eine klasse von CWnd ableite... oder ähnliches, mit dem klassenassistent oder auch von hand alle meine funktionshandler registriert hab, und bis ich dann endlich soweit bin das ich eine instanz erstellen kann... das dauert... beim winAPI erstell ich ne struktur die die basis für mein fenster herstellt... eine struktur die im bestn fall mit 3 zeilen abgehandelt is... und dann noch meine windowProc und fertig......... noch krasser is es bei dialogen... die MFC programmierer gehen her... erstellen ihre dialog klasse und so weiter.. ich schreib meine fenster prozedur und sag CreateDialog... 


und nun frag ich dich... gegenüberstellung API - MFC...

Wer is schneller? (3FPS is ne ganz schöne menge)
Wer hatt weniger probleme mit DLLs des anderen systems? 
Wer kann auf fremd dlls verzichten die windows nich hatt?
wer spart mehr schreibarbeit und zeit?

und wenns dich beruhigt... hab ich noch einen 5. grund wo ich schon dabei bin....

hast du schonmal member funktionen von MFC klassen in inline asm aufgerufen? also ich net... weil es einfach nich geht...
die API funktionen hingegen sind sehr leicht aus assembler heraus aufzurufen...

achja und der 6. grund follgt auch noch.... PORTABILITÄT...

schonmal ein MFC progy auf GCC kompiliert? oder gar auf LCC? sicher nich.. weil es einfach nich geht, nichmal wenn u mingw32 dabei hast.

so und jetzt mach ich nen punkt weil sonst tipp ich morgen noch...

faszit.. ich könnte MFC durchaus leiden... jedoch die oben genannten gründe sprechen dagegen das ich es einsetze, und ich rate auch aufgrund der eben genannten gründe prinzipell davon ab die MFC einzusetzen...

irgendwelche argumente die jahrelange erfahrung wiederlegen? Wohl kaum,,,


----------



## Vaethischist (21. September 2003)

chibisuke hat gesagt.:
			
		

> nun ich kann dir jede aussage in dem posing begründen..
> 
> [snip]
> 
> irgendwelche argumente die jahrelange erfahrung wiederlegen? Wohl kaum,,,



Ja...hab ich!

1.) Das Objektorientierung nicht gerade der Performancekracher ist, das wissen wir alle. Nur ging es dem ursprünglichen Fragesteller um das *Drucken* und ich weiß jetzt nicht, was das mit Performance und 3 fps mehr oder weniger zu tun haben soll. Ansonsten sind die Wrapper-Klassen in ihrer Verwendung logischerweise langsamer, aber wenn man keine hochkritischen Anwendungen schreibt, dann ist der Leistungsverlust locker zu ertragen, betrachtet man die Vorzüge der Wrapper. Schreibt man zeitkritische Anwendungen, wird man ohnehin kaum auf Framworks wie die MFC zurückgreifen, von daher kann ich mit dem Performanceargument hier nichts anfangen (auch wenn die Aussage an sich richtig ist).

2.) Erstens war davon in Deinem ursprünglichen Posting nichts zu sehen, zweitens drückst Du Dich etwas unklar aus. Was ist jetzt das Problem? Serialisierung/Persistenz? Das ist kein Laden von Klassen aus Dateien, womit das schon  mal ausfällt. Klassen in DLL's unterbringen? Also das funktioniert ohne die von Dir dargestellten Probleme... 

3.) Statische Bindung der MFC-Bibliotheken...
Mal davon ab: Erklär mir mal welches Framework ohne Bibliotheken auskommt, die nachher auf dem Zielsystem vorhanden sein müssen...

4.) Im Wettbewerb "Wir erstellen einen Texteditor" liege ich mit ca. 10 Sekunden (inklusive Kompilierung) mit der MFC (+Wizard) ganz weit vorn (und das ist noch ein schlechtes Beispiel). Außerdem kann ich an der "Klasse für Dialog erstellen - Implementieren"-Taktik nichts seltsames erkennen. Ein Dialog ist nunmal ein "Modul", wenn man so will, also warum soll er nicht seine eigene Klasse bekommen.

Generell sehe ich keinen Grund API und MFC gegenüberzustellen. Beide haben Vor- und Nachteile. Mein Problem mit Deinem Posting bezog sich auf offensichtliche Unwahrheiten und Geschmacksangelegenheiten:

Wieso spare ich Schreibarbeit bei der API? Codegenerierung...schon mal gehört?)

MFC-Apps sind nicht kompatibel mit anderen Compilern...und? Wo liegt da das Problem. Als Windows-Anwendungsprogrammier wird man i.d.R. ohnehin mit den MS-Entwicklungsumgebungen arbeiten (ohne die jetzt besonderes loben zu wollen), von daher sehe ich Kompatibilität hier nicht als vordergründiges Problem (zumal die Inkompatibilität bis auf die Code-Ebene reicht).

Das "Wer hat die DLL"-Problem ist faktisch nicht existent, wenn man gescheite Setups bzw. statische Bindung her nimmt.

Genug...wir wissen beide, was API und MFC sind. Wissen um ihre Vor-/Nachteile und damit ist es auch gut. Erstens interessiert das hier sowieso keinen und zweitens habe ich keine große Lust auf Glaubenskriege...

P.S.:



			
				chibisuke hat gesagt.:
			
		

> nun ich kann dir jede aussage in dem POSING begründen..



Ich denke das ist ein sehr passender Schreibfehler...


----------



## chibisuke (21. September 2003)

Na? und was machste wenn ich dir deine viel gelobte VC++ IDE weg nehm und dir nur n prozessor pack hin stelle, wie wirs beispielsweise in der schule haben?
klasse, dann kannste nichmal ne MFC app schreiben weil du ständig mit wizards gearbeitet hast und nichmal weißt was das teil eigendlich intern macht....

Nun den wettbewerb können wir gerne machen... jeder hatt einen komandline compiler und einen standart texteditor seiner wahl zur verfügung, was nicht zur verfügung steht sind editoren die syntax hervorhebung benutzen, die assistenten für automatische code generation bieten, genauso wie referenzen zum thema.. na viel spaß.. mein code dafür is etwa eine bildschirmseite groß... deiner wird vermutlich faktor 2 bis faktor 3 ausfallen, zumal du alle handler und so weiter in der klasse registrieren musst... die zeit richtet sich entsprechend dannach..


Aber der einzige wirkliche grund wiso alles mit MFC arbeitet, ist weil die leute das API meist gar net beherschen... in büchern wie "VC++ in 21 Tagen" oder ähnlichen is nur MFC beschrieben, den viele dann sogar einfach nur abtippen und ihn nich verstehen.... ich frag mich nur, wiso sollte man MFC benutzen?

ich meine jetzt geh ich mal davon aus das ich nicht nur in C++ programmier, sondern vieleicht mal für irgendein opensource projekt auf C angewiesen bin... ich geh davon aus das ich vieleicht nicht nur C# sondern auch mal Delphi, Pascal, oder ähnliches programmieren muss... nun und da gibts bekanntlich kein MFC....

also ich für meinen teil seh eigendlich keine vorteile gegenüber dem API die nicht durch irgendwelche nachteile gleich mehrfach ausgeglichen werden..........

Lassen wir das, es bringt im endeffekt doch überhaupt nix.. jeder hatt seine meinung die er vertritt, und die wird sich auch durch eine solche diskusion nicht ändern


----------



## Vaethischist (21. September 2003)

> _Original geschrieben von chibisuke _
> *Na? und was machste wenn ich dir deine viel gelobte VC++ IDE weg nehm und dir nur n prozessor pack hin stelle, wie wirs beispielsweise in der schule haben?
> *



Erstens hab ich die IDE weder gelobt, noch ist diese Annahme realistisch, wenn man in einem produktiven Prozeß involviert ist (Job, Uni, ...). Auf Arbeit schließt Dich auch keiner im dunklen Kämmerlein ein und verlangt von Dir mit dem Taschenrechner die Jahresbilanz des internationalen Multikonzerns Deiner Wahl zu berechnen... 



> _Original geschrieben von chibisuke _
> *
> klasse, dann kannste nichmal ne MFC app schreiben weil du ständig mit wizards gearbeitet hast und nichmal weißt was das teil eigendlich intern macht....
> *



Ich bin Dipl.-Inf. und weiß ziemlich genau, was da unter der Decke abläuft. Allerdings ist das vollkommen irrelevant, solange es um die Nutzung des Frameworks (der Wrapperklassen) geht. Die Vereinfachungen der Nutzung einer API durch das Einführen von Wrappern wird seit Jahren überall praktiziert und wahrscheinlich nicht, weil sie alle doof finden...



> _Original geschrieben von chibisuke _
> *
> Nun den wettbewerb können wir gerne machen... jeder hatt einen komandline compiler und einen standart texteditor seiner wahl zur verfügung, was nicht zur verfügung steht sind editoren die syntax hervorhebung benutzen, die assistenten für automatische code generation bieten, genauso wie referenzen zum thema.. na viel spaß.. mein code dafür is etwa eine bildschirmseite groß... deiner wird vermutlich faktor 2 bis faktor 3 ausfallen, zumal du alle handler und so weiter in der klasse registrieren musst... die zeit richtet sich entsprechend dannach..
> *



Du gehörst also scheinbar auch zu denen, die der Meinung sind "Hardcore-Coder" nutzen keine IDE, das machen nur Idioten und Newbies, die nix können. Ich weiß nicht warum Du das glaubst (so es denn so ist), nur frage ich mich intensiv warum ich die offensichtlichen Vorteile von Objektorientierung, Codegenerierung,  Syntaxhighlighting, etc. nicht nutzen sollte. Wenn Du ein gutes Argument dafür hast, ich höre Dir gerne zu...aber bitte SINNVOLLE.



> _Original geschrieben von chibisuke _
> *
> Aber der einzige wirkliche grund wiso alles mit MFC arbeitet, ist weil die leute das API meist gar net beherschen... in büchern wie "VC++ in 21 Tagen" oder ähnlichen is nur MFC beschrieben, den viele dann sogar einfach nur abtippen und ihn nich verstehen.... ich frag mich nur, wiso sollte man MFC benutzen?
> *



Du redest hier von Leuten, die wahrscheinlich nicht mal den Unterschied zwischen API und MFC begriffen haben. Warum führst Du die in einer Argumentation zum  MFC-API-Vergleich an? Versteh ich net...und...siehe letzter Satz (von mir in diesem Posting)...



> _Original geschrieben von chibisuke _
> *
> 
> ich meine jetzt geh ich mal davon aus das ich nicht nur in C++ programmier, sondern vieleicht mal für irgendein opensource projekt auf C angewiesen bin... ich geh davon aus das ich vieleicht nicht nur C# sondern auch mal Delphi, Pascal, oder ähnliches programmieren muss... nun und da gibts bekanntlich kein MFC....
> *



Erster Punkt an Dich. Nur gilt, wie bei fast allen Sachen das Programmieren betreffend: "Kannste eins, kannste alles!"

Die Vorteil/Nachteildiskussion halte ich in sofern für sinnlos, weil Du immer noch mit (mir) unverständlichen, falschen, nicht unbedingt von "jahrelanger Erfahrung" zeugenden Argumenten daher kommst. Ansonsten hätte ich da oben vielleicht was von "viele Fehler in der MFC-Implementierung" oder ähnlichen, tatsächlichen Nachteilen der MFC gelesen. Das was Du schreibst, kann ich da leider nicht gelten lassen, obwohl ich durchaus bereit bin zu akzeptieren, das weder MFC noch API noch irgendwas anderes die perfekte Lösung sind, aber wenn Diskussion, dann bitte mit sachlichen Argumenten und nicht ausgedachten oder dahergeträumten Szenarios. Womit wir wieder bei der Motivation für mein erstes Posting in diesem Thread wären...und siehe, es änderte sich nichts...


----------



## chibisuke (22. September 2003)

Doch auch ich benutz ne IDE.. aber es gibt durchaus situationen wo man entweder nicht die möglichkeiten hatt eine zu nutzen, oder es ganz einfach sinnvoller ist ohne zu arbeiten...

kleine beispiel... du bist bei einem bekannten, der hatt null ahnung von alle dem, du schreibst ihm schnell n kleines progy... kompiler gibts im internet zum säue füttern, aber IDE wirste ne wirklich gute im internet nur schwer finden...

das is ein fall wie er mir durchaus ab und zu begegnet

außerdem.. wartest du gerne ne halbe stunde bis was kompilert is wenn du es in 10 minuten haben kannst? (n bischen übertrieben).. weil wenn du die windows bibliotheken ordendlich einbindest und nur das was du brauchst.. dann kompiliert es im gegensatz zu MFC um einiges schneller, wo du ja nur deine stdafx.h hast..


----------



## Vaethischist (22. September 2003)

Du konstruierst laufend ungünstige Szenarios und begründest damit Deine Ansichten. Also mal ehrlich: Wann gehst Du zu einem Freund und "codest mal eben was"? Und selbst wenn, Eventualitäten und ausgedachte Problemfälle kann ich Dir für JEDES BELIEBIGE Szenario angeben und damit scheinbar schlüssige Argumentationen widerlegen. Das hilft nur nichts, weil es einfach vollkommen unsachlich ist...


----------



## chibisuke (23. September 2003)

was is daran unsachlich, ich hab laufend situationen wo ich keine IDE verfügbar hab...

du etwa noch nie ohne IDE gearbeitet? kann ich fast net glauben...

nun mir persönlich bringt MFC gar nix.. weil die paar mal wo ich es leicht einsetzen kann, die sind so selten tja... entsprechend hab ich aufgehöhrt es zu benutzen... so und nun lassen wir das thema, sonst wird das noch ein ganzer roman hier..


----------



## Vaethischist (23. September 2003)

> _Original geschrieben von chibisuke _
> *
> nun mir persönlich bringt MFC gar nix.. *



Aha...jetzt sind wir endlich soweit... Dir *persönlich* bringt sie nichts, aber dann verwechsel Deine persönlichen Ansichten bitte nicht mit überzeugenden Argumenten...

[EOD]


----------

