| Author |
|
device
Newbie
Joined: May 26 2009
Online Status: Offline
Posts: 33
|
| Posted: May 28 2009 at 15:39 | IP Logged
|
|
|
As mentioned in other postings, I am new to VBScript and Powerhome. I was wondering if folks had any tricks for debugging VBScript with Powerhome.
I use VBSEdit which creates a combined editing and debugging environment for VBScript. I wrote a powerhome object which stubs the ph. routines and allows VBSEdit to do auto completion and other basic checking for me. So I can do syntactic and gross logic checking inside a debug environment where I can set breakpoints and look at variables. Are there debugging tricks people use, in particular "live" under Powerhome?
Thanks in advance,
D
|
| Back to Top |
|
| |
spou
Newbie
Joined: July 28 2007
Location: Canada
Online Status: Offline
Posts: 33
|
| Posted: May 28 2009 at 22:15 | IP Logged
|
|
|
Hi Device
For starter, the only way to debug the kind of scripts used in PH is the same way one would debug a web script: painfully.
Joke aside, the best thing to do is to add the "msgbox" command here and there. With that instruction, you can have the place your software is (program flow) or have display a variable value.
You'll find out that scripts should be small, and well commented, because in 6 months, you wont remember why you did this or that.
Also, you'll find that in the PH realm, using the PH_*instructions are a bit though on the machine. I had a script that moved 40 values to globals, and it taxed my old duron-900 enough that I could feel a slowdown in the responsiveness of PH.
I then moved that script to a large macro, and it is way better.
So, script should really be for some small task that are more or less external to the job PH is doing. For example, I use it to check various weather conditions (from a mysql database) and try to find out if a thunderstorm is approching. I then only set single global into PH to warn me. To be honest, it's not working very well, but I can keep fiddling it without impacting PH.
hope that helps,
Spou
|
| Back to Top |
|
| |
device
Newbie
Joined: May 26 2009
Online Status: Offline
Posts: 33
|
| Posted: May 29 2009 at 17:25 | IP Logged
|
|
|
Thanks for taking the to write comment.
Generally, I've been using ph.usermessage wrappered inside a logging function instead of message box to avoid suspending the system and creating other oddities since most of my code runs off of insteon device change and manages timed events.
With respect to globals in my particular case, I generally found it a good idea to check the value of the global first and only "setglobal" if the value changed and wrote some "update" routines to wrapper the
"setglobal" with this check. Although I don't call these routines where I know the global will change (e.g. adding an offset to a datetime). These routines save clutter in the eventlog, reduce disk I/O and seem to slightly improve performance (I can process more events per second).
I am a little surprised that macros run with so much lower overhead than scripts. Since the advent of Java interpreted languages have improved dramatically, while Dave's macro language forces the user to do a lot of preparsing which simplifies the runtime work, VBScript has a distinct lexical analysis phase up front and does not need to parse each statement as executed. I don't know if its does any of the clever caching and signature varification which allows reuse of previously parsed representations of the same script. It is good to know so if I run into performance problems that I can convert back to macro. I am writing in VBScript primarily because I find it easier and more convenient.
Thanks again for the comments,
D
|
| Back to Top |
|
| |
|
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Programming
Topic: VBScript Debugging
