Hallo.
Ich wollte gerade einen Ausdruck in Vorschau über den Systemdialog ausgeben. Zuerst rufe ich den Druckdialog auf:
ContainerControlExport1.PGrafic=OpenPrinterDialog(PSetup)
Hier wähle ich “In Vorschau öffnen” (Auswahlmenü PDF, unten links im Dialog) und klicke auf den Drucken-Button. Der Druckdialog verschwindet und in meinem Code geht es weiter. Dort rufe ich einen Dialog auf, in dem diverse Einstellungen zur Druckausgabe vorgegeben werden können:
UserDialog.ShowModal
Leider wird jetzt vom System ein weiterer Dialog über meinen Einstelldialog gelegt und ich kann meinen Dialog nicht bedienen. Alles hängt 
Ich bin mir recht sicher, dass dieses Verhalten (relativ) neu ist. Zumindest als ich die Funktion damals so eingebaut habe, gab es das Problem noch nicht.
Was blockiert hier meinen Dialog und wie kann ich das verhindern?
Gruß, Stefan.
Dreh es um.
Deinen Dialog zuerst und dann erst OpenPrinterDialog dialog.
Oder besser diese Einstellungen vorher machen, lange bevor man zum Drucken Dialog kommt.
So etwas hatte ich befürchtet
Da hängt leider ein ziemlicher Rattenschwanz dran, weil der Anwender den Dialog selbst gestalten kann. Ich muss erst mal prüfen, ob dafür schon irgendwas vom Druckdialog benötigt wird.
Blöd.
Danke für den Hinweis.
Gibt es keine Möglichkeit, trotz des Dialogs mit meinem Code weiter zu machen? Ich bekomme dan ja durchaus in den Vordergrund aber bedienen kann ich ihn dann nicht. Was blockiert meinen Dialog?
Verschachtelte modale Dialoge funktionieren nicht gut in macOS.
Mein Vorschlag: Prüfe, z.B. über AppleScript, ob dein Fenster frontmost ist - wenn nicht, warte solange. Allerdings - wenn der fremde Dialog nicht von selbst verschwindet, hilft das nix. Baue auf jeden Fall ein “App.DoEvents” in the Warteschleife ein.
Allerdings finde ich es seltsam, daß das fremde Fenster “Vorschau” heißt. Das sieht so aus, als ob da jemand die Option für eine Vorschau aktiviert hat, obwohl du eigentlich direkt drucken wolltest. Wie das kommt, weiß ich leider nicht.
Ich hatte schon versucht, aus .Showmodal nur .Show zu machen
Dazu habe ich dann auch im Open- und Close-Event eine Variable UserdialogOffen as Boolean angelegt, die ich nach .Show in einer Do-Loop Schleife (mit DoEvents) abfrage. Das hat aber leider auch nicht funktioniert.
Ich wollte nicht drucken. Ich wollte über den Druckdialog die Ausgabe in Vorschau umleiten. Das ist also durchaus korrekt. Nur hatte ich bisher vom Druckdialog diesen Dialog mit Wartebalken nicht. Schon merkwürdig.
Grundsätzlich funktionier mein Programmablauf, wenn ich entweder keinen Userdialog habe oder die Ausgabe direkt in eine Datei geht (speichern als Bild).
Es wird eohl darauf hinaus laufen, dass ich mein Programm umstricken muss und der Aufruf des Druckdialoges nach dem Userdialog erfolgt. Mal sehen, was das für Probleme mit sich bringt.
Danke für die Tipps.
Wenn du ein Demo-Projekt zeigen könntest, wo du die Umleitung drin hast, dann werden wir dir vielleicht besser helfen können und dir das Umschreiben ersparen. Ich bin sicher, daß sich das lösen läßt.
Ja, guter Ansatz. Ich schau mal, was das für ein Aufwand ist. Die Routinen die da im Einsatz sind, sind recht umfangreich, die kann ich nicht einfach in ein Testprojekt stecken. Das muss ich reichlich abspecken.
Auch wenn der Ansatz, den Userdialog vor den Aufruf der Druckfunktion zu setzen, mir momentan der größere Aufwand zu sein scheint, wird es vermutlich die sinnvollere Variante sein.
Ich schau mir das die Tage mal näher an und melde mich bei Bedarf wieder.
1 Like
Der Umbau, den Userdialog vor den Aufruf des Druckerdialogs zu verlegen war geringer als befürchtet.
Jetzt befürchte ich nur, ich habe etwas übersehen. 
1 Like
