Is it better to update the property of an object in the state? or just replace the whole object in the state?
i.e for e.g
state.theObject.property = value or
state.theObject = newObject
Related
This is a bit difficult to explain but basically:
I want to change the Color property of a class from another class: In this case, an animation class
Form1 -> Contains object "ShapeClass" -> Contains "FillColor" and
"Position" property
AnimatorClass -> Contains variable "SubjectProperty" which is the
object whose value is being changed throughout the animation. The sub
"run()" would change the value in the "ShapeClass" object
So here's how the animation works:
Dim Shape1 as ShapeClass = new ShapeClass()
Dim anim as AnimatorClass = new AnimatorClass()
anim.SubjectProperty = Shape1.Position
anim.run()
And the animation would run successfully: actually changing the Position property of the Shape1 object.
However, whenever a Drawing.Color is used as the SubjectObject, the actual value in Shape1.FillColor doesn't get changed. In all other situations, the SubjectProperty variable seems to be a reference to the actual property in the ShapeClass, and changes to SubjectProperty, go to the property it references, but this doesn't not seem to happen with the Drawing.Color class.
Could someone tell me why this is the case, and how to fix it? Thanks.
(Appologies if I explained it badly)
I have a list of objects of type say Person, and I want to export Person records to an excel-sheet (I am using a proprietary excel component for VB.NET). Using a form with checkboxes the user can specify which Person properties should be exported.
Instead of having an enormous if-then-else tree where I check to see if each checkbox (corresponding to a property) has been checked, I have a data structure where for each property in Person I keep a boolean (checked/unchecked) and the name of the property as a string. I then use two for-loops like this:
For Each p As Person In Persons
...
For Each item As ExportColumnData In ExportColumnTable
...
If item.Checked Then
...
Dim o As Object = CallByName(p, item.PropertyName, CallType.Get, Nothing)
SaveValueToExcelSheet(o)
...
End If
...
Next
...
Next
However, this is not type-safe since I am using CallByName supplying PropertyName as a string. Is there a more elegant and type-safe way I can achieve the same thing? I need some way (other than a string) to reference the properties of these Person objects.
The CallByName function uses reflection to find and execute the property getter by string name, so you are right that it is unsafe in the sense that there will be no compile-time checking done to ensure that the properties by those names actually do exist in the Person type.
Unfortunately, short of a big If/Else block, or something similar, there is no "safe" way to do this in a way which will allow for compile-time type checking. If you want it to check that at compile-time, you need to call the property by name directly in code, and if you are doing that, it will have to be in a big conditional block of some sort.
There are things you could do to minimize or shift the location of the ugliness. For instance, you could create an enumeration of all the Person properties and add a method to the Person class which returns the property value given the enumeration item using a big Select Case block. That would make the logic reusable but not really any less ugly. Not only that, but doing it that way kind of puts the type-checking responsibility on your code, not the compiler.
Alternatively, you could, for instance, set the tag of each CheckBox control to a delegate which takes a Person object and returns the correct property value for that option from the given Person object. Then, in the loop, you could just call the delegate in the tag to retrieve the value. For instance, if you had a delegate like this:
Private Delegate Function GetPersonProperty(x As Person) As Object
Then you could set the Tag of the CheckBox controls like this:
chkFullName.Tag = New GetPersonProperty(Function(x As Person) x.FullName)
chkAge.Tag = New GetPersonProperty(Function(x As Person) x.Age)
Then, in your loop, you could invoke the delegate in the Tag to get the value, like this:
Dim myDelegate As GetPersonProperty = CType(item.Tag, GetPersonProperty)
Dim value As Object = myDelegate.Invoke(p)
But that's rather overly-complicated for such a simple task.
In the end, if the compile-time type checking is really important, I'd just bite the bullet and make the big conditional block. If it's not really that important, I'd just stick with the reflection and put some decent exception handling in the code.
You say you already have a class where you store the information about the properties of your Person class. You can use this to store the PropertyInfos as well.
Here's an example:
Class Person
Public Property Name As String
Public Property Age As Integer
End Class
Class ExportProperty
Public Property [Property] As PropertyInfo
Public Property Export As Boolean
End Class
Sub Main()
'' Create a List(Of ExportProperty) from all public properties of Person
Dim properties = GetType(Person).GetProperties() _
.Select(Function(p) New ExportProperty With { .[Property] = p}) _
.ToList()
'' Say we want to export only the Age field
properties.Single(Function(p) p. [Property].Name = "Age").Export = True
'' Create a person instance to export
Dim pers = New Person With { .Name = "FooBar", .Age = 67 }
'' Only export the properties with Export = True
For Each prop in properties.Where(Function(p) p.Export)
'' Use the PropertyInfo.GetValue-method to get the value of the property
''
Console.WriteLine(prop.[Property].GetValue(pers, Nothing))
Next
End Sub
Your solution is perfectly fine, as long as the contents in ExportColumnData are correct. If these are computed dynamically at runtime, you're fine.
Otherwise, or alternatively, you can do the following: use Type.GetProperties to get a list of PropertyInfo objects. You can then use these instead of a mere String to extract property values in your loop:
Dim o As Object = item.PropertyInfo.GetValue(p, Nothing)
So in my class 'myInfo' I have an aliased property 'HeaderInfo' that is a property as a class, where it is actually the Header of a much deeper class.
Private _header As myHeader
Public Property HeaderInfo() AS myHeader
Get
Return _header
End Get
Set(ByVal value As myHeader)
_header = value
Someotherclass.Foo.Bar.AnotherThing.Header = _header
End Set
End Property
myHeader is a class with properties like 'Name', 'ID', etc. that are all strings. So when I reference this property in something like a Windows Form, I do
Dim info As New myInfo()
info.HeaderInfo.ID = "ID HERE"
info.HeaderInfo.Name = "Name here"
It works to the extent that the instance of the info.HeaderInfo is setting all its properties correctly, but
Someotherclass.Foo.Bar.AnotherThing.Header = _header
never gets set inside the myInfo.HeaderInfo 'Set', because I'm not directly setting the property, I'm setting its subproperties in assumption that it would propagate. Am I not understanding how properties with a custom type work? Is there a way to propagate this?
To make this happen automatically, you would need to alter the setter for the properties in your myHeader type, and for that to work your type instances have to know about the specific instance of your myInfo type.
Let's look at why this doesn't work they way you hoped. To do that, I'll break apart this statement:
info.HeaderInfo.ID = "ID HERE"
When that statement is executed, first the info variable must be de-referenced to get the object instance it refers to.1 When we have that object, we have to get (not set) the HeaderInfo property, so that we have a reference to the your myHeader object instance. Once we have the myHeader object, we call the setter on the ID property to complete the assignment.
Hopefully that clears up why this works the way it does. You do access the HeaderInfo property, but you only ever use the getter.
1Side note: if you ever see the "Object reference not set to instance of object" this is what it's talking about: a variable or property that you did not expect in an expression was Nothing/null.
I am looking to do a depth first searching algo using vba so i have defined an object called "node" which should contains a "parentNode".
I have tried to define parentNode as collection and use the following
Public Property Let Parent(ByRef inputNode As Node)
Set parentNode = New Collection
hasParentNode = True
parentNode.Add inputNode
End Property
Public Property Get Parent() As Node
Parent = parentNode.Item(1)
End Property
But when i call node.Parent i got Object variable or With block variable not set
i know that is due to the line "Parent = parentNode.Item(1)" what should be the proper way of doing this? I want it to return the parnetNode assigned by Ref
Thanks
Since Node is an object (I assume, I have no idea what class Node actually is), your code is missing the Set keyword:
Public Property Get Parent() As Node
Set Parent = parentNode.Item(1)
End Property
Getting Object variable or With block variable not set usually sometimes means a missing Set keyword.
I have just created several Property Set methods, and they didn't compile. When I changed them to Property Let, everything was fine.
I have since studied the documentation to find the difference between Property Set and Property Let, but must admit to being none the wiser. Is there any difference, and if so could someone offer a pointer to a proper explanation of it?
Property Set is for objects (e.g., class instances)
Property Let is for "normal" datatypes (e.g., string, boolean, long, etc.)
Property Let is more versatile than Property Set. The latter is restricted to object references only. If you have this property in a class
Private m_oPicture As StdPicture
Property Get Picture() As StdPicture
Set Picture = m_oPicture
End Property
Property Set Picture(oValue As StdPicture)
Set m_oPicture = oValue
End Property
Property Let Picture(oValue As StdPicture)
Set m_oPicture = oValue
End Property
You can call Property Set Picture with
Set oObj.Picture = Me.Picture
You can call Property Let Picture with both
Let oObj.Picture = Me.Picture
oObj.Picture = Me.Picture
Implementing Property Set is what other developers expect for properties that are object references but sometimes even Microsoft provide only Property Let for reference properties, leading to the unusual syntax oObj.Object = MyObject without Set statement. In this case using Set statement leads to compile-time or run-time error because there is no Property Set Object implemented on oObj class.
I tend to implement both Property Set and Property Let for properties of standard types -- fonts, pictures, etc -- but with different semantics. Usually on Property Let I tend to perform "deep copy", i.e. cloning the StdFont instead of just holding a reference to the original object.
Property Set is for object-like variables (ByRef) whereas Property Let is for value-like variables (ByVal)