Microsoft Scripting Runtime #1

[ADezii]

The next series of Tips will involve the Microsoft Scripting Runtime Library (Scrrun.dll). This Library is, in my humble opinion, one of the most useful and practical Libraries ever created. With the Scripting Runtime Library, you can retrieve information related to Drives, Folders, Files, and Text Files and set/retrieve certain Attributes of Drives, Folders, Files, and Text Files. Through Methods exposed by this Library, you can also manipulate these Objects. Because of the extensive functionality exposed by this Library, I have broken it down into several Components which will be the subject matter for the next series of Tips. Our first related Tip will show you how to retrieve specific and vital information for all Drives on your PC, or for a single Drive of your choosing. The code is fairly intuitive, and I have inserted Comments wherever I thought they would be appropriate. This code was used on a Pentium 4 PC with a CD ROM Drive, DVD Drive, Floppy Drive, a single non-partitioned Fixed Disk, and a small Flash Drive in a USB Port. Should you have any questions concerning this Tip, please feel free to ask. Without further adieu, the Scripting Runtime Library Tip #1:
[CODE=vb]
On Error GoTo ErrorHandler
On Error Resume Next 'Critical Line of code

'Must set a Reference to the Microsoft Scripting Runtime Library (Scrrun.dll)

'declare appropriate Object Variables
Dim fso As FileSystemObjec t, drv As Drive, drvSingle As Drive

'Create an Instance of the FileSystemObjec t using 1 of 2 Methods
Set fso = New Scripting.FileS ystemObject
'OR
'Set fso = CreateObject("S cripting.FileSy stemObject")

Debug.Print "--------------------------------------------"
'Loop through all Drives on the PC
For Each drv In fso.Drives
Debug.Print "Drive Letter: " & drv.DriveLetter
Debug.Print " Available Space: " & Format$(drv.Ava ilableSpace, "#,#,#,#") & " bytes"
Debug.Print " Drive Type: " & fDetermineDrive Type(drv.DriveT ype)
Debug.Print " File System: " & drv.FileSystem
Debug.Print " Free Space: " & Format$(drv.Fre eSpace, "#,#,#,#") & " bytes"
Debug.Print " Is Drive Ready?: " & IIf(drv.IsReady , "Yes", "No")
Debug.Print " Drive Path: " & drv.Path
Debug.Print " Root Folder: " & drv.RootFolder
Debug.Print " Drive Serial Number: " & drv.SerialNumbe r
Debug.Print " Drive Share Name: " & drv.ShareName & IIf(Nz(drv.Shar eName) = "", _
"Unavailabl e", drv.ShareName)
Debug.Print " Total Size of Drive: " & Format(drv.Tota lSize, "#,#,#,#") & " bytes"
Debug.Print " Volume Name of Drive: " & IIf(Nz(drv.Volu meName) = "", "Unavailabl e", _
drv.VolumeName)
Debug.Print "--------------------------------------------"
Next

'For a Single Drive, from this point on
Set drvSingle = fso.Drives("C:" )

Debug.Print "--------------------------------------------"
Debug.Print "Drive Letter: " & drvSingle.Drive Letter & " (Single Drive)"
Debug.Print " Available Space: " & Format$(drvSing le.AvailableSpa ce, "#,#,#,#") & _
" bytes"
Debug.Print " Drive Type: " & fDetermineDrive Type(drvSingle. DriveType)
Debug.Print " File System: " & drvSingle.FileS ystem
Debug.Print " Free Space: " & Format$(drvSing le.FreeSpace, "#,#,#,#") & " bytes"
Debug.Print " Is Drive Ready?: " & IIf(drvSingle.I sReady, "Yes", "No")
Debug.Print " Drive Path: " & drvSingle.Path
Debug.Print " Root Folder: " & drvSingle.RootF older
Debug.Print " Drive Serial Number: " & drvSingle.Seria lNumber
Debug.Print " Drive Share Name: " & drvSingle.Share Name & _
IIf(Nz(drvSingl e.ShareName) = "", "Unavailabl e", drvSingle.Share Name)
Debug.Print " Total Size of Drive: " & Format(drvSingl e.TotalSize, "#,#,#,#") & _
" bytes"
Debug.Print " Volume Name of Drive: " & IIf(Nz(drvSingl e.VolumeName) = "", "Unavailabl e", _
drvSingle.Volum eName)
Debug.Print "--------------------------------------------"[/CODE]
[CODE=vb]
Private Function fDetermineDrive Type(intDriveTy pe As Integer) As String
'Interprets the Numeric Value returned by the Type Property and
'returns a String representing the Drive Type
Select Case intDriveType
Case 0
fDetermineDrive Type = "Unknown"
Case 1
fDetermineDrive Type = "Removable"
Case 2
fDetermineDrive Type = "Fixed"
Case 3
fDetermineDrive Type = "Remote"
Case 4
fDetermineDrive Type = "CD ROM"
Case 5
fDetermineDrive Type = "RAM Disk"
Case Else
fDetermineDrive Type = "Unknown"
End Select[/CODE]
OUTPUT:
[CODE=text]--------------------------------------------
Drive Letter: A
Available Space: 833,536 bytes
Drive Type: Removable
File System: FAT
Free Space: 833,536 bytes
Is Drive Ready?: Yes
Drive Path: A:
Root Folder: A:\
Drive Serial Number: 1284401684
Drive Share Name: Unavailable
Total Size of Drive: 1,457,664 bytes
Volume Name of Drive: Unavailable
--------------------------------------------
Drive Letter: C
Available Space: 49,298,620,416 bytes
Drive Type: Fixed
File System: NTFS
Free Space: 49,298,620,416 bytes
Is Drive Ready?: Yes
Drive Path: C:
Root Folder: C:\
Drive Serial Number: 350880761
Drive Share Name: Unavailable
Total Size of Drive: 61,483,933,696 bytes
Volume Name of Drive: Dezii
--------------------------------------------
Drive Letter: D
Drive Type: CD ROM
Is Drive Ready?: No
Drive Path: D:
Drive Share Name: Unavailable
--------------------------------------------
Drive Letter: E
Drive Type: CD ROM
Is Drive Ready?: No
Drive Path: E:
Drive Share Name: Unavailable
--------------------------------------------
Drive Letter: F
Available Space: 10,195,968 bytes
Drive Type: Fixed
File System: FAT
Free Space: 10,195,968 bytes
Is Drive Ready?: Yes
Drive Path: F:
Root Folder: F:\
Drive Serial Number: -2137813243
Drive Share Name: Unavailable
Total Size of Drive: 32,472,576 bytes
Volume Name of Drive: FlashDisk
--------------------------------------------
--------------------------------------------
Drive Letter: C (Single Drive)
Available Space: 49,298,620,416 bytes
Drive Type: Fixed
File System: NTFS
Free Space: 49,298,620,416 bytes
Is Drive Ready?: Yes
Drive Path: C:
Root Folder: C:\
Drive Serial Number: 350880761
Drive Share Name: Unavailable
Total Size of Drive: 61,483,933,696 bytes
Volume Name of Drive: Dezii
--------------------------------------------[/CODE]

[FishVal]

Hello, ADezii.

IMHO "Windows Script Host Object Model" library (\WINDOWS\syste m32\wshom.ocx) is even more useful.
It has all (or almost all) useful classes of "Microsoft Scripting Runtime" as well as a bunch of other very useful ones.

• network
• windows registry functions
• a very useful shell exec method allowing to run an application and get access to its stdin/stdout/stderr as well as to terminate it
• creating shortcuts
• etc

Regards,
Fish

[ADezii]

Hello, ADezii.

IMHO "Windows Script Host Object Model" library (\WINDOWS\syste m32\wshom.ocx) is even more useful.
It has all (or almost all) useful classes of "Microsoft Scripting Runtime" as well as a bunch of other very useful ones.

• network
• windows registry functions
• a very useful shell exec method allowing to run an application and get access to its stdin/stdout/stderr as well as to terminate it
• creating shortcuts
• etc

Regards,
Fish

Hello FishVal and thanks for the info, I never realized that it was quite that extensive. When I am done with this series of Tips relating to the Scripting Runtime could I perhaps interest you in creating a Tip(s) relating to the implementation of the "Windows Script Host Object Model"? I'm sure that it would generate a lot of interest. If you agree, I'll even show you the Top Secret 'Tip Creator Handshake' that only Mary, NeoPa, and I are privy to. (LOL).

[dima69]

Just one drawback from using Scripting. There are some antivirus programs (like Kaspersky AV) that have an ability to block scripting in Access. In such case, Access application just stops running. So if you intend to distribute your application, you would rather consider not using Scripting, as powerful as it is, unless there is no other option.

[ADezii]

Just one drawback from using Scripting. There are some antivirus programs (like Kaspersky AV) that have an ability to block scripting in Access. In such case, Access application just stops running. So if you intend to distribute your application, you would rather consider not using Scripting, as powerful as it is, unless there is no other option.

Excellant point dima69, one that I was not aware of, and one to definately consider should you decide to use it. Within these AV Utilities, is there an option to specifically turn off the Component that would normally block Scripting?

[dima69]

Excellant point dima69, one that I was not aware of, and one to definately consider should you decide to use it. Within these AV Utilities, is there an option to specifically turn off the Component that would normally block Scripting?

I know that in Kaspersky AV there is an option that can be changed to enable Scripting. Don't remember about the others.

[FishVal]

Hello, ADezii

Hello FishVal and thanks for the info, I never realized that it was quite that extensive. When I am done with this series of Tips relating to the Scripting Runtime could I perhaps interest you in creating a Tip(s) relating to the implementation of the "Windows Script Host Object Model"?

You certainly could. Just let me know, please, in advance when "Runtime Scripting" saga will come to a head. :)

Regards,
Fish

[ADezii]

Hello, ADezii



You certainly could. Just let me know, please, in advance when "Runtime Scripting" saga will come to a head. :)

Regards,
Fish

Thanks FishVal, I figure 4 more Tips involving the Scripting Runtime, namely: Folders, Files, Text File manipulation, and the File System Object itself. This should give you plenty of time for the 'Grandaddy of all Tips'! (LOL). See you around and thanks for the assistance.