Ab zweitem Drucken unter Win11 friert Anwendung ein
-
@Th69 Hallo Th69
ich hab das so irgendwo gesehen und einfach ergänzt.
Mein Eindruck ist, dass Microsoft selbst nicht weiss, was zu tun ist.
.. oder es eben nicht sagt.
-
@DocShoe Hallo DocShoe
Ich weiss es leider nicht!
Ich arbeite unter Win10!
Und das passiert unter Win11! Da hab ich keine Entwicklungsumgebung.
Aber wie schon gesagt, es versucht den Dialog wieder zu öffnen, bleibt aber da auf (halbem Weg?) stehen.
Also nachdem man schon mal erfolgreich gedruckt hat.
Erst wenn das Programm gekillt wird, geht der Dialog auf. Davor ist es eingefroren.
Aber Drucken ist dann natürlich auch nichts mehr.
-
@elmut19 sagte in Ab zweitem Drucken unter Win11 friert Anwendung ein:
Und das passiert unter Win11!
Hast du denn keinen Win11 Rechner zur Hand?
Sofern Remote Debugging für dich nicht in Frage kommt, würde ich mal die Debug Fassung kompilieren, auf dem Win11 Rechner laufen lassen, beim Absturz einen Crash Dump machen, und diesen dann mittels WinDbg debuggen.
-
@Quiche-Lorraine
Hallo Quiche-Lorraine,inzwischen haben wir ein Notebook mit Win11 da, noch ohne VStudio.
Hab das Remote-Debugging bisher nur auf einem Win6 Panel machen müssen. Aber werd mal gucken, was einfacher ist.Vermutung wäre (gemäss Verhalten), dass es beim "DoModal()" des Druck-Dialogs hängen bleibt.
Aber wie ist das mit der 32Bit-Emulation auf dem neuen Windows?
Könnte darin der Grund liegen?Ich habe z.B. folgenden Beitrag gefunden:
https://learn.microsoft.com/en-us/answers/questions/1319494/new-print-dialog-box-just-let-me-print-once-(c-)
oder
https://stackoverflow.com/questions/57020201/c-gdi-printing-causes-system-to-freezeMan kann über einen Registry Eintrag das Win11 zwingen, den alten Dialog zu verwenden.
Ansonsten wird ein neuer Dialog verwendet.
Mit dem alten funktioniert das Drucken dann wieder.
-
@elmut19 sagte in Ab zweitem Drucken unter Win11 friert Anwendung ein:
Aber wie ist das mit der 32Bit-Emulation auf dem neuen Windows?
Könnte darin der Grund liegen?Langsam, mein Bauch sagt mir erst einmal dass man hier nach undefiniertem Verhalten suchen sollte. Es wäre nicht das erste Problem dieser Art.
Als Vorlauf würde ich mal den Application Verifier ausprobieren. Danach würde ich mal den Code Schritt für Schritt debuggen und alle Parameter mittels der MSDN überprüfen.
BTW: Überprüfe mal ob etwas im Device Context selektiert wurde. Die Art und Weise des Selektierens ist leider fehleranfällig. Ich habe mir da selbst einige Handles ins Nirwana befördert, bevor Dr. Memory mir den Fehler zeigte.
-
@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.
-
@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()
?
-
@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.
-
@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
-
@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
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
-
@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?
-
@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 ...
-
@elmut19 Warum nicht einfach ne VM nutzen?
-
@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).
-
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.
-
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.
-
@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.
-
@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...
-
@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.