Walter,

>>How about a system variable (preferably returning a Boolean value) to let us know if the user has printed a report from the preview window?
>
>Hmmm. Then I would also propose an variable to determine if a report has printed with. (WITH a TO PRINTER PROMPT clause it is handy to know if a user choose to cancel the report. I know this can be done otherwise but this seems more logic to me, to do it this way).

All of this is based on my own work, so...

I don't use the PROMPT clause ever. To me it's useless. All of my reports are generated from dialogs. Using the PROMPT clause simply would be aggavating to the users, since they've already made their choices (date, range, output, etc.) That doesn't mean, however, that someone else might find it useful.

>What about a way to determine if the cancel button has been pressed in a SYS(1037) dialog ?

Hate to be the naysayer here, but SYS(1037) (along with GETFILE(), PUTFILE(), and other calls to the Common Dialogs DLL) wouldn't be a priority to me, since I can pretty much get everything I'd need to know from the ActiveX control. Further, print operations and many user choices in the overall environment, are Windows operations. I don't really care what printer is chosen (or not chosen). If a situation arises where I need to, I use the ActiveX control.

Lastly, there are some things that simply aren't going to make because that functionality (albeit in this case through an ActiveX control) already exists. There are other things that won't happen because that's not the way Windows works. For example, if someone wished for a function to determine whether or not the printer was on-line or not, that wouldn't make it. That's because Windows doesn't know (or care) until something is sent to the printer.