Passing varibles using "Byref"

[Peter]

I will excute the code below to get MethodName array. These codes are
edited under VS2003. Now I want to upgrade it to VS2005,but VS2005 gives me
a varning message: The varible "sSourceMethodName" may throw a Null
reference exception because it passes using "Byref" before being assigned.

Although it's just a warning I still want to let ift fit the VS2005's
recommended mode.

Any suggestions will be appreciated,

Peter

'------------------------------------------
Dim sSourceSampleName() As String
Dim Count as integer
Count = GetMethodName( sSourceMethodName)

Public Function GetMethodName( ByRef sMethodName() As String) As Integer
Dim odr As OleDbDataReader
Dim i, j As Integer

j = GetMethodCount() 'Defined in other places
ReDim sMethodName(j - 1)

Dim oCmd As New OleDbCommand

'Connection ConnImport has been opened
With oCmd
.Connection = ConnImport
.CommandType = CommandType.StoredProcedure
.CommandText = "udpGetMethodName"
End With

odr = oCmd.ExecuteReader
Do While odr.Read()
sMethodName(i) = odr(0)
i += 1
Loop

If Not odr.IsClosed Then odr.Close()
Return j

End Function
'--------------------------------------------------------------

 

[Cor Ligthert [MVP]]

Peter,

Get rid of that fixed array and use an arraylist, than you can pass byval
and your program becomes direct more efficient as well.

Cor

 

[Peter]

Thanks for your reply, Cor,

I will try to use arraylist to get rid of that fixed array problem.
But I also want to get the return values by calling a function. I used
"Byref" because the function can change the "Byref" parameter just like a
return value. Can I still use "Byref" under VS2005?

Peter

 

[Tom Leylan]

Peter:

I think you'll find the use of the array has little to do with it. You
should use a collection class, it's just easier but the problem is that you
don't need to declare the parameter as ByRef. I just replied to another
message along the same lines. An array "is" a reference, you pass it ByVal.
When the value gets to the function it is a reference to the array.

You _can_ pass it by reference but you open it up to be completely swapped
out. Create a new array in your function and assign that one to the ByRef
variable and you will see you destroyed the original one.

Picture what is happening in the computer when you pass variables to
functions. They are placed onto the "stack" if you had a 20,000 element
array would we imagine it would push 20,000 values onto the stack? It
always pushes a single value that acts as a pointer to where the array is.

Don't worry about keywords like ByRef... conceptually languages always have
the option to pass values or references, it isn't something they can
eliminate in VS2005 or even VS2009.

Tom

 

[Cor Ligthert [MVP]]

Tom,

There is a redim in Peter's code, in my idea that is creating a complete new
array at a new point. I am not sure if you can than pass by value and get it
back on the same position. My idea was not.

Therefore my answer was as it was.

Cor

 

[dgk]

Thanks for your reply, Cor,

I will try to use arraylist to get rid of that fixed array problem.
But I also want to get the return values by calling a function. I used
"Byref" because the function can change the "Byref" parameter just like a
return value. Can I still use "Byref" under VS2005?

Peter

ByVal often does allow the object's properties to be changed (value
type vs reference type objects). Simple things like integers and
strings are value types and a copy is actually made and passed to the
function so changes to them are indeed lost. But most things, and I'm
not sure about the arraylist that Cor suggested, can be changed within
a subroutine or function and persist when the sub exits.

Try it yourself. Create a simple object with a text property and pass
it either byval or byref to a subroutine and have that sub change the
property. When it gets back to the calling program, it won't matter
how you passed it, the property is still changed. Try it again, but
this time have the sub set the parameter to a new instance of the
object. That will make a difference.

 

[Tom Leylan]

Ah yes the redim might be a problem. Might be interesting to find out (I'm
not likely to redim an array) so I won't do it however Clearly he would
be better of with a dynamic array.

It seems as I look the code over again that the return value "j" is just the
value of GetMethodCount() which likely could be called before
GetMethodName() and in that way the count wouldn't have to be returned, the
array could be resized prior to calling GetMethodName() and if it was zero
the call to GetMethodName() could be skipped entirely.

Tom

 

[Tom Leylan]

Well I just tried it and as we knew it would it failed when the array is
passed by value. Thank goodness Clearly redimming the array creates a
new reference and the calling routine never gets it (unless it was returned
expressly of course).

The ArrayList is doubtlessly the better option.

 

[Peter]

I read all your advice several times and understand I can use a object as a
parameter , pass it to a subroutine then change it and returne to the caller
no matter Byval or Byref.

I should separate GetMethodCount from GetMethodName.

I will create an arraylist object instead of an array.

Thanks for all of you, I think here is a warm family and I love this family,

Peter