Extract .rtf from Binary Table for Printing
Posted 27 April 2007 - 15:27
What I hope to do is create a button on the dialog to call, let's say a vbscript to accomplish these objectives if possible.
I guess I should ensure the vb runtime is present also, if I can go this route. There's merge modules to handle that part of it, I believe.
Any help appreciated!
Posted 30 April 2007 - 01:46
I'm also wondering if adding this vbscript CA to my project will be effected by the vbscripting runtime or lack thereof. I know there is a merge module for it, but I don't know that that would help me because the action will fire from a button in the UI.
Any more information would be appreciated, as always!!
Posted 30 April 2007 - 08:46
VBScript custom actions are generally risky since they sometimes get blocked by anti virus software and other "smart security features". However, even if the scripting host is disabled on the machine in question the custom action should still run since MSI includes its own VBScript host.
If I were you I would rewrite this in either C/C++ or Installscript and then use the shell execute feature as illustrated in the link provided above.
Posted 30 April 2007 - 09:56
But some time, I don't understand the exact reason, the files in supportdir are not extracted into temp folder; though the supportdir folder gets created but its blank.
So, I think better way will be to keep file in binary table and extract thru a CA. What you say?
Posted 30 April 2007 - 10:18
Posted 30 April 2007 - 16:40
BTW why do you duplicate the rtf in the Binary table? COuldn't you simply extract the RTF text from the Scrolling Text control table?
Posted 01 May 2007 - 05:48
Posted 09 May 2007 - 14:44
TempFolder = Session.Property("TempFolder")
ExtractBinary "eula", TempFolder & "EULA.rtf"
Print TempFolder & "EULA.rtf"
Function ExtractBinary(BinaryName, OutputFile)
Const msiReadStreamAnsi = 2
Set oDatabase = Session.Database
Set View = oDatabase.OpenView("SELECT * FROM Binary WHERE Name = '" & BinaryName & "'")
Set Record = View.Fetch
BinaryData = Record.ReadStream(2, Record.DataSize(2), msiReadStreamAnsi)
Set FSO = CreateObject("Scripting.FileSystemObject")
Set Stream = FSO.CreateTextFile(OutputFile, True)
Set FSO = Nothing
Set shell = CreateObject("WScript.Shell")
shell.Run Session.Property("SystemFolder") & "write.exe /p " & TempFolder & "EULA.rtf"
Set shell = Nothing
Should I change this CA to script executed from install (Wise's option for executing from Binary Table)? Would that be safer in that any script blocking won't detect, prevent this from running. Also, should I add 'On Error Resume Next' in there anywhere. If there is some reason they couldn't print, I wouldn't want the install to blow up altogether!
I'm not really savvy enough to create a .dll to accomplish this, then pass the needed parameters to it from the install (Wise does have a dll CA where parameters can be passed). I would like to learn, however, if its safer. However, I am in a pinch and since what I have now appears to work, if I can ensure the vbScript will run, I would like to take that approach for now since I'm up against a nearing distribution deadline (this Friday, May 11, 2007!). Please don't let this prevent anyone from providing .dll pointers if its fairly easy.
Currently I am duplicating the .rtf's in the binary table as I don't see the reference Stefan supplied earlier. I don't know that this is critical at this point so let me know if I should consider it so.
THANKS ALL FOR THE INFORMATION!!!
I LOOK FORWARD TO HEARING FROM SOMEONE SOOOOON!
Posted 10 May 2007 - 16:16
Posted 10 May 2007 - 19:13
I've been informed in a Wise forum, that Microsoft does not recommend using vbScript on VISTA. I then read several postings of various installations failing on VISTA due to vbScript useage. These problems appeared to be caused by the installation of vbscript.dll with the VISTA OS, but it is not registered.
Another potential problem is script blocking. I believe we did experience this occassionally with our deployed installs at my previous place of employment. Users were just told to allow the script.
Any information, help, opinions are as always GREATLY appreciated!!
Posted 10 May 2007 - 22:35
Con1: Sometimes scripting gets disabled. Some anti-virus products (at least Norton AV 2000) disable the use of some functions in the FileSystemObject object. If you target Windows NT 4 or Windows 95, these OSes do not come with scripting installed (it comes with IE4). Finally, on a product of mine targetted at thousands of users, the helpdesk reported about two Windows XP systems that generated the relevant error - Windows Installer has a special error for this.
Con2: Scripting is not very stable. One of the MS Office Setup developers (someone like Heath Steward or Rob Mensching, forgot) wrote on his blog that the setup team banned the use of scripting in Setups, and that the reliability improved after that. I have the same opinion, I find it much easier to handle an exception in a DLL, compared to the error object in a script.
There is also a Pro: Scripts can be reverse engineered. Advanced users (think of administrators of corporate environments who have to know what kind of software they are deploying) can open the script and study its internals.
This even came to the rescue for the MDAC 2.6 MSM by InstallShield, it contained one script to detect the current OS / installed MDAC version, and decide whether MDAC should be installed. That script contained a bug, as it assumed that Windows XP was the highest version of Windows... ever. So this script made a wrong decision on Windows 2003. But, since it was a script, we could all correct the script instead of waiting for InstallShield to correct the problem.
In my opinion the cons weigh more than the pros, but its your decision.
Posted 11 May 2007 - 13:51
My current vbscripts are basically used for extracting a binary file and printing it in one of our installs and a script to determine the status of the ASP.NET 2.0 Web Service Extension in our web application install.
They are small and I guess would be easy to convert to something else if problems arise.