Ab zweitem Drucken unter Win11 friert Anwendung ein
-
@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.
-
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.
-
@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.
