vbscript - how to expose variables from msscriptcontrol?

Question

I'm trying this for a while now.. is it possible to expose variables and other things to the main script with msscriptcontrol?

example of this control:

set a = createobject("msscriptcontrol.scriptcontrol") 
a.language = "vbscript" 
a.executestatement "ab = 12" 
msgbox a.eval("ab") 

what i like to do is to make an activeX com dll in vb6 for including other scripts in my vbscript. the old way i did that was: read a file with an fso object and executeglobal the content of the script file. now i want to wrap that into an activeX dll. here some pseudo-vbscript-code to show you what i'm trying to accomplish when the dll is finished:

set include = createObject("scripting.includeFile") 
include.file "c:est.vbs" 
call sub_in_test_vbs() 

anny ideas? I was trying to do this with an include function inside a vb6 class with msscriptcontrol but it can't do "executeGlobal" and expose the script to the main vbscript...

[EDIT for: Ekkehard.Horner]

Sub Include(File)
ExecuteGlobal(CreateObject("SCRIPTING.FILESYSTEMOBJECT").OPENTEXTFILE("FILENAME & ".VBS", 1).READALL & vbNewLine)
End Sub

Answer 1

If you want to write COMponents in any COM(ic) language and use them in any COM(ic) language - even without registration - then use Windows Script Components.

Update:

From your comment

so sometimes i split the large script into smaller vbscript's, put them into a folder and make a main script that reads everything in that folder and executes what's in the scripts. in the main file there is a sub called "include" (see example in my question) so that i can include files like in e.g. c++ ore something. the problem is that every time i do this i have to write that same "include" sub in the main vbscript so i wondered if i can make an activeX dll in vb6 so that i just can do this: createobject("blah.include").include "filepath"...

I assume that your real world problem is code re-use via modules/libraries in VBScript. That can be achieved without the overhead of MS ScriptControl, vb6, and dlls.

(1) Use something like

Dim gsLibDir : gsLibDir = "M:libkurs0705"
Dim goFS     : Set goFS = CreateObject( "Scripting.FileSystemObject" )
ExecuteGlobal goFS.OpenTextFile( gsLibDir & "BaseLib.vbs" ).ReadAll()

If all your re-usable code is in BaseLib.vbs (and it would be if you didn't distribute the code into many smaller files in that folder just for the privilege to 'read everything' from there), you are done.

(2) If you have a few specialized libs (Database, XML, MS Office automation, Libre Office automation, ...) and want to select from that set according to the task of your main.vbs, either (a) add a few lines like

ExecuteGlobal goFS.OpenTextFile( gsLibDir & "XmlLib.vbs" ).ReadAll()

or (b) put a Sub include(suitableparms) into BaseLib.vbs and call it like

includeLibs Array(                 _
           "§LibDir§ReLib.vbs"     _
         , "§LibDir§TxtManLib.vbs" _
         , "§LibDir§ADOConst.vbs"  _
         , "§LibDir§ADOLib.vbs"    _
         , "§LibDir§WMILib.vbs"    _
         , "§LibDir§DNLib.vbs"     _
         , "§LibDir§XPLLib.vbs"    _
                 )

Of course, such a Sub should provide more functionality than

Sub Include(File)
  ExecuteGlobal(CreateObject("SCRIPTING.FILESYSTEMOBJECT").OPENTEXTFILE("FILENAME & ".VBS", 1).READALL & vbNewLine)
End Sub

which - quote & name errors aside - is equivalent to (a) with the additional overhead of a call. Just as useless/bloated is

sub includeFile (fSpec)
    dim fileSys, file, fileData
    set fileSys = createObject ("Scripting.FileSystemObject")
    set file = fileSys.openTextFile (fSpec)
    fileData = file.readAll ()
    file.close
    executeGlobal fileData
    set file = nothing
    set fileSys = nothing
end sub

(cf. here, further food for thought)

So put some effort in the design of a Sub include() that deals with possible syntax errors in the files included, avoids loading the same module more than once, and provides extra payload (search a list of lib folders, garantee an ordered sequence of unloading, doing initialization/clean up, ...) - or stick with (a).

(3) If you want to mix languages and use the features of COM, forget ExecuteGlobal and use .wsf and .wsc files. If you 'don't know a thing about XML and ... don't have experience with wsc files and how to register them correctly', then you'll have to learn about these strange beasts, preferably by studying the docs.