When I run the install for our application, I include a EULA.rtf file. The file displays properly in the license dialog. I then click the Print button. The windows Print dialog shows and I select Microsoft XPS Document Writer as the printer. I click Print and I get a message stating Title: WordPad, Message: "Could not start print job."
While the setup is open I navigate to %temp% and find the EULA.rtf file. I right click on this file and select print and it correctly brings up the dialog to save to .xps file. It correctly saves the file.
However, within InstallShield Suite Wizard this is not possible.
In the License Agreement Wizard page, I check the Events for the Print button. Print is selected as the click event and the resource correctly points to the EULA.rtf file.
Is there something that I am missing here? I realize that InstallShield is correctly spawing the windows print dialog. It appears as I would expect. However, is there something else that is required to get his to work?
I added a very basic suite UI project that includes orca.msi as the primary package and the default license dialog. The error occurs even with this very basic installation.
All of our tests have been on virtual machines. I wanted to test this outside of the virtual machine. So on my desktop I run the install and click the print button. On my desktop the document opens in Microsoft Word, not WordPad. When I try to click print I am presented with an error. If I go to the temp directory again and open the document in MS word and print, it prints successfully. So something is still wrong.
After selecting a printer, I believe InstallShield 2013's suite printing behavior calls ShellExecute using the 'printto' verb for the file in question (in this case the .rtf). At this point, have you tried different .rtf files, or just different machines? I know I've heard of reports that different versions of Word result in different behavior, as does invoking the print button when Word is or is not currently open.
I tried creating a very basic suite project Michael, one where I just included orca.msi and the stock eula.rtf file. I compiled and tested with the same result.
Again, right clicking on the resulting .rtf file in the %temp% directory will allow the user to select print from the context menu and it will print successfully. Opening the file in WordPad or Microsoft Word, also allows me to print the document. There must be some other strange gremlin in the system.
I just ran another test with WordPad open before pressing the Print button. This too fails with the same error.
I believe we have root-caused the problem; if you happen to have InstallShield 2014, can you cross-check whether the printer selection works correctly from Basic MSI or InstallScript projects? It appears that the Suite printer selection was mishandling the case when the printer's name included spaces; the Basic MSI and InstallScript support in InstallShield 2014 appear to handle this correctly, and I'm hoping to confirm whether that addresses the issue.
I downloaded IS 2014 Premier and created a new Suite project. I created a new feature called MainFeature and added one MSI package, orca.msi. I compiled and tested the install. It exhibits the same behavior as IS 2013 does. 😞
Sorry for not being clearer; I know the Suite behavior between InstallShield 2013 and 2014 would match. However the newly updated printer selection in Basic MSI projects in InstallShield 2014 seems to work better for me. If it also solves the behavior in your case, I'd like to apply its approach to the Suite project's printer selection.
Ahh, sorry I misunderstood the intent of your suggestion.
I tested a basic MSI project, using IS2014, and I can print the license agreement without any errors. I also tested a basic InstallScript project using IS2014 and it works there as well.
Thanks, that pretty much confirms the cause, and I know the fix. What version of InstallShield will it have to be in for you to benefit from the fix? (I can't make any promises, but I can at least put in the request.)
We are currently using InstallShield 2013. I have not yet got permission to upgrade to 2014. Basically I have to wait until QA has time to fully test the installer again when we upgrade. So any hotfix or patch will need to be for 2013 to fix this for us.
I've been looking on Flexera's site trying to determine if a patch was ever released with a fix for this issue for the 2013 version. I haven't been able to find anything so far. Can anyone tell me if such a patch has been released?
