Scripting

I presume you're referring to the common misconception that Null and Nothing are the same thing? Not so.


Negative, I'm referring to the Null characteristics of many other applications. The term is found commonly in Excel, SQL, Access, Oracle, and a whole host of other IT related kajiggers, and they all refer to the same concept. A field whose contents are not merely 0, but non-existent. It's not a stretch to think that a person asking "why" a specific action is taken might have experience in another field, and thus understand the concepts via another set of terms.

Certainly the technically correct thing is to 'Set obj = Nothing' in a purely mechanical sense. I think our (probably now lost) McRip understands the pure mechanics of it, but wanted to know the Why of it as well.

Since we're now in a who's-on-first style last word debate, allow me to be entertaining for a moment.


Just yesterday there was a script posted here to delete a folder. What is was missing was a test to see if the folder actually got deleted. Now, to me, that's such an obvious test for a script whose sole function is to delete that folder!


The clear answer here is to replace the folder to be deleted with an array value. Vis a vis:


arrlocations = Split("\Documents\,files,c:\program files,\settings",",")
Set objFSO = CreateObject("Scripting.filesystemobject")

If objFSO.FolderExists(arrlocations(2) & "\") then
objFSO.DeleteFolder arrlocations(2),True
If objFSO.FolderExists(arrlocations(2) & "\") then
msgbox("Fail!")
wscript.quit(5150)
End if
End if

set objFSO = Nothing
wscript.quit(42)


This should fix their problem reaallll nice.

DISCLAIMER: Please don't use this script.

WScript.CreateObject - make it just 'CreateObject'......

To elaborate on the good Captain's response, when you run VBScript as embedded script, it uses the Windows Installer engine's interpretor (let's call it). The 'WScript' directive tells your script to use the Windows Scripting Host's interpretor which doesn't exist "inside" an MSI.

Note that, confusingly perhaps, you can still use WScript objects, such as WScript.Shell.

Scripts which run externally, either compressed in the Binary table, included as an installed file or from the workstation, can still use WSH. However, since it's assumed in that environment, why bother?

On a style note, you turn off native error-handling but include none of your own. You should *ALWAYS* program defensively. Assume NOTHING. Check that your objects got created, for example. The biggie here, though, is that you delete a folder and don't check to see if it actually got deleted. As I say, assume nothing.

Lastly, although no longer strictly necessary, you should discard your objects at the end of your script. For example:Set WS = Nothing

ORIGINAL: captain_planet

WScript.CreateObject - make it just 'CreateObject'......


Tested it and it works like a charm on uninstalling... Thanks very much.

@VBScab
please try explaining to me why to set "Set WS = Nothing" at the end of the embedded code. Or did I misunderstand it?

ORIGINAL: McRip


ORIGINAL: captain_planet

WScript.CreateObject - make it just 'CreateObject'......


Tested it and it works like a charm on uninstalling... Thanks very much.

@VBScab
please try explaining to me why to set "Set WS = Nothing" at the end of the embedded code. Or did I misunderstand it?


This is a good habit to get into more than anything else. By setting your objects to null values at the end of a script, you systemically avoid situations where a variable might remain set through to another script, or may stay in memory (which is not really necessary anymore, but is still good practice.)

Maybe someday in the future we'll all be using script engines that don't clear out memory on script termination again, and dinosaurs will roam the earth. Then you'll *really* be glad all your scripts terminate their variables.

By setting your objects to null values...Can I be pedantic? Setting an object to 'Nothing' clears the memory and pointers which the object used, which setting it to Null wouldn't do.

confusingly perhaps, you can still use WScript objects, such as WScript.Shell - Maybe to make it a little less confusing (though maybe not....), it's worth mentioning that the argument for the CreateObject function is usually just a ProgId (Programmatic Identifier). Hence, if we trace the ProgId 'Wscript.Shell' in your registry you'll see it points to the COM object you're creating an instance of (C:\WINDOWS\system32\wshom.ocx).

Therefore, what I'm trying to say is that the initial 'WScript' (WScript.CreateObject) is telling the WScript engine to create an instance of whatever ProgId is specified in the brackets.

So, for example for the FileSystem object. You would use:

WScript.CreateObject("Scripting.FileSystemObject").....which would use the WScript engine to create an instance of the ProgId 'Scripting.FileSystemObject', which essentially points to: 'C:\WINDOWS\system32\scrrun.dll'.

Obviously, as VBScab points out, we don't use the WScript engine to instantiate objects in Windows Installer embedded VBScripts.

Hmmm. Maybe I'm just confusing you more. Shut up, Captain Planet.....

ORIGINAL: VBScab

By setting your objects to null values...Can I be pedantic? Setting an object to 'Nothing' clears the memory and pointers which the object used, which setting it to Null wouldn't do.


Speaking of habits... I have this bad (good?) habit of reframing questions when it seems like that might help someone understand, even if the specificity is a bit off. Some people know what "Null" means because it's used very commonly in other areas of IT.

I presume you're referring to the common misconception that Null and Nothing are the same thing? Not so.

In VB and for most in VBScript:
Empty is an un-initialized variant
Null is an un-initialized database field
Missing is an un-initialized optional parameter
Nothing is an un-initialized object reference
vbNullString is an un-initialized string. These are generally used to pass to and from API calls
vbNull is a return value from the VarType function equal to 1
vbEmpty is a return value from the VarType function equal to 0
vbNullChar is Chr$(0)
"" is a zero-length string

No offence, but judging from other posts, I don't think McRip *does* understand the mechanics, hence the clarification.

The point still remains that confusing Null with Nothing (or other items in the list) could have consequences. By all means continue to use the two interchangably if you want but remember the advice given here when your test for Null returns True (or Empty!) and your code goes merrily on its way, possibly wreaking havoc because the test OUGHT to have been for Nothing.

What I'm trying to do here is guide people on how to do things properly, not the way everybody else does it. Any idiot can write a program: writing a program as bullet-proof as possible takes time, care and experience. If nobody provides guidance, you end up with the God-awful lash-ups I see every day. Yeh, it works NOW but what if 'x' happens, or 'y'?

Just yesterday there was a script posted here to delete a folder. What is was missing was a test to see if the folder actually got deleted. Now, to me, that's such an obvious test for a script whose sole function is to delete that folder!

ORIGINAL: McRip

Manually the code works to delete a folder with subfolders and files in there.

Why is this code not working in the "Call VBScript From Embedded Code" tab???

I hope you may help me further. Thanks in advance...


Option Explicit
On error resume next
Dim FoldertoKill
Dim WS
Dim FSO

Set WS = WScript.CreateObject("WScript.Shell")
FoldertoKill = WS.ExpandEnvironmentStrings("%APPDATA%") & "\Dummy"
Set fso=CreateObject("Scripting.FileSystemObject")
fso.DeleteFolder FoldertoKill, True
on error goto 0



don't use embedded code, char limitation 256 IIRC, also a pain to edit. create a script and load it into the binary table.

What the hell did I start here??? Damn...

"On Error GoTo 0" - Turning off Error Handling. That's what I want. I do understand what it means.
Don't start any things VSCab.
I do know how to work with it. You can read what it exactly means on the Microsoft websites...

"On Error GoTo 0" turns off the error handling flag, which causes the host environment to stop executing the current procedure after raising a runtime error.

Cheers

What the hell did I start here??? Damn...


Nothing to see here citizen, move along.

Seriously though, this kind of debate is always rousing and a pleasure to take part in, even if it's horribly misplaced in some poor sap's question thread.

OK, I calm down. I'm just really steamed up about another scripting I don't get to work.
http://itninja.com/question/faulttree-101348

I'm sorry

The clear answer here is to replace the folder to be deleted with an array value. You missed my point. Whether one uses a string, an array element, a Dictionary item or whatever is irrelevant. The point was that there was no detection of a successful deletion.

ORIGINAL: VBScab

The clear answer here is to replace the folder to be deleted with an array value. You missed my point. Whether one uses a string, an array element, a Dictionary item or whatever is irrelevant. The point was that there was no detection of a successful deletion.



Sigh, there's a joke in the code. Thus the disclaimer, I figured you'd appreciate it.

Sorry, Joe. I didn't go through it. Good job you put the disclaimer [grin]

ORIGINAL: aogilmor

ORIGINAL: McRip

Manually the code works to delete a folder with subfolders and files in there.

Why is this code not working in the "Call VBScript From Embedded Code" tab???

I hope you may help me further. Thanks in advance...


Option Explicit
On error resume next
Dim FoldertoKill
Dim WS
Dim FSO

Set WS = WScript.CreateObject("WScript.Shell")
FoldertoKill = WS.ExpandEnvironmentStrings("%APPDATA%") & "\Dummy"
Set fso=CreateObject("Scripting.FileSystemObject")
fso.DeleteFolder FoldertoKill, True
on error goto 0



don't use embedded code, char limitation 256 IIRC, also a pain to edit.  create a script and load it into the binary table.



Maybe I am dumb and you will laugh, but when I load the script into the binary table it won't work.
When I call VBScript from Installation what is the "Script Function Call"?
Because I usually work with embedded code...

Can you help???

It's not necessary to use a function: the script should just run. Having said that, for some guidance on how to use functions, see this thread http://itninja.com/question/faulttree-101167

- To say "it won't work" is less than helpful. What did you get in the log you took when installing. You took a log, right?
- Does the script execute correctly outside of a CA?
- It only just struck me - wy have you created a script for removing folders instead of using the RemoveFile table?

OOOPPPPSSS, I forgot my last post, sorry. I'm currently pretty busy.
I made the mistake twice. I forgot to change it to "WScript.CreateObject". That's it.

The Remove File Table doesn't work as expected... That's why I use scripting...

All works properly...

Cheers

I can't believe that the missing WScript directive made it work. I have a quadzillion scripts which don't use it and they all work. It serves only to explicitly call the WSH which, if you run CScript or WScript (or those executables are linked to the .VBS extension), WSH is called anyway.

The RemoveFile table didn't work as expected? Could it be that you didn't have it set up properly? Which authoring tool do you use?

I'm using Wise Installation Studio 7.3.0.250

ORIGINAL: McRip


ORIGINAL: aogilmor

ORIGINAL: McRip

Manually the code works to delete a folder with subfolders and files in there.

Why is this code not working in the "Call VBScript From Embedded Code" tab???

I hope you may help me further. Thanks in advance...


Option Explicit
On error resume next
Dim FoldertoKill
Dim WS
Dim FSO

Set WS = WScript.CreateObject("WScript.Shell")
FoldertoKill = WS.ExpandEnvironmentStrings("%APPDATA%") & "\Dummy"
Set fso=CreateObject("Scripting.FileSystemObject")
fso.DeleteFolder FoldertoKill, True
on error goto 0



don't use embedded code, char limitation 256 IIRC, also a pain to edit. create a script and load it into the binary table.



Maybe I am dumb and you will laugh, but when I load the script into the binary table it won't work.
When I call VBScript from Installation what is the "Script Function Call"?
Because I usually work with embedded code...

Can you help???


In Wise you put it in the binary, I believe, by doing " Run VBscript from installation" on the script page.
Not sure why your particular script didn't work and dont' have time to look now, but it's got nothing to do with it not being embedded. In addition to being a pain to edit, embedded scripts suffer from the limitations previously mentioned (though I can't pull up any specific reference now I've bumped up against the character limit personally). I feel sorry for you if that's what you use...even notepad is better than trying to edit scripts in that horrible little box. [:@]

I use Notepad++ for editing my scripts. Then I normally copy and paste...
But I changed from Embeddd code to VBScript from Installation.
It's really much easier to handle...

Cheers

I'm using Wise Installation Studio 7.3.0.250In which case, populating the RemoveFile table is pretty straightforward.

In 'Installation Expert' view:
- Select the folder to be deleted in the lower left-hand pane
- Click the 'Operation' button and select 'Remove file'
- Select 'All Files'
- Click 'OK'

In 'Setup Editor' view:
- Click the 'Tables' tab
- Scroll down to find the 'RemoveFile' table
- Find the row which contains the name of the folder you selected
- Remove the '*' from the 'FileName' column

Now compile your MSI.

The above can obviously be done by going directly to the 'Tables' tab but working through the 'Installation Expert' view will enable you to select the correct component.

What if the [INSTALLDIR] does't get deleted because of newly created files in there?

Is there a script for removing [INSTALLDIR]?

An uninstall will only reverse an install, in that by default only those files which the installer put down are the ones which will be removed. If you want to be sure to remove other files, again, use the RemoveFile table and either name them explicitly or, if you want the entire folder to be removed, leave the FileName column empty.

As for a scripted solution, DeleteFolder (or, as I prefer, objFolder.Delete) won't care if the files are newly created or not. Indeed, it won't care if there are files therein or not, permissions and file attributes notwithstanding, of course.

Hi,
I have the code in VBScript like the following:
Dim fso As System.Object
fso = Nothing
fso = HttpContext.Current.Server.CreateObject("Scripting.FileSystemObject")
it gives me the error with " Object reference not set to an instance of an object."
Did I miss anything?
Thank you vey much in advance.

This is all academic nonsense now as we'll all soon be using Powershell. [:D]

ORIGINAL: VBScab

An uninstall will only reverse an install, in that by default only those files which the installer put down are the ones which will be removed. If you want to be sure to remove other files, again, use the RemoveFile table and either name them explicitly or, if you want the entire folder to be removed, leave the FileName column empty.

As for a scripted solution, DeleteFolder (or, as I prefer, objFolder.Delete) won't care if the files are newly created or not. Indeed, it won't care if there are files therein or not, permissions and file attributes notwithstanding, of course.



You are right, VBScab.
Have you an example for deleting [INSTALLDIR] with scripting?
Because I hate all the cmd popups during uninstall using reg.exe, subinacle.exe and other commandline utilities... It doesn't look fine.

And for subinacle I use the folling script for testing. Manually it seems to work but in Windows Installer it doesn't. It's weird at the moment...

Public Sub StartApplication(App, WindowStyle)
dim aShell

set aShell= CreateObject("WScript.Shell")
aShell.Run App,WindowStyle
set ashell=nothing
end sub

StartApplication "%SYSTEMROOT%\system32\subinacl.exe /keyreg HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{436F4AD7-C95B-4d2f-B0F8-8DC643F7A200} /grant=[LogonUser] =F",0


For deleting [INSTALLDIR] at the end of uninstall I'm currently using this code

cmd.exe /c RD "[INSTALLDIR]" /S /Q


This is all academic nonsense now as we'll all soon be using Powershell. [:D]Dream on...:)

Because I hate all the cmd popups during uninstall using reg.exe, subinacle.exe and other commandline utilities... It doesn't look fine.Er.......so use the RemoveFile table. No script, no pop-ups, no problem. It works.

This dicussion is really funny. I enjoy it...

What's about this code. Does it work? I didn't test it yet.


Function removeDir()
Dim pathToFolder, smallPath
Set objFS = CreateObject("Scripting.FileSystemObject")
pathToFolder = Session.Property("INSTALLDIR")
smallPath=Left(pathToFolder,Len(pathToFolder)-1)
If (objFS.FolderExists(smallPath)) then
objFS.DeleteFolder smallPath, true
End if
End Function


It won't work in any other type of action than embedded because you're using the Session object. That only exists "inside" the MSI. Once you call a script externally, you've lost it. The solution to that is to pass the property on the function's command line.

And my last response in this thread is.................use the RemoveFile table.