Variable outside of a script

[BobSakemano]

I hate to ask this again guys but I just cant seem to be able to get it working.

I need to have 2 variables outside a script. A simple Yes or No. (1 / 0) whatever you look.

Right now I'm using the objFSO.FileExists to rename files, its pretty backwards and I'm sure there is an easier way.

Could you guys help me out with this? Give me an example I can use. This is the only thign thats keepin me from finishing my work.

I was thinking maybe its posible to have a few values in the script file itself that can be modifed? like 1's and 0's ?

 

[tsuji]

BobSakemano,

The simplest is to use msgbox function with vbYesNo button and then pickup the yes or no instruction.
[tt]
smsg="Do you want to rename this file : " & filename
nret=msgbox(smsg,vbYesNo,"Windows Script Host")
if nret=vbYes then
wscript.echo "The file will be renamed."
else
wscript.echo "The file will not be renamed."
end if
[/tt]
But I must say your question is not at all clear if those external variables outside of a script really mean. The above only applies from user-interactive.

regards - tsuji

 

[BobSakemano]

yes, I'm not using an interface. see its like this, my scripts runs as a service every hourse and it needs to remmeber some stuff. (2 simple variables or yes or not)

To be more precies, whether an email has been send or not.

Any idea?

 

[tsuji]

BobSakemano,

In that case it is just like a web page is running stateless. To communicate one with another, you have to have some intermediary, like session, cookies...

Here, you store the yes/no in a file (like a cookie), maybe together with the time it is created. Then the next time the script is triggered by the scheduler, it reads the file and validate its data (yes/no) by reading the time stamp (or some other more secure device). Equivalent, is to use special made registry key/value. But why testing that hard on the security of the system?

- tsuji

 

[tsuji]

One more method is [1] to have the script having a constant declaration. [2] Then within the script, you read itself (wscript.scriptfullname) and parse for the declaration. [3]Change the right hand side (yes/no) of the constant. [4] Save itself. Every time the script is triggered by the scheduler, it executes with that constant value set, after doing all the works, it modifies the constant for the next time to use. The advantage is this keeps all the info within the same file. The disadvantage is the script file constantly being modified, and the right to modify it has to be extended to local system account. (See, you can just keep inventing.)
- tsuji