Modify Object by reference

[TechGnome]

mmmmmmm..... I think some thing was over looked here....
There is a difference in class fields, vs class properties...

Class fields:

Public Class Test
  Public SomeName as String
  Public Age as Integer
End Class

Are treated as value types....

While a property:

Public Class Test
  Public Property SomeName as String
  Public Property Age as Integer
End Class

(yes, I realized I use the VB10 syntax there, sue me, point still applies)
Get treated as reference types and are part of the object.

The difference in this distinction causes the rules to change when they are passed around. And has a lot to do with where they get stored (heap vs stack).

Gremlins - I don't buy that (at least no with out references (no pun intended)) ... granted it's been sometime since i've been out of th VB6 game... but if memory serves (and it could be faulty, I will grant that) ... that's NOT the experience I remember and I did a LOT of work with system that was heavy on the DLLs.

WOF - you SHOULD be able to pass an object's property by ref to be modified... but it has to be a PROPERTY... not a field... they are not interchangeable... in your first post, you show them as fields... not properties.

-tg

[GremlinSA]

you SHOULD be able to pass an object's property by ref to be modified... but it has to be a PROPERTY... not a field... they are not interchangeable... in your first post, you show them as fields... not properties.

-tg

Do you have VB6 installed ???

Try it...

It will not change a byref property, no matter how you try...

I'll look for a few online references, problem is that anything VB6 is not so easy to find anymore...

[WoF]

Right, Gremlin. A property canNOT be modified byref, neither if it was declared a public field, nor a property get/let pair.
Alas, a thing like "Public Property Somename as String" does not exist in VB6, TechGnome.

I mean, I would have expected that a property, being actually a pair of routines to receive or give back a value, cannot be modified byref, being no actual memory location.
But a public field should be, or so I had expected.

I think this is because of the policy, or better: the way how value passing in VB6 objects is done at all. If you have a get/let pair, it is obvious that there is no actual memory location for that property, because it might even be assembled or computed within the get routine. So the result is stored somewhere in a temporary field. That is like a ByVal parameter passed to a function.
So I think the interface is always doing this. It creates a temporary field where it puts the result of the property-get. In case there is only a public variable it results in putting the contents of this var into the accessible temp field. The user will find n0 difference in using the resulting value, but it NEVER ever allows byref modification.