Crystal reports 11 RDC (COM API) displays printer dialog even when I tell it not to prompt

I'm using Crystal Reports 11's RDC (COM) API to print. My code looks like this:

HRESULT res = m开发者_Python百科_Report->SelectPrinter(b_driver, b_device, b_port);
if (FAILED(res)) return res;
// For these calls, the #import wrapper throws on error
m_Report->PutPrinterDuplex(dmDuplex);
m_Report->PutPaperSize(dmPaperSize);
m_Report->PutPaperSource((CRPaperSource)pdlg->GetDevMode()->dmDefaultSource);
if (m_Report->GetPaperOrientation() == crDefaultPaperOrientation)
    m_Report->PutPaperOrientation(crPortrait);

VARIANT vfalse;
VariantInit(&vfalse);
vfalse.vt=VT_BOOL;
vfalse.boolVal=0;

res = m_Report->PrintOut(vfalse);

However, at the end of all this, crystal reports still shows its own printer selection dialog - but only for some reports, it seems. Why does crystal reports show a print dialog even when I pass false for promptUser? And how, then, can I suppress crystal reports' internal printer selection dialog and force it to use my values?

Edit: Whoops, CR11, not CR9.

Some further information:

• The reports that work properly (ie, do not show the print dialog) are generated internally using the RDC API; we create a new report object, import subreports into it, then print the result. No problem there.
• The reports that do not work properly (ie, force the print dialog to open) have been created with a previous version of crystal reports; however, opening and saving the report does not seem to help.
• Sample reports in the Crystal Reports installation directory show the same problem.

I tried reproducing with VBScript; however, the result was that nothing was printed at all (no dialog, no nothing):

Set app = CreateObject("CrystalRuntime.Application.11")
Set report = app.OpenReport("C:\Program Files\Business Objects\Crystal Reports 11.5\Samples\en\Reports\General Business\Inventory Crosstab.rpt")
report.PrintOut(True)
rem Testing with a True parameter to force a print dialog - but no printout and nothing appears (no error either though)

First, let me preface that I'm not a C/C++ programmer, so I'm not able to test the code--my interaction w/ the SDK has been with the VB and .Net interface over the years.

I found the following code from BO's devlibrary:

// A dummy variant
VariantInit (&dummy);
dummy.vt = VT_EMPTY;
HRESULT       hr = S_OK;
// Specify the path to the report you want to print                                    
_bstr_t ReportPath("c:\\Program Files\\Business Objects\\Crystal Reports 11.5\\Samples\\En\\Reports\\General Business\\Inventory.rpt");
_variant_t vtEmpty(DISP_E_PARAMNOTFOUND, VT_ERROR);
// Instantiate the IApplication object
m_Application.CreateInstance("CrystalRuntime.Application.115");
//Open the Report using the OpenReport method
m_Report = m_Application->OpenReport(ReportPath, dummy)
//Print the Report to printer
m_Report->PrintOut(dummy, dummy, dummy, dummy);

Does it work? It should print the report with its 'default' printer settings and without prompting.

You wrote:

However, at the end of all this, crystal reports still shows its own printer selection dialog - but only for some reports, it seems.

Generally speaking, I've found that Crystal tends to ignore commands to suppress dialogs if it thinks something is missing. I've found this to be true with the parameter dialog. Perhaps it apply to this situation as well. I would ask what is different about the reports that cause the dialog to be generated. There is a 'no printer' option that can be set. Perhaps this is the common thread.

Do you have access to the VB6 IDE? If you write the equivalent commands using VB6's interface, does the prompting occur?

You might also investigate using the CRPE32.dll instead of the report-designer control. To be honest, I don't know if the RDC wraps the CRPE DLL or is an entirely-separate code base.

Turns out it was a bug in my code after all - I'd previously put in a wrapper for the RDC API to fix certain other bugs we were having; due to the large number of methods in the IReport interfaces, I wrote a script to generate pass-through stubs for the methods I wasn't interested in. Turns out that script was passing in bogus values for parameters with default values. Oops! Fixing the wrapper code fixed the bug here.