global variables for function arguments and return value in VB scripts

[JerryKing]

The purpose of my program is to realize the expert reasoning through a sequence of dialogs interacting with a user. All the user inputs of reasoning procedure need to be recorded for future enquiry in a database. The architecture of the reasoning procedure is like a pyramid, from top to bottom. VB scripts or VBA can be used for this application software. I’d like to define a global object, so that it can be used both for arguments and for saving user inputs. Unfortunately, my following codes do not work. Seems there are problems of declare global variable as a structure object. How to fix the problem? Are there some better ways for doing this? Thanks.

Public Structure Operation
Public attributes()
End Structure

Global m_operation as Operation

Sub GetAttribute01(m_operation)
m_operation.attributes(0) = Dialog.GetCurrentVal()
End sub
…


Sub main(id)
GetAttribute01(m_operation)
GetAttribute02(m_operation)
GetAttribute03(m_operation)
…
End sub

 

[chrishirst]

Why not simply use a dictionary object

A couple of simple subs/functions to demonstrate

Dim Dict As Object

Sub Init()
Set Dict = CreateObject("scripting.dictionary")
End Sub

Public Sub NextEntry(Value As String)
Dim key As String
key = "attrib" & Trim(Str(Dict.Count))
Dict.Add key, Value
End Sub

Public Function getEntry(ID As Integer) As String
If ID > 0 And ID <= Dict.Count Then
    getEntry = Dict.Item("attrib" & Trim(Str(ID)))
End If

End Function

 

[nhebb]

In order to use the Dictionary object, you need to reference the Microsoft Scripting Runtime, scrrun.dll. But, if you're going to distribute the application to other users, you need to tread carefully.

The reason the dll is called "scripting" runtime is because it was designed to provide file system operations for web servers for use in ASP pages. It was never intended for desktop applications.

Microsoft's official policy is that you should not redistribute it with your application. Each version of Windows has a different version of it, and you should never try to install over the existing version. The differences between the versions can cause runtime errors.

It may work fine for your application, but I just thought I should warn you of potential problems.

 

[FrancisL]

Do you have a reference for the Microsoft official policy on this? I searched MSDN with no luck, other than to find that they themselves distribute it with Office.
For what it is worth, I distribute it with my software and have never had a problem.

 

[chrishirst]

Same here.

I have several applications that use a dictionary, both desktop and web server varieties.

The reason the dll is called "scripting" runtime is because it was designed to provide file system operations for web servers for use in ASP pages. It was never intended for desktop applications

So are you trying to tell us that the Windows Scripting Host (WSH) should never be on ANY desktop machine and Internet Explorer should NOT support VbScript??

Each version of Windows has a different version of it, and you should never try to install over the existing version. The differences between the versions can cause runtime errors

That's why you use an installer package. All necessary references and libraries are packaged up with the setup files then installed (or replaced) and registered on the target machine.