Pick any one of your existing reports to test this out with SalReportPrint().
Make sure that in SAM_ReportStart you nab the report window handle in wParam AND make that hidden window visible. For example:
Now set yourself up so that when you print the report, it goes to the Microsoft PDF Print Driver (to simulate a print error.)
Code: Select all
On SAM_ReportStart Set hWndReport = SalNumberToWindowHandle( wParam ) Call SalCenterWindow( hWndReport ) Call SalHideWindow( hWndReport ) Call SalShowWindow( hWndReport ) ! Not sure if all of those lines are needed, I may have gotten carried away there copying and pasting much of that from something else I was testing out. Meh ...
When the Microsoft Print Driver asks where you want to save the PDF, click "Cancel".
That should generate a report printing error.
After you click "OK" on the error message dialog(s), you should be left with a blank open window (maybe behind other windows) that SalReportPrint created.
Normally, we wouldn't know about that window because, when printing, that window is hidden.
This has me wondering: if while running an application we have many print errors, can we potentially wind up with so many of these hidden report windows that the application can crash (maybe complaining about too many reports, maybe not complaining at all?)
Now any hidden report window will get closed when the window calling SalReport* happens to close. That's good.
However, if a window repeatedly calls SalReportPrint and keeps getting print errors, there are likely a whole bunch of report windows existing in the background.
Unless one is vigilant about explicitly destroying those report windows.
Which has me thinking that SalReport* should always (as in always always always) involve some these practices:
- get the window handle of the report window (I like putting it in hWndReport) generated by SalReport* on SAM_ReportStart
- just before any SalReport* call, Call SalDestroyWindow(hWndReport)