Function issue

[jgolde00]

Hoping someone could help me figure out what I am doing wrong.

What I don't get is when this runs the first pop up box (echo) has nothing in it after the second loop goes through it will show "testing".

Could someone tell me why the first loop "f" has no data but the second loop it has the "testing" data in it?

Thanks



For i = 1 To 6

If Not i = 5 Then
call test
End If

wscript.echo f

'----Loop
Next

'----Function
Function test
f = "testing"
End Function

 

[PHV]

Add Dim f before your For loop.

Note: I strongly recommend the use of Option Explicit

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[jgolde00]

PHV,

That was exactly what was wrong, thank you so much for the help.

Jay

 

[mrmovie]

also your Function test, should be a Sub
further, for clarity i would pass the test() sub the variable you want to modify. makes it easier to follow what is going on (at the moment you are changing a variable which is out of the scope of the function/sub test)

Dim f
f= "start"

For i = 1 To 6
If Not i = 5 Then
call test(f)
End If

wscript.echo f
'----Loop
Next

'----Function
Sub test(ByRef sPassed)
sPassed = "testing"
End Sub

 

[mrmovie]

i must admit i was scratching my head for a minute ;-)
the important thing is that the first time f is used/referenced is within the Function Test(), so its scope is still within the Function Test() (i think)
so, the main part of your script doesnt have an f the first time it tries to use it, so when it calls Wscript.Echo f, f is automatically dim'd so to speak and it is a blank string.
the next time the Funciton is called it now knows to change the f in memory from the main part of the script.
PHV is right, of course

 

[jgolde00]

That helps to understand why it was doing that, Thanks again for all the help.

 

[PHV]

I insist on the use of the Option Explicit instruction on top of all your scripts...

 

[mrmovie]

I second that, if you dont use Option Explicit you are asking for all sorts of problems and hours of scratching your head over an issue with is a flippin typo.

 

[tsuji]

I think the issue here is the scope of variable rather than option explicit which is absolutely (ie unconditionally) optional for vbscript. I have not seen any example in vbs where sparing option explicit cause problem. But misusing/misconceiving scope does.

- tsuji

 

[PHV]

I have not seen any example in vbs where sparing option explicit cause problem
Variable names spelling issues are covered by this option

 

[tsuji]

PHV,

The language won't read the mind of the programmer, or should it? I won't oppose good practice. But, the opinion of this or that is divided.

- tsuji

 

[PHV]

OK, I rephrase:
Variable names unintentinal misspelling issues are covered by this option

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[tsuji]

PHV,

I can rephrase it also, but I think I need not. But if a rephrase can illuminate something I want to do.

Any script if written with option explicit provision perform as intended, then, taking it out unconditionally and without exception will result in a script of equal value in performance. To this, I do not know of any exception.

- tsuji

 

[PHV]

Ah.
Yes I agree.
Option Explicit is for design time only.

 

[tsuji]

PHV,

I know we agree all along from time zero. It's just a matter of wording. Have a good day.

- tsuji

 

[PHV]

Thank you.
My main problem is my lack of confidence in english language outside the strict technical area...

 

[dilettante]

Warning: Whiney rant ahead.

I'm not aware of any case where Option Explicit causes negative side effects, except in a poor script. A silly example:

Dim LastName

LastName = InputBox("Enter last name")
   :
{several lines of misc. logic}
   :
[COLOR=red]LastNmae[/color] = Trim(LastName)
   :
{more logic, possibly hundreds of lines or more}
   :
MsgBox LastName

If one leaves out Option Explicit, to many "programmer's" the code appears to work - yet clearly the string is never getting trimmed as desired. At some point a flaw like this will cause problems, and can be hard to track down - especially in lengthy runs of script.

If one puts in Option Explicit, the source of the trouble becomes clear quite quickly.


One of the crosses the VB/VBA/VBScript/ASP/Javascript community must bear is that this is the "low-rent district" of programming. I'm sure the Perl, etc. community has its share of these issues itself.

The fact is that the cost of entry here is rather low. In the case of VBScript for example, we get a lot of people with entry-level skills writing code, whether box admin folks or ASP authors. Everyone has to start someplace though, and it may as well be here.

I welcome these folks. But why set them on such a wrong road as suggesting they ever leave out Option Explicit?


I am completely frustrated by assisting people with VBScript who write code like my snippet above. After spending large amounts of time assisting them in tracking down a flaw of this type, they balk at my suggestion that they must use Option Explicit.

This is a much bigger headache for me in "real life" than in online forums. At least here my boss isn't standing over me, insisting that I fix Sloppy Joe's code - yet again.

Such code tends to have large numbers of these flaws. Many of these they manage to hack around, shotgunning until they more or less get the results they desire. This leaves them with things like faulty but ineffective logic. Or dead code - such as messed up logic sitting in a branch of an If that can never be taken (until one day it goes "boom!"). A common "hack fix" for the problem above looks like:

Dim LastName

LastName = InputBox("Enter last name")
   :
{several lines of misc. logic}
   :
LastNmae = Trim(LastName)
   :
{more logic}
   :
[COLOR=red]LastName = Trim(LastName) 'Sloppy Joe's "fix"[/color]
MsgBox LastName

So now he insists that Option Explicit "breaks my code" and then refuses to use it. Grr!


This is intolerable, and the suggestion that anyone ever write VBScript without Option Explicit sets my teeth on edge. If anyone can tell me how Option Explicit has any arguable drawbacks I would love to hear them. It is most certainly not "for design time" because most important code will undergo maintenance in its lifetime, and a great deal of VBScript goes through repeated phases of cut-and-try until it works "well enough." I see ASP pages that effectively never get finished, and suffer more hacking and fixing for months after being placed into production.

Code can run for weeks, and then some untested path gets executed. Bang! You just screwed up some customer's account balance - and your code chugs right along without any notification. All because of a variable name typo and no Option Explicit.

It is like working with heavy equipment or power tools without proper safety gear: gloves, safety glasses, steel-toed boots, etc. Uncomfortable? Too bad!

By the way, I don't consider avoiding the need to declare variables a legitimate argument.

 

[dilettante]

Gee, just look at all the spelling and punctuation errors I made above. ;-)

But I know I'm not the only one who makes mistakes.

 

[tsuji]

dilettante,

I see deep trauma behind the lines. But it does not change the matter of the fact. And it risks to transmit wrong message. Okay then, let dim them everywhere.

option explicit
dim i, f
For i = 1 To 6
    If Not i = 5 Then
    call test
End If
wscript.echo f
'----Loop
Next
'----Function
Function test
    dim f
    f = "testing"
End Function

Does it solve the problem. No. This show it is the scope rather than option explicit.

When we think we are at the "moral highground", we speak with the language of power like your boss at one time. But, the fact is the same : you wish vbs function that way. It is not. So it is not cool enough.

regards - tsuji

 

[dilettante]

I'm sorry if I seemed to be implying that Option Explicit will cure all ills. ;-)

Of course scope is a very important concern, and plays into things here.

mrmovie had it way up near the top of this thread. In the first iteration of the loop when test() was called there was no global f. So when f = "testing" got executed a local variable was allocated and assigned a value, and was just as quickly deallocated as execution left the scope of test().

Once the WScript.Echo f call was made though a new global f variable was allocated. Subsequent test() calls ended up assigning values to this global variable.

So tsuji I think we were all in agreement on that part.

I was simply suggesting that Option Explicit should always be used, and that if jgolde00 had been using it here this scope issue probably would never have arisen. The absurdity of declaring f both locally and globally should have made the problem stand out very clearly, and a single global declaration would have been used. If the author didn't recognize this situation, asking somebody else should have lead to the trouble's discovery quickly.

That's the essential value of using Option Explicit: you have to think about declaring variables and about variable scope. Dealing with these matters up front saves lots of debugging time later.


But I think we can all agree we have beat this topic to death now, if we don't agree on anything else.