> Hi evereone,
>
[quoted text clipped - 7 lines]
> print
> out.
There is no "command". You have to set the CancelError property to True and
then trap for an error the control raises when the user clicks the Cancel
button. Here's some example code:
-----BEGIN CODE SNIPPET
On Error GoTo EH
CommonDialog1.CancelError = True
CommonDialog1.ShowPrinter
<do your printing>
Exit Sub
EH:
Select Case Err.Number
Case cdlCancel
'User clicked Cancel button on Print dialog box
Case Else
MsgBox Err.Description
End Select
-----END CODE SNIPPET
Yes, it's stupid. It'd be MUCH better if the various Showxxx methods simply
returned a Boolean with False meaning the user clicked Cancel. But the
reason it is the way it is goes clear back to VB1 when the control didn't
have those methods. Instead, it had an Action property that you assigned a
value to display a certain dialog box.
This is one of many things that people find annoying about this particular
control. Because of the annoyances of the control, and it's rather limited
capability, most people use Win32API functions to show the common
dialogs...at least in production apps (they might use the control in demo
apps and the like).

Signature
Mike
Jeff Johnson - 17 Aug 2009 14:34 GMT
> Yes, it's stupid. It'd be MUCH better if the various Showxxx methods
> simply returned a Boolean with False meaning the user clicked Cancel. But
> the reason it is the way it is goes clear back to VB1 when the control
> didn't have those methods. Instead, it had an Action property that you
> assigned a value to display a certain dialog box.
Hurray for backwards compatibility....
Barf.
MikeD - 17 Aug 2009 23:18 GMT
>> Yes, it's stupid. It'd be MUCH better if the various Showxxx methods
>> simply returned a Boolean with False meaning the user clicked Cancel. But
[quoted text clipped - 5 lines]
>
> Barf.
Yep. You know exactly what I'm talking about. <g>
Backwards compatibility is great....but it doesn't mean you can't move
forward either.

Signature
Mike