Visual C++ - Drucken aus dialogbasierenden Anwendung

M

Matrim

Grünschnabel
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.
 
Zuletzt bearbeitet:
ich hoffe dass hier hilf dir
mehr hab ich mit druckern nicht gemacht

Code: 
  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
  }
 
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);
 
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? o_O

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.
 
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...;-)
 
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.
 
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...
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...;-)
Zum Vergrößern anklicken....


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...
 
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,,,
 
chibisuke hat gesagt.:
nun ich kann dir jede aussage in dem posing begründen..

[snip]

irgendwelche argumente die jahrelange erfahrung wiederlegen? Wohl kaum,,,
Zum Vergrößern anklicken....

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..
Zum Vergrößern anklicken....

Ich denke das ist ein sehr passender Schreibfehler... :-) :-) :-)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück