How to pass a ADO object as a parameter to a function?
-
I defined a function like this: func(byref x as ADODB.Connection) then i : Dim conn as New ADODB.Connection afterwards i: func(conn) but when i compiled it, i met a error. How to write correctly?thanks much X|
What does the error say? what about the error code? Notorious SMC
The difference between the almost-right word & the right word is a really large matter - it's the difference between the lightning bug and the Lightning Mark Twain
Get your facts first, and then you can distort them as much as you please Mark Twain -
What does the error say? what about the error code? Notorious SMC
The difference between the almost-right word & the right word is a really large matter - it's the difference between the lightning bug and the Lightning Mark Twain
Get your facts first, and then you can distort them as much as you please Mark Twain -
Try this:-
call func(conn)orfunc connNotorious SMC
The difference between the almost-right word & the right word is a really large matter - it's the difference between the lightning bug and the Lightning Mark Twain
Get your facts first, and then you can distort them as much as you please Mark Twain -
Try this:-
call func(conn)orfunc connNotorious SMC
The difference between the almost-right word & the right word is a really large matter - it's the difference between the lightning bug and the Lightning Mark Twain
Get your facts first, and then you can distort them as much as you please Mark Twain -
But do you understand WHY this worked? I think that is more important. Using parens in VB mandates that your function RETURN something. For example:
Public Function AddNumbers(numOne As Integer, numTwo As Integer) As Ineteger
Dim retVal as Integer
retVal = numOne + numTwo
AddNumbers = retVal
End Function
This function would be called like so:
Dim answer As Integer
answer = AddNumbers(1, 2)
If you have a Subroutine they generally don't return anything. This is afterall the main difference between a Function and a Subroutine. Functions do soemthing AND return something. Given a Subroutine as such:
Public Sub DisplaySomething(something As String)
Debug.Print something
End SubBecause this does not return anything it has to be called one of the following ways:
DisplaySomething "Hello World."
-or-
Call DisplaySomething("Hello World.")
This is one of the reasons that alot of people don't like VB. They feel confused by needing to rememebr if they have to use parens or not. Generally speaking i think that using the
Callkeyword is bad form though. Simply don't use parens and all is fine.
Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things."
-
But do you understand WHY this worked? I think that is more important. Using parens in VB mandates that your function RETURN something. For example:
Public Function AddNumbers(numOne As Integer, numTwo As Integer) As Ineteger
Dim retVal as Integer
retVal = numOne + numTwo
AddNumbers = retVal
End Function
This function would be called like so:
Dim answer As Integer
answer = AddNumbers(1, 2)
If you have a Subroutine they generally don't return anything. This is afterall the main difference between a Function and a Subroutine. Functions do soemthing AND return something. Given a Subroutine as such:
Public Sub DisplaySomething(something As String)
Debug.Print something
End SubBecause this does not return anything it has to be called one of the following ways:
DisplaySomething "Hello World."
-or-
Call DisplaySomething("Hello World.")
This is one of the reasons that alot of people don't like VB. They feel confused by needing to rememebr if they have to use parens or not. Generally speaking i think that using the
Callkeyword is bad form though. Simply don't use parens and all is fine.
Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things."
Ray Cassick wrote: rememebr if they have to use parens or not. Tell me about it ! ;) And for someone like me who alternates between .net and vb6, it can get even more confusing! Thank god for .net's intellisense. I just don't bother with parens at all. :) Notorious SMC
The difference between the almost-right word & the right word is a really large matter - it's the difference between the lightning bug and the Lightning Mark Twain
Get your facts first, and then you can distort them as much as you please Mark Twain -
But do you understand WHY this worked? I think that is more important. Using parens in VB mandates that your function RETURN something. For example:
Public Function AddNumbers(numOne As Integer, numTwo As Integer) As Ineteger
Dim retVal as Integer
retVal = numOne + numTwo
AddNumbers = retVal
End Function
This function would be called like so:
Dim answer As Integer
answer = AddNumbers(1, 2)
If you have a Subroutine they generally don't return anything. This is afterall the main difference between a Function and a Subroutine. Functions do soemthing AND return something. Given a Subroutine as such:
Public Sub DisplaySomething(something As String)
Debug.Print something
End SubBecause this does not return anything it has to be called one of the following ways:
DisplaySomething "Hello World."
-or-
Call DisplaySomething("Hello World.")
This is one of the reasons that alot of people don't like VB. They feel confused by needing to rememebr if they have to use parens or not. Generally speaking i think that using the
Callkeyword is bad form though. Simply don't use parens and all is fine.
Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things."
Ray Cassick wrote: Generally speaking i think that using the Call keyword is bad form though. Simply don't use parens and all is fine. Really, humm, I prefer to use the parens because, I like to make it more blatently obvious that I am calling a function ( the keyword "call" helps with that blatentness) With default functions sometimes it is not immeadly obvious what one was thinking when they wrote their code.