[RESOLVED] Looking for the right explanation re: Call Statement
Hi Guys .. googled it but cant find exactly .. maybe someone has a hidden MS link. .. basically when using the CALL statement and passing a control such as a form or textbox you need to use Call mySub(me) or mySub me .. but cant use mySub (me) .. somnething to do with default properites of the control being allocated to memory ... any ideas.. just want an exact explanation to make some sense of it .. particularly Form related .. thanks ..
Rory
Re: Looking for the right explanation re: Call Statement
If you use Call then you need to realize that you can call a sub and it can call a function.
Depending on which you call you will need the parenthesis or not.
To call a Sub you can use either...
Call mySub(something)
or
mySub something
Then to call a function...
Call myFunction(something)
or
Text1.Text = myFunction(something)
You can not use parenthesis without returning the results to some variable or property or something that will hold the value. If your using parenthesis then it expects being assigned to something or being called with the Call statement.
I dont know what kind of explanation your wanting but hopefully I covered it. :)
Re: Looking for the right explanation re: Call Statement
The codes
Call MySub(me) and MySub me - both are equivalent. You are trying to call a function or procedure and ignoring the return value.
If you want return value from the function, then you should use the following line of code
x = Mysub(me).
If you use the parenthesis, you mean that you are going to use the return value. so it must be assigned to some variable.
Re: Looking for the right explanation re: Call Statement
nope didnt do it :D
Ok only on subs right now .. i know about functions and return values, just trying to clear up the issue with Controls and Subs and when using Parenthesis ..
i know i can do this ..
call mySub("Test")
mySub ("Test")
Dim str
str = "Test"
mySub (str)
but here is the part ..
Call mySub(Me) <-- OK
mySub Me <-- OK
mySub (Me) <-- ERROR
something to do with default properties of controls right .. and already being allocated to memory ..? I know what I can do and cant do, just want to know why is all .. I know .. its not "that" important .. but i just like to know why things work or dont work ... google didnt work :bigyello:
Thanks
Rory
Re: Looking for the right explanation re: Call Statement
The syntax Sub (Argument)
Means, pass the argument ByVal. You would use this syntax if the procedure has declared its arguments ByRef but you don't want the procedure to update the argument.
VB Code:
Private Sub SquareIt(ByRef X as long)
X = X * X
End Sub
Private Sub Command1_Click()
Dim Y as Long
Y = 2
SquareIt Y
Debug.Print Y 'Prints 4
Y = 2
SquareIt (Y)
Debug.Print Y 'Prints 2
End Sub
Objects (Forms/Control/Class instances) themselves do not have a Value, so VB uses the value of the Object's default property and passes that to the procedure.
Re: Looking for the right explanation re: Call Statement
I noticed that...
I have a procedure in one module, and another procedure in another. When i call a second one, if i use Call parametres must be in (). If i don't use Call, parametres must be withouth (), otherwise syntax error occures, expected =.
Re: Looking for the right explanation re: Call Statement
Quote:
Originally Posted by brucevde
Objects (Forms/Control/Class instances) themselves do not have a Value, so VB uses the value of the Object's default property and passes that to the procedure.
ok we might be getting somewhere ;)
remember i know how to use subs and functions, i just want to see if anyone knows, in simple terms, why the same as can be done with values, cant be done with controls/objects .. i take it is a memory allocation and the default property but looking for a simple answer .. specifically this is related to Forms, in this case.
thanks for answering so far though .. coming from a Vbscript world never had to think of this .. but now i cant get it off my mind :-)
This is probably more important than i think actually, after all what is used more than Form Load or Sub Main other than Calling a Sub in VB6.0 .. ;-)
Rory
Re: Looking for the right explanation re: Call Statement
i think it's something like this in java :)
Re: Looking for the right explanation re: Call Statement
Quote:
Originally Posted by gavio
i think it's something like this in java :)
just instead of this ..
Call mTray.Refresh(Me)
or this ..
mTray.Refresh Me
Id prefer to do this ...
mTray.Refresh (Me)
but i cant .. so id like to know WHY ohh Why .. :bigyello:
... waits eagerly for bush, hack, moer, merri, or robdog to save the day .. :thumb:
Re: Looking for the right explanation re: Call Statement
The use of the Call statement is used to ignore a return from a function.
You can the Call Statement on a Subroutine but you cannot have the parenthesis. Parenthisis indicates a Function. This will be a conflict since subs do not return values in the same way as functions.
Re: Looking for the right explanation re: Call Statement
i think you won't sleep today
Re: Looking for the right explanation re: Call Statement
Quote:
Originally Posted by rory
just instead of this ..
Call mTray.Refresh(Me)
or this ..
mTray.Refresh Me
Id prefer to do this ...
mTray.Refresh (Me)
but i cant .. so id like to know WHY ohh Why .. :bigyello:
... waits eagerly for bush, hack, moer, merri, or robdog to save the day .. :thumb:
You can't pass a form by value. What's the value of Me?
Re: Looking for the right explanation re: Call Statement
Quote:
Originally Posted by Al42
You can't pass a form by value. What's the value of Me?
Me is Me .. whatever form it is in ..
the other methods i posted work, but this doesnt ..
mTray.Refresh (Me)
doesnt seem like anyone else has an explanation either .. oh well .. time to move on .. guess will leave it as just knowing it can only be done a certain way due to allocated memory for the control's default property value. :wave:
Re: Looking for the right explanation re: Call Statement
You miss the point. Me has no value, so you can't pass it by value, which is what mTray.Refresh (Me) is doing. You can probably pass Me.Width (or any similar value), but not Me.
Let's invent a term and say that you can't pass a valuless object by value.
Re: Looking for the right explanation re: Call Statement
Quote:
Originally Posted by Al42
You miss the point. Me has no value, so you can't pass it by value, which is what mTray.Refresh (Me) is doing. You can probably pass Me.Width (or any similar value), but not Me.
Let's invent a term and say that you can't pass a valuless object by value.
ok .. but these work ..
Call mTray.Refresh(Me)
mTray.Refresh Me
Re: Looking for the right explanation re: Call Statement
You're missing the point. If you call a sub you can either use the Call keyword and then pass the parameter list (that is all arguments) inside paranthesis, or you can skip the paranthesis and the Call keyword.
However when one single argument is inside paranthesis it is passed by value instead of the default by reference, as explained above. However Me is an object or rather a reference variable for an object. You want to pass an object ByRef since it is a reference. If you pass it ByVal VB would need to create a copy of the object and pass that to the Sub, which VB can't do for a Form.
Re: Looking for the right explanation re: Call Statement
Ok i get your point now that it should be passed as ref not val, and now i understand why :-) , however you say it doesnt work with a form if passed as val but when you do this it works .. in this case is it just bypassing the sub's ByVal and using byRef? Thanks..
VB Code:
Private Sub Command1_Click()
Test Me
End Sub
Private Sub Test(ByVal frm As Form)
Debug.Print frm.Width
End Sub
Re: Looking for the right explanation re: Call Statement
The difference is that you specifically state that the Form should be passed ByVal. An object reference is simply a memory address so this means you will pass the memory address by value. That is not the same thing as telling VB to create a copy of an object and put that on the stack, when you call the sub.
Re: Looking for the right explanation re: Call Statement
Got it thanks .. good enough for me .. :thumb:
[now i can sleep]
Re: [RESOLVED] Looking for the right explanation re: Call Statement
If you want another explanation (just in case you want to stay up a while longer) here it is:
You can specify in the declaration of a sub or a function if an argument should be passed ByVal or ByRef (the latter is the default). However a ByRef specification can be overwritten by the call by specifying that the argument should be made ByVal instead. All arguments are pushed to the stack by the call and later popped by the Sub/Function. Now when ByVal is used a copy of the data is created so the Sub/Function can't change the origional value. So if the Sub/Function has specified that an argument is ByVal it's up to the procedure to make the copy before it is popped from the stack. If however the call specify that the argument is ByVal it's up to the caller to first create the copy before it pushes the argument on the stack.
When an object is passed ByVal it still is a reference the only difference is that the reference can't be changed. Just create a new project and add a second Form to it (the project now contains two Forms, Form1 and Form2). Add the following code to Form1 to see how this works. Play around with the code and change the ByVal to ByRef to see the difference.
VB Code:
Private Sub Form_Load()
Dim frm As Form
Set frm = Form1
Debug.Print frm.Caption '<-Shows the caption of Form1
MySub frm
'The above call will change the reference to Form2...
'... or will it?
Debug.Print frm.Caption '<- Which caption will be shown here?
'Unload Form2 which is loaded by MySub so you can end the application
Unload Form2
End Sub
Private Sub MySub(ByVal frm As Form)
Debug.Print frm.Caption '<-shows the caption of Form1
Set frm = Form2 '<- Change the reference to point to another Form
Debug.Print frm.Caption '<- shows the caption of Form2
End Sub