George,

>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 work from a different mindset here. My report control class has a optiongroup for destination (printer, screen, browse) and a Do Report button, so they select the report, enter and relevant subset criteria and hit the Do report button. More than 1/2 the time they are just viewing the reports without printing.

>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.

Maybe a DoEvents() call in one of the group or page band events might help?

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

Agreed, we sure could use some more control, like having report events Top, Previous, Next, Bottom, GotoPage, Print, Exit and Cancel that get called when the preview buttons are pressed.