#1
|
|||
|
|||
Scope of script objects and VisBuild steps
Hi,
I have a script w/ some additional functionality which is easy to add to a project via Insert->Build In->Script. This script is rather large and it takes few minutes before it completes its work. 1. How can I split this script up into smaller steps BUT in such way that variables do not go out of scope? I have a case that several functions (I'd like them to become steps in a project) will operate on the same file and I don't want to save and reopen this file every single time when when step means executing separate script file. In that case all my variables would go out of scope when I end script execution and I would have to set them again when I begin executing next step (next script). 2. I have seen various tabs in Script Editor and one of them is Project Tab. Can I instantiate an object or set a variable of global (Project) scope and have be available in to all scripts which will execute throughout the project? I'd appreciate some pointers here but I'll try to experiment on my own as well. |
#2
|
|||
|
|||
This script doesn't work
I just placed this simple script into Project Tab in Script Editor page. One global variable and two procedures (one sets global variable and the other one reads it)
--- BEGIN --- Dim var Sub SetVar() var = "My Name" End Sub Sub GetVar() MsgBox "Value is: " & var End Sub --- END --- Now, I insert two new Script steps; first step calls SetVar procedure and the second one calls GetVar. When a MsgBox pops up it is unfortunately w/out var set to "My Name" ... it only reads "Value is:" Why? PS. The only way this works the way I want is when I globally set var to some value like this: Dim var var = "My Name" Sub GetVar() MsgBox "Value is: " & var End Sub But this defeats the purpose. Does exactly what I was affraid off .. variables go out of scope. Last edited by Sotorin; 03-12-2004 at 12:30 PM. |
#3
|
|||
|
|||
Script variables do not persist between projects steps. This would lead to lots of difficulties (the least of which is that all global variable names would have to be unique across all steps in a project).
One option would be to modularize the script code into one or more project or global script functions. Another one would be to store the values from your file into a temporary macro, and then iterate over that for each value: http://www.kinook.com/Forum/showthread.php?threadid=231 |
#4
|
|||
|
|||
This is what I have tried
Let's simplify things - I have a project w/ two "Run Script" steps. I open up Script Editor, click on Project Tab and type in the followring VBscript:
============= ' these are global variables (w/in the script scope of course) Dim objXML Dim var1, var2 Function CreateXMLDoc() Set objXML = CreateObject("MSXML2.DOMDocument") If (objXML.Load(<XML file here>)) then CreateXMLDoc = True Else Err.Raise 1, "", "Error loading file" End If End Function Function SetVariables() If Not (objXML Is Nothing) Then var1 = objXML.selectSingleNode(<query here>).Text var2 = objXML.selectSingleNode(<query here>).Text End If End Function ============= Now when my first "Run Script" step calls CreateXMLDoc()everything is OK but when the second step calls SetVariables() then I get an error "Object Required" - evidently objXML went out of scope when CreateXMLDoc finished even though objXML was declared as global variable. You suggested that I "... modularize the script code into one or more project or global script functions ..." Isn't putting this code under Project Tab (in Script Editor) that very thing? Where would I have to place this code in order for it to be available to all the "Run Script" steps? I'm insisting on having global access to variables because it is extremely inefficient to load large XML file, change a node, unload for every step that operates on the same XML file and this is the very case in our VisBuild project (multiple steps modify/operate on the same XML file in succession). |
#5
|
|||
|
|||
Why does the code need to be in separate Run Script steps? Could you modularize the code into functions, and then call these as necessary from one Run Script step that instantiates the XML document and passes it to the functions that do the necessary work?
|
#6
|
|||
|
|||
Code does not have to be in separate Run Script steps as far as I am concerned - it's the clients' requirement. Originally we had everything wrapped into one Run Script step (just like you suggested in your post) but they didn't like it saying "we don't know what's going on inside of this step and we want to see it". So, that's the origin of that. Seems like we are going to have to meet half way with them.
|
|
|