ByRef - delayed update of the original variable?

[Tom_Slycke]

In a VB.Net class and have pointed out a discrepancy to my teacher. Can
anyone here answer this?

Very simple program used to demonstrate the "ByRef" parameter passing.

If the ByRef truly refers to the variable location, I would have expected
the textbox1.text display to update right when the value change when NAME is
set to "Samantha" but the textbox1.text field does not reflect the change
until the subroutine completes.

I tried inserting a textbox1.refresh after the NAME is set to "Samantha",
but the textbox1.text still did not change to Samantha until the subroutine
completed.

-----------------------------------------
the subroutine called by
DisplayIT( Textbox1.text )

The routine is.....

public sub DisplayIT(byref name as string)
..
message box is used to display the contents of text1box.text ( origonal
contents )
..
name = "Samantha"
..
messagebox is used to display the contents of textbox1.text (
"Samantha" )
..
end sub
------------------------------

 

[Branco Medeiros]

Tom_Slycke wrote:

Very simple program used to demonstrate the "ByRef" parameter passing.

If the ByRef truly refers to the variable location, I would have expected
the textbox1.text display to update right when the value change when NAME is
set to "Samantha" but the textbox1.text field does not reflect the change
until the subroutine completes.

<snip>

Notice that when you pass a *property* as a ByRef parameter, VB copies
the property value to a temporary variable, passes *the variable* ByRef
and assigns back the value in the variable to the property:

Sub ChangeText(ByRef Value As String)
Value = "NewValue"
End Sub

'...
'The follwoing statement:
ChangeText(TextBox1.Text)

'Is actually handled like this:
Dim Temp As String = TextBox1.Text
ChageText(Temp)
TextBox1.Text = Temp

Therefore, the behavior you observed is expected. Notice also that this
behavior was introduced by VB.Net. Previous versions of VB would also
create a temporary value for the property but wouldn't assign the value
back...

This is because a property is not a field, it's actually one or two
*methods*: a getter and a setter (read-only properties are just
getters, write-only are just setters). Properties exist so you can
access internal state of the object with the same syntax of field
access, but keeping control of how such values are processed. Compare
this to the Java language, where there aren't properties. If you want
to have control on how the fields of an object are accessed, you must
explicitly write getters and setters to each field.

HTH.

Regards,

Branco.

 

[Phill W.]

I would have expected the textbox1.text display to update right when the
value change when NAME is set to "Samantha" but the textbox1.text field
does not reflect the change until the subroutine completes.

The Control is not redrawn until Windows itself is allowed to get a look
in and redraw it, which VB actively prevents while you're debugging. If
you've ever had to write subclassing code to handle Windows-level
Messages, you'll be extrememly glad of this!

Try adding

textbox1.Refresh

after setting the Text property, which forces VB to let Windows have a
turn.

HTH,
Phill W.