This spring GW finally released the much anticipated WE7, betas, that holds the scripting power. GREAT! I like it, and use several of the scripts frequently, even daily. Many with me...
Many a time, when a question comes up - or even a request for some kind of functionality - we are told the same standard reply: "You can do it with a script." At one point, it crossed my mind, GW should have an automated server, that simply spit out that reply, whenever the subject line held the word request, or something. OK, that was an excergerating joke. But the answer often comes anyway. Yes, scripting is powerful,and helpful. My question, though, is how much resources does a script eat? Yep, you geeks, slow down that reply button one sec; I know, it depends on what the script has to do. Some operations naturally will take less resources, copared to more advanced ones. What I am after is, if a certain functionality - i.e redirecting a given keystroke - could be done with a single command in the source code of the software, but now it has the need of a whole script; how much resources are waisted? Even so, we see that many of the scripts, 'depends' on other scripts, like Homer and GWToolkit. This means, that first your computer will have to accept the keystroke, then run the 'redirecting' script, which tells it to run a certain part of say GWToolkit, then return to the redirecting script to see if anything else is to be done about that key - and finally, it can perform whatever it is meant to do, upon that one keystroke. Before you take next bite of your sandwich, do emember to split it apart, to realize what it contains, then take the ham to the fridge to see if it compares with the ham in the package, take it back to your sandwich, look to see if you need to do anything more before eating it, reassemble your sandwich; and take the bite... Get it? Lattely, also several users have noticed trouble with scripts loading. Personally, I think it has something to do with the Beta2; as it started to occur more or less same day as I installed Beta2. Whenever starting WE, you were left with a load of messages saying that your script had an error. You press I-gnore Error, and next script tells you IT has an error. It sure got better in a few days, as the different scripts got their updates, and particularly after downloading/installing Homer script (taht one, I didn't find any setting for to autoupdate, so had to do it all manually). It seems a bit critical to me, that scripts are so dependent on each other, that updating one, but not the other, leaves the user in trouble. Think there is two ways around it. 1) Instead of distributing one big package - GWTooolkit - each 'tool' could be its own small block of source code, that the script builder could download and implement into his script. Wel, not very smooth a solution, so let's take a look on the other one... 2) Could it be possible to have a call in all scripts, (at the beginning of the code), that checked to see if the user has the version of the BASE-script that is needed; and if not, automatically ran an autoupdate on that BASE-script? I.e, I make a script named 'startsound', which is using calls from GWToolkit. When the 'startsound' is initialized, it checks for GWToolkit v6 or later. If not found, it automatically downloads and installs it. In script manager: Could there be a checkbox which read 'autoupdate all scripts'? When checked, all scripts installed would have their autoupdate setting turned on. This would make it easier to ensure the user always has the latest version of whatever scripts he has installed. If, out of some reason, he does not want a given script to autoupdate, he could turn that one off manually, by the already existing, incividual update feature. If you reply to this message it will be delivered to the original sender only. If your reply would benefit others on the list and your message is related to GW Micro, then please consider sending your message to [email protected] so the entire list will receive it. All GW-Info messages are archived at http://www.gwmicro.com/gwinfo, and can be searched through and sorted using the search form at the bottom of the page. If you wish to unsubscribe from this list, send a message to [EMAIL PROTECTED] and include leave gw-info in the body of the message.
