13 replies to this topic

[Superfreak3]

I was wondering if there was a way to extract a binary .rtf file, print it, then delete it. I'm using a Wise product which doesn't offer an easy way to print stuff from their License and/or Read Me dialogs. I was planning on addind the .rtf's as binary files, extract, use the Operating Systems Write.exe (Write.exe /p <extracted location>\eula.rft) to print it, then delete the file.

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!

THANKS!!!

[Glytzhkof]

Maybe this will help?:
http://forum.install...?showtopic=8059

[Superfreak3]

I have a vbscript that seems to stream the .rtf file to the temp folder successuflly. Now, I need to add some code to that script to print the document. I was hoping to use Write .exe in the System32 folder. I could pass /p [TempFolder]eula.rtf to this which will work. I only need to know how to vbscript it. I think I can use something like shell.execute, but don't know.

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!!

[Glytzhkof]

If you are using Installshield you should be able to add the license file to the Support Files view and reference it from Installscript.

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.

[Glytzhkof]

http://msdn.microsof...hellexecute.asp

[antyagi]

Right Glytzhkof, VBScript action might get blocked by antivirus.

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?

[Glytzhkof]

I always execute VBScripts from the binary table, yes. I have never had a problem with my own scripts and anti virus, but have seen problems with vendor scripts. I think it all depends what you are doing in the script whether it gets blocked or not.

[Stefan Krueger]

I don't think you'll need VBScript. You could just launch write.exe as a EXE custom action. But if you prefer to print the file with whatever application is associated with the .rtf extension than you should call the ShellExecute api in a DLL, or download freeware shelexec.exe (only 1 L) which does the same.

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?

[antyagi]

Or may be you can just extract rtf from control table.

[Superfreak3]

OK, here's the CA (code embedded directly in CA)...

Dim TempFolder
TempFolder = Session.Property("TempFolder")

ExtractBinary "eula", TempFolder & "EULA.rtf"
Print TempFolder & "EULA.rtf"

Function ExtractBinary(BinaryName, OutputFile)
Const msiReadStreamAnsi = 2

Dim oDatabase
Set oDatabase = Session.Database

Dim View
Set View = oDatabase.OpenView("SELECT * FROM Binary WHERE Name = '" & BinaryName & "'")
View.Execute

Dim Record
Set Record = View.Fetch
Dim BinaryData

BinaryData = Record.ReadStream(2, Record.DataSize(2), msiReadStreamAnsi)

Dim FSO
Set FSO = CreateObject("Scripting.FileSystemObject")
Dim Stream
Set Stream = FSO.CreateTextFile(OutputFile, True)
Stream.Write BinaryData
Stream.Close
Set FSO = Nothing
End Function

Function Print(sFile)
Dim shell

Set shell = CreateObject("WScript.Shell")
shell.Run Session.Property("SystemFolder") & "write.exe /p " & TempFolder & "EULA.rtf"
Set shell = Nothing
End Function


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!

[Stefan Krueger]

The custom action should be scheduled for immediate execution. Duplicating the file doesn't harm, except increased package size and the need to maintain the file in two locations.

[Superfreak3]

What is the overall feel or opinion for using vbScripts in install Custom Actions? At my previous place of employment, we used vbScripts extensively in our installations using InstallShield. My current company uses Wise products, but they haven't really used any vbScript Actions as I've just introduced one or two small scripted actions.

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!!

[Zweitze]

I have three considerations:

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.

[Superfreak3]

Thanks for the insight.

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.