is it possible to define functions, that can be used by several scripts?
My intention is to build a small library with common used functions to avoid redundancy.
The following does not work:
File C:\Download\mylib\mylib.js:
[code]function myFunc(string) {
DOpus.Output(string);
}[/code]
[code]@Script JScript
function includeFile (filename) {
var fso = new ActiveXObject('Scripting.FileSystemObject');
var fileStream = fso.openTextFile(filename);
var fileData = fileStream.readAll();
fileStream.Close();
eval(fileData);
}
The .wsf file looks the nicest, but I don't know if that will work with Opus or not. Worth a try, though. If it is implemented as a meta-scripting language then it should work with Opus, but it could be implemented in a different way.
@leo
Windows Scripting Components work with DO on XP-32 and Win7-64.
I did a wsc-extension to DO recently, which is not done yet, but I see no reason to not make any use of them. Did not encounter any trouble, it handles just like any other ActiveX-Object, it's cool. o)
// Eval in global scope - that's the trick
eval(includeFile('C:\Download\mylib\mylib.js'));
function includeFile(filename) {
var fso = new ActiveXObject('Scripting.FileSystemObject');
var fileStream = fso.openTextFile(filename);
var fileData = fileStream.readAll();
fileStream.Close();
return fileData;
}
function OnClick(click_data) {
myFunc('blubb');
test();
}
[quote="tbone"]@leo
Windows Scripting Components work with DO on XP-32 and Win7-64.
I did a wsc-extension to DO recently, which is not done yet, but I see no reason to not make any use of them. Did not encounter any trouble, it handles just like any other ActiveX-Object, it's cool. o)[/quote]
Neat! I wasn't sure if that was the same thing you were talking about, or something else. That could come in handy.
Yes, that's one of the main drawbacks. A WSC on the other hand, will give you an error popup if the code within fails, which is something you need to get used to at first, but it get's the job done. Error messages are very acurate at least and issues are easy to trackdown with their help. The error popup can be disabled, I had problems to get the corresponding error to appear in the DO log window though.
@dinkel
A WSC is a regular script file wrapped into some pieces of xml. You can look at it as a plain-text, scripted DLL and it does exactly what you have tried with your eval() approach, sharing functionality between modules or different applications.
Methods/properties added to prototypes within the WSC, will only work inside the WSC. But an object that has been created inside the WSC, which finds it's way back to the scripts scope, will preserve any prototype features.
What I didn't tried yet is to add methods/properties to the global and "fixed" objects from the scripts scope, by passing "this" to the WSC and using "outerThis.String.protoype" for adding things to the object-prototypes from the "outside world". I guess it works. For consistency though, you should handle both scopes when modifiying prototypes or maybe even better, only use the "outside world" prototypes when creating/modifying objects within the WSC.
