Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Cheesy solution of the week...or Stupid Programmer Trick
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire de rapports & Rapports
Divers
Thread ID:
00104032
Message ID:
00104315
Vues:
21
>George,
>
>Why exactly does it matter if they printed from the preview window?
>
Several reasons. Assume a series of check boxes indicating output: Preview, Print, File, for example. What if the user accidentally clicks the Print button rather than exit. Whoops, 2 copies if you can't tell. Largly, IMO, it's simply matter of trying to design the most efficient yet flexible interface.

>I think it might be better polling the queue every few seconds to see if a VFP printjob pops up in there, but that depends on not renaming the document, and not having another VFP app putting jobs in the queue at the same time, etc., etc.
>
I initially tried EnumJobs(), but because the timer kept being disabled (or I somehow didn't call it right, did return .T. however) I kept missing it. Same for FindWindow(). The "Printing..." dialog is the class and type as the debugger (according to Spy++), and FindWindow should be able to see it. But again, since the timer doesn't fire while it's out there, VFP never knows it.

>Cancel might be detectable by polling the job status. But kinda the same question: why worry about it if they cancelled the printjob?
>
I don't see how. Even if you could, assume the check boxes, did the user hit cancel because they decided they didn't want it printed or because they realized that the Printer check box was checked?

Of course, if we had some control in this area, this wouldn't be aan issue.
George

Ubi caritas et amor, deus ibi est
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform