Scripts with common subroutine

[Guest]

My two files are:

There you go. You embellished the script! (Sorry). Get rid of that Sub Main stuff that is in your x.vb file! Try it exactly as I gave you.

(Remember that #include is like an #insert (if it existed), so you ended up with two Sub Main's, which is invalid.)

[ewkearns]

I think I found the problem! It is right there on the page where #include is documented with examples.

No? Wait. What?

[baudi]

Homeseer actually does provide a couple of functions that help with this general issue. They are described in the Help file.

RunScriptFunc
Public Function RunScriptFunc(ByVal Script As String ByVal Proc As String _ ByVal Params As Object ByVal Wait As ...

RunScript
Public Function RunScript(ByVal scr As String ByVal Wait As Boolean ByVal SingleInstance As Boolean) As Object Purpose This function runs another script. }}-- }}--This ...

[ewkearns]

Perfect example.

PublicFunction RunScriptFunc(ByVal Script AsString, ByVal Proc AsString, _
ByVal Params AsObject, ByVal Wait AsBoolean, _
ByVal SingleInstance AsBoolean) AsObject

All the guy wanted to do was "Include" another bit of code, not learn an alien language. Why does this have to be so hard? No examples. No references.

If it weren't for this forum and the brain trust therein, many of us couldn't get anything to work. I know I couldn't.

[baudi]

It's not another language. It's a function call in the language that he's already using in his script. He can use #include if he wishes; this is simply another way to modularize his code

[donstephens]

There you go. You embellished the script! (Sorry). Get rid of that Sub Main stuff that is in your x.vb file! Try it exactly as I gave you.

(Remember that #include is like an #insert (if it existed), so you ended up with two Sub Main's, which is invalid.)

I think I see what you are saying. Unfortunately, using your exact example returns the same error.

                            Aug-29 3:55:40 PM                           Error             Compiling script test2.vb: 'Foo' is not declared. It may be inaccessible due to its protection level.                                            Aug-29 3:55:40 PM                           Error             Compiling script test2.vb: Namespace or type specified in the Imports 'System.Core' doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases. 

I don't want to be a hassle. I'll try the other suggestion given using the runscript function. I agree that the #include statement seems more elegant, and that it would be helpful if the help files had more examples.

Thanks to all for revisiting this.

[jon00]

I thought I would try the example here and it works fine:

x.vb:

Private Function Foo() As Boolean
Return True
End Function

test2.vb:

#include x.vb
Sub Main(parms As Object)
If Foo() Then hs.WriteLog("Foo", "Is True")
End Sub

Then called the script test2.vb via an event

[donstephens]

Since only I and one other user are having issues, I'm going to assume that he and I have something unique in our settings that is causing this. I am going to look at the ScriptingReferences section of my settings.ini file.

[xs10shl]

There is more than just you - I cant get #Include to work on my scripts running the latest HS3 on Win10, as much as I would dearly love it. I've tried everything from changing the path from relative to absolute, changing the direction of the file delimiters from "/" to forward-slash, and more. The feature would have come in handy for scripts that share common constant and class names, such as the name of an INI file. This is something that "runScriptFunc" can't help with. By the way, does anyone know offhand the performance penalty (if any) of "runScriptFunc", or these types of script calls? It just seems like it could be considerable, depending on how it's implemented, and how many you have. How about nested "runScriptFunc" calls?

runscriptFunc also has the deficiency that it will only run scripts in the scripts directory, AFAIK. No worries when there are only a few, but when maintaining 30-or-so, things get pretty confusing.

It's not a show-stopper, but had I known about vbscript limitations prior to starting, I'd have probably forged ahead and written a plug-in in VB.NET, which would have allowed me access to class structures with methods, etc, etc.

[Guest]

There is more than just you - I cant get #Include to work on my scripts running the latest HS3 on Win10, as much as I would dearly love it..

As you can see in the previous comments, there is a lot of things that one can do wrong that seems logical but will mess things up. Without seeing your actual source code, those helping will not know what is wrong.

Have you tried the simple example above? Does it work? If it does work, have you tried expanding it until you are where you want to be?

[donstephens]

I tried Jon00's example and didn't have any luck. Did it work for you?

[Guest]

It was originally my example, and I did test it before posting. Be sure you entered it exactly as shown.

[xs10shl]

Here's a mini clue as to what is going on. I can run your (aa6vh's) main and function (called y.vb and x.vb, respectively) as-is from a manual event, and that works. After running it first manually from an event, I can also access it from hs.runscriptfunc. If I then modify it and try running it from hs.runscriptfunc WITHOUT FIRST compiling the p-code from running the same manual event, it fails to re-compile, spitting out an error that foo() is undefined. If I then run the now-modified code from an HS Event, everything works again, including the call from hs.runscriptfunc. so the problem appears to be that only the p-code compiler from the event engine honors the "#include statement. the compiler from a hs.runscriptfunc call does not. This makes it unfortunately not useful for me, because 95% of my calls are from a device callback routine, and not from the Event engine. If my understanding of the limitations are correct, I'd have to write an event that ran all of my scripts before I could call them programmatically from other scripts.

(edit, please note this is not a conclusion after exhaustive testing, but it would certainly help explain why I could never get it to work - hs.runscriptfunc is usually the only point where all of my scripts are called, as opposed to using events)

[xs10shl]

Of note, I've tested out a few more examples, including code with multiple #Includes, and also putting #includes anywhere in the code (outside a routine, of course.) All work fine provided each vbscript is first run independently via an "event" runscriptfunc call. All will fail due to an undefined function foo() if first called via hs.runscriptfunc, UNTIL called via the "event" version of runscriptfunc, at which point it works again, without any further modification. This is clearly one stumbling block that has caused a few of us headaches.

[Guest]

Good catch! I have noticed another oddity, in that scripts invoked from an event that have an "Include" will also fail when run after the Homeseer server is restarted (or rebooted).

I discovered that I had to create a special event that runs my scripts, and manually update the script files (to force a recompile, done by simply resaving the script). Since I do not usually restart/reboot Homeseer but once a month, I have not bothered yet to investigate further. Maybe after I finish the upgrade to my Television projection system, I will take the time to discover what is going on, and find a better detour.