Print Templates print preview window closes unexpectly when printing document

Question

This is a cross posting from Internet Explorer Web Development after a suggestion that this forum would be a better location. See
https://social.msdn.microsoft.com/Forums/ie/en-US/351e1245-b606-4467-9f3c-1c72f9cdf9ea/print-templates-print-preview-window-closes-unexpectly-when-printing-document?forum=iewebdevelopment.
I have raised an issue through Connect for this:
https://connect.microsoft.com/IE/feedback/details/1134168/ie9-to-ie11-print-templates-print-preview-window-closes-unexpectly-when-printing-document, but I would like some more visibility of the issue as my customers thought my application was closing when
they printed a document.  I also don't know if an issue in Connect gets any priority support via MSDN, but this forum does.
This looks to me like a problem in the IE Print Templates startDoc API call, but if there is a more appropriate forum to raise this issue in please let me know.
In the application where I use print templates, the window closing is not in it self a problem because the Javascript that is calling startDoc also closes the Print Preview window when the print is finished.
The fact that the application looses focus and can be hidden by the windows of other applications when the Print Preview window is closed by startDoc is the issue noticed by our customers, so I need a fix preferably, or a work around at a pinch.
Details of the issue reproduced below.
When using IE Print Templates, the startDoc function is causing the print preview window to close.  This behaviour started with IE9, and is still present with IE11.
When an application is using print templates (see
https://msdn.microsoft.com/en-us/library/aa753279(v=vs.85).aspx) for print functionality, this has the effect of causing the application to become hidden by any other application window once printing from the print preview window has started.  It is
actually this behaviour that started me looking at this issue as the users thought the hosting application had closed.
Print Templates are not accessible by using IE as a web browser, but only when using the WebBrowser Control to embed IE in an application.  The reference for this feature is available from this url:https://msdn.microsoft.com/en-us/library/aa753279(v=vs.85).aspx
and a sample Microsoft application that demonstrates the use of Print Templates can be used to demonstrate the problem (required for the reproduction steps).  The application is available via this article and searching for "download spiffy".
Steps to reproduce the problem:
To see the full effect of the issue, first ensure there is a window from another application (like Windows Explorer) that will cover the sample applications window if brought to the foreground (making the Windows Explorer window full screen works).
Start the sample application (and ensure that the full screen Window Explorer is the next application to activate).
Then in the drop down box in the top right corner of the UI select Template8.htm.
Click the Print Preview button that is just below the drop down box (this will open a new Print Preview window).
In the new window click the Print… button (this will open a Print dialog).
Click the Print button at the bottom of the Print dialog.
The Print dialog closes (expected) and then the Print Preview window also closes (not expected), however the document is still printed successfully.
When the Print Preview windows is closed unexpectedly, the Windows Explorer window is brought to the foreground (obscuring the sample applications window).
If you reselect the sample application and click the Print Preview button again, the Print Preview dialog is not displayed unless you restart the application (this looks to be a symptom of the same issue, not a separate problem).
To see that the Print Preview window appears to be closed by the startDoc call, use the resource editor in Visual Studio (the exe can be opened directly by File | Open | File…) to edit the HTML resource "TEMPLATE8.HTM" (I found I needed to delete
it and add it back in for the change to stick), find the startDoc call and add two alerts, one on the line before and one on the line after.  When IE is accessing the template, it is being done using the name of the executable (so do not rename the modified
version of printtemplates.exe, make the changes to a copy in a different directory if you don't want to change the original).  Start the modified version of the application and follow the same steps as in the reproduction.  This time, after clicking
the Print button in the Print dialog, the dialog will close, the first alert will pop up, then the Print Preview window will close, then
the second alert will pop up.
Thank you,
Warren.

Answer 1

Hi Shu,
I have noticed that the print templates API is listed as part of the Legacy APIs. 
Is this just because it hasn't changed or is not new?  Or does this mean that it is no longer maintained and may be removed (or at least deprecated) at some point in the future? 
It would good to know if we should start planning for the implementation of a different method of printing.
I understand that the sample application is no longer maintained, but I also think that the Print Template API that it uses has not changed, and so should still work (and it does mostly).
If the Print Preview window was being closed as a result of using the Print dialog (and if it had behaved the same way with IE8) I would be willing to go with the by design argument.  
I have found that the Print Preview window is not closed until startDoc is called, and it closes before control is returned from the startDoc function. 
Just as part of investigating and try to find a workaround, if I call window.close(), any alert calls made no longer display the alert window after the close call. 
Alert still functions after startDoc has closed the window however. 
The is not the sort of consistent behaviour I would expect from something that is by design. 
Also while investigating, I found that calling startDoc after calling window.close() results in an exception with the error code -2147467259 (0x80004005), this is probably quite normal and expected, but does indicate that the Web Browser Control should
not be closed till after printing.
I had found that old thread, and I had concluded it was the same issue, but it was also aimed at different aspect of the problem (which I see in the sample application, but not my application). 
The visible issue I have is that my users think the application has been closed because after clicking print (on the Print dialog) the application gets hidden by other windows from other applications. 
This aspect affects the sample in the same manner and so it was a convenient way to demonstrate the problem.
If IE connect do not look at this issue any time soon, do I have any other avenues to resolve this issue?
Thank you,
Warren.