UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Define 'scripting'    
 
   
cyberblitz
post May 11 2014, 04:21 PM
Post#1



Posts: 84
Joined: 16-February 13



Hey All,
've been using a little vbscript, particularly the file system object, in this way:
CODE
Set object = CreateObject("scripting.Filesysystemobject")

But no matter how hard I search to interpret this script I cannot find a definition for the part' scripting' that appears before 'filesystemobject'.
Why do I need this object before filessystemobject' and what does it mean?
Go to the top of the page
 
BananaRepublic
post May 11 2014, 04:29 PM
Post#2


Dungeon Cleaner
Posts: 1,504
Joined: 16-June 07
From: Banana Republic


"Scripting" in this context is the namespace of the library. Because you are late-binding, you have to qualify the namespace in addition to the object. You might have seen code like this:
!--c1-->
CODE
Dim rs1 As DAO.Recordset
Dim rs2 As ADODB.Recordset

Note how you have two same names for two fundamentally different (even though they are similar in their functions) - the only way for compiler to know which recordset you mean, you have to specify the namespace --- DAO for DAO's recordset and ditto for ADO's recordset.
If you want to use VBA object model to inspect what Scripting contains, you can add a VBA reference to C:\Windows\System32\scrrun.dll -- that's where the objects are defined and once referenced, you can see all objects & methods.
I hope that help.
Go to the top of the page
 
cyberblitz
post May 11 2014, 04:46 PM
Post#3



Posts: 84
Joined: 16-February 13



So early binding would be:
!--c1-->
CODE
Dim objfso As New Filesystemobject

But why won't you need 'scripting.' here?
I'm assuming because the library has already been referenced?
Go to the top of the page
 
BananaRepublic
post May 11 2014, 04:55 PM
Post#4


Dungeon Cleaner
Posts: 1,504
Joined: 16-June 07
From: Banana Republic


Well, yes, the namespace is optional, but if you go to Tools -> Reference and note that there is a up/down button to set priority. The effect is that if you do not disambiguate, the object is resolved by each referenced library. So if DAO library is higher on the list than ADODB library then a "Dim rs As Recordset" becomes a DAO.Recordset. But run it on a project where ADODB library is higher in priority and it will not work anymore!
Personally, I dislike using unqualified object types like that -- I always use two part qualified names because I've been bitten by too many overlaps --- Word.Range, Excel.Range, UserForm.Textbox, Access.Textbox, Shell.Folder, Scripting.Folder, and many more. IMHO, whether you early or late bind, two-part qualified names help a lot in not only removing ambiguities but also remind which library you are using and thus making your code more clearer to read.
Go to the top of the page
 
cyberblitz
post May 11 2014, 05:14 PM
Post#5



Posts: 84
Joined: 16-February 13



Thanks.
The reason for having to know this is because where I work we having a new system installed (called Metavision) that has a vbscript environment built in. And for some reason, which is a little clearer now, the word 'script.' is put before a function/method/property that I assume the developers have created to allow control or/and retrieve information of certain oobjects/controls.
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    13th December 2017 - 07:11 PM