Ab zweitem Drucken unter Win11 friert Anwendung ein

[elmut19]

@Quiche-Lorraine
Folgende Methoden habe ich noch auf dem Device Context gefunden.

m_pDC->SelectObject(&cPenNormal);
m_pDC->SetTextColor(..);
m_pDC->FillRect(..);
m_pDC->DrawText(..);
..MoveTo, ..LineTo, ..EndPage(), ..IsPrinting()

Also ein "CBrush" oder "CPen", "CFont" kommt über ein "SelectObject(..)" rein.
Sonst habe ich nichts gefunden. Und die funktionieren schon lange so.
Das mit dem Application Verifier muss ich dann noch anschieben.

[Quiche Lorraine]

@elmut19 sagte in Ab zweitem Drucken unter Win11 friert Anwendung ein:

Und die funktionieren schon lange so.

Ja das ist halt das Wesen von undefiniertem Verhalten. Es funktioniert halt solange eine Bedingung erfüllt ist.

Frage: Achtest du auf den Rückgabewert von SelectObject()?

[elmut19]

@Quiche-Lorraine
Nein! Also manchmal wird die Rückgabe einem Old-Obj zugewiesen.
Aber oft ohne Zuweisung.
Beim Überfliegen habe ich gerade nicht drauf geachtet, ob es sich dabei um den DC des Druckers handelt.
Aber der ist sicher auch betroffen.

... "An application should always replace a new object with the original, default object after it has finished drawing with the new object."

Es könnte also sein, dass das ursprüngliche Object nicht wieder zurückgeschrieben wird.

Aber es heisst auch, dass diese Objekte dann über eine "OnIdle(..)"-Fktn, über das System verwaltet werden.

Aber ich finde auch, z.B. in meiner "DrawLine(..)" ein "ding.DeleteObject();"
... Also insgesamt viele solcher "xxx.DeleteObject()".
Das für den Print-Vorgang nachzuverfolgen dauert natürlich einige Zeit.

[Quiche Lorraine]

@elmut19 sagte in Ab zweitem Drucken unter Win11 friert Anwendung ein:

Nein! Also manchmal wird die Rückgabe einem Old-Obj zugewiesen.

Dann probiere doch mal folgendes. Jedes SelectObject liefert das zuvor selektierte Objekt zurück. Also würde ich den Device Context so wiederherstellen, wie ich ihn vorfand.

// Sorry WinAPI Code 
PrevSelectedBitmap = SelectObject(dcTrans, MyBitmap);
// 
// Do stuff...
// 
SelectObject(dcTrans, PrevSelectedBitmap);

https://devblogs.microsoft.com/oldnewthing/20130306-00/?p=5043

[elmut19]

@Quiche-Lorraine
Bin mal einen Druck-Vorgang durchgegangen.
Am Anfang wird ein Object, aber lokal in der Methode, gesichert.
Die Sicherung erfolgt auf Pen und Font Objekte.
Danach werden dies Objekte zig mal getauscht, ohne das vorherige in ein "Old" zu sichern.
Im Abschluss werden erzeugte Objekte durch "DeleteObject()" auch wieder gelöscht.
Zwischedurch wird auch wieder ein "OldFont" zurückgeschrieben.

Im Grossen Ganzen sollte das eigentlich nicht so schlecht sein.
Visuell aber schwer zu 100% einzuschätzen.

[elmut19]

@elmut19
Inzwischen sehe ich den "neuen" Druck-Dialog von Win11als Bug von Microsoft an.
Es ist nirgends eine Programmiervorschrift für das Din zu finden.
Das Einzige, was es gibt, ist ein Registry Patch, der den alten Druck-Dialog wieder einschaltet.
https://answers.microsoft.com/de-de/windows/forum/all/windows-11-modernen-drucken-dialog-ohne-maus/729b38f0-536b-4a06-b014-950f83ccd557

[Quiche Lorraine]

@elmut19 sagte in Ab zweitem Drucken unter Win11 friert Anwendung ein:

Inzwischen sehe ich den "neuen" Druck-Dialog von Win11als Bug von Microsoft an.

Hast du dir schon das Problem auf Win11 unter dem Debugger angeschaut?

[elmut19]

@Quiche-Lorraine
Ich werd erstmal einen Testrechner mit Win11 beantragen.
Der Rechner, auf dem wir das kurz probiert haben, ist leider nicht meiner.
Das ist mir da doch zu umständlich.
Aber jedenfalls vielen Dank für Deine Hinweise.
... Und ich werd noch weitersuchen ...

[Tyrdal]

@elmut19 Warum nicht einfach ne VM nutzen?

[elmut19]

@Tyrdal
Danke Tyrdal.
Werd ich jedanfalls auch beantragen.
Hab ich nicht dran gedacht, da ich eh unbedingt noch ein Notebook fürs Homeoffice möchte.
Mal sehn, was Lizenztechnisch besser ist.
Bisher kann ich nur sehen, dass auf dem "normalen" Druckweg meine Objekte, so wie ich es bei Microsoft nachlesen kann, auch wieder abgebaut werden.
Vorerst bleibt leider die einzige Möglichkeit, den Registry Patch anzuwenden.
Programmiertechnisch wird es da keine Möglichkeit geben, da der neue Druck-Dialog ja neuer ist, als meine Programmierumgebung (und deren Doku).

[elmut19]

Erstmal Danke für Eure Antworten.

Ich wollte hier noch den aktuellen Stand mitteilen.
Inzwischen habe ich einen Link gefunden, der wohl eine Lösung beschreibt,
die für jemand anderen funktioniert hat: (vom 05. Okt. 23)
https://learn.microsoft.com/en-us/answers/questions/1319494/new-print-dialog-box-just-let-me-print-once-(c-)

Aber leider bin ich aus Gründen, die mir unverständlich sind, nicht in der Lage, das selbst zu testen.

[Martin Richter]

Hast Du die Antwort gelesen, die akzeptiert/markiert wurde:

You have to call OleInitialize(NULL)
at the beginning of WinMain().
Link the program with ole32.lib.
Now PrintDlg and PrintDlgEx work OK.

[elmut19]

@Martin-Richter
Ja, klar hab ich die gelesen!
Ich habe diese Zeile auch in meinen Quellcode eingebaut.
Dass ich selbst nicht testen kann, hat andere Gründe,
die mir inzwischen einfach nur wurscht sind.
Die kann man im Forum auch nicht lösen, leider.

Aber glücklich wäre ich, wenn z.B. jemand erklären könnte,
was es mit diesem Statement auf sich hat.

[Martin Richter]

@elmut19 sagte in Ab zweitem Drucken unter Win11 friert Anwendung ein:

Aber glücklich wäre ich, wenn z.B. jemand erklären könnte,
was es mit diesem Statement auf sich hat.

Also das würde das lesen der Doku auch tun? Oder?

OleIntialize ist die CoInitialize die Methode um COM in Deinem Programm verfügbar zu machen.
Nur wenn Du eine der beiden Funktionen aufrufst ist es möglich COM-Objekte korrekt in Deiner Anwendnung zu nutzen.

Die Windows Common Dialogs sind schon länger keine reinen Windows API Module mehr. Die benutzen auch COM. Und das steht sogar in der Doku...

[elmut19]

@Martin-Richter
Ich danke Dir, Martin.
Das Problem ist ja, dass bisher (Win10 und frühere) alles funktioniert hat.
Und dann so ein Fehler. Da komme ich zumindest leider nicht auf so eine Idee.
Leider würde ich das aus dem lesen der Doku wohl auch nicht alleine rausfinden.

Also nochmals Danke für den Hinweis.

[Martin Richter]

Ich kann Dir dennoch nicht sagen, ob das die wirkliche Ursache ist. Könnte es mir aber sehr wohl vorstellen.
Es war halt in dem Thread als Antwort markiert.

Günstig wäre in so einem Fall auch ein Dump des Zielsystems. Dan könntest Du selbst ermitteln wo er stehen bleibt.

[elmut19]

@Martin-Richter
So, jetzt habe ich endlich mal ein Win11.
Wir haben es auch unter zwei verschiedenen Builds (xx.2361 und xx.2428) getestet.
Bei beiden konnten wir das Fehlerverhalten, sowie die Korrektur feststellen.
Scheint also grundsätzlich bei Win11 so zu sein.

Ich habe das "OleInizialize(NULL)" anm Anfang der "InitInstance()" reingesetzt.

Weiterhin verhält es sich im Fehlerfall auch so, dass man in einer Schleife problemlos
viele einzelne Dokumente drucken kann.
Das hat auch nur den einmaligen Aufruf des Druckdialogs erfordert.
Erst wenn der Druckdialog ein weiteres Mal aufgerufen wurde, hing das Programm.

Also das "OleInitialize(NULL)" hat geholfen!
Danke nochmals an Alle.