Delegate pointing at a property[Resolved]

Just a quick Q. How do I setup a delegate to point at a property. I am getting syntax errors when I try these methods:

-expects sub or function, if either are put in it says property is not a valid identifier.

VB Code:

Public Delegate property delgGrabBalance() As Double

-says the signature is incorrect.

VB Code:

Public Delegate Function delgGrabBalance() As Double

This is the property:

VB Code:

Public Property Balance() As Double
        Get
            Return mBalance
        End Get
        Set(ByVal Value As Double)
            mBalance = Value
        End Set
    End Property

Thanks for any help!

Delegates are for subs or functions.. as the error the IDE gives you says...

why do you need a delegate for the property?

I have objects that compose other objects. For example I have an Order object that contains Item objects(no inheritance involved). There are time when I need to acces information from an objects container, for example if I need the Order's date in the Item object. I am trying to avoid making the values shared in a public module as this would mean redundant data. If there was a way I could just point to the order object's property functions with a public delegate I could get the values from the object itself. I am also trying to avoid having the parent object pass an instance of itself. Now if I could pass a pointer to the parent object....

well do you only need to read values from the parent object? if so maybe you can create a function to return the value instead of a property, and then possibly a delegate would work?

Well that is how I have been doing it, i just wanted to know if there was a way to make my life easier and use properties. Oh well. While I have you let me run my concept by you, I could use some experienced input. Like I said I will have a parent object and I will want certain aspects of that parent to be available to other objects it contains without redundantly storing the data. Could I make a module that contains delegates pointing to the parent objects properties and then the objects contained in the parent can all get the values they need by invoking the public delegates? Make any sense?

I can't wait until I know enough so I can answer other peoples questions and be almighty too :bigyello:

I would suggest using Interfaces, it will give you a defined structure but without the requirement of inheritance. If the object(s) in question may not be of a known type or fit the required structure then you can just check it for the interface and do something else if not implemented - like through an exception. If it does implement the interface then it can polymorph to the Interface and you can access all the parts you need. This also breaks any reliance on specifc property names or scope.

Quote:

---

Originally Posted by Edneeis

I would suggest using Interfaces, it will give you a defined structure but without the requirement of inheritance. If the object(s) in question may not be of a known type or fit the required structure then you can just check it for the interface and do something else if not implemented - like through an exception. If it does implement the interface then it can polymorph to the Interface and you can access all the parts you need. This also breaks any reliance on specifc property names or scope.

---

Edneeis, you may need to break that down for him a little
;)

I have read about interfaces but have never actually put them into practise. I was not sure if that was what I needed but I will try and do some research on how to implement interfaces tonight. For the most part I understand how they work but am not sure how one object can implement the interface of a specific instance of the object it is implementing. Any useful samples/tutorials on the net for creating a simple interface would be helpful. Maybe I will finally check out those 101 vb .net samples ;)

I started to make an Interface example but then I re-read your posts to see what you are doing. What does this mean?
"I am also trying to avoid having the parent object pass an instance of itself. Now if I could pass a pointer to the parent object...."
Or maybe the proper question is why? Why would you want to avoid passing an instance? What is the difference between a pointer to the object and a reference to it (which is what actually gets passed)?

It sounds that that would be the proper way to solve this issue. Or to simply access the item via the order so you have references to both.

Delegates would have still made you have a reference to an instance method. It really doesn't sound like ou need interfaces or inheritance but maybe I just missed something.

Can you explain further how the objects (Order and Item) are connected and what you are trying to accomplish?

Ok let me give you a specific example. BTW thanks a million for the help!

Lets take my Item object that I am working with. within the item object I have a few other object, such as an object that holds date information (multiple dates can be held for each object on an order) and in each date object I have a locations object (multiple locations can be assigned to each date for where the item is going). Now the top level object, my Item object, contains the dates object which conatins a collection of date objects. in turn each date object containg a locations object which in turn contains a collection of location objects. My problem is this. There are some properties that the Item object has that I need available to all these objects that are contained in it. For example a given Item has a conversion rate that all of these objects need to figure out their quantities. Whereas all the objects have their own quantity variables, because a given location or date can have a different quantity, they should all have the same conversion rate based on the item. This is the type of property I need to cascade down through all my objects. If you need something clarified please tell me.

Another question, say after all this you decide that passing a refrence to the parent object is the way to go. Even though I am passing a refrence, when I Dim an object to set it to the passed refrence is it not taking up the same space that the original object does? or does it just take up the amount of memory a pointer uses?

Thanks again!

Technically a pointer and a reference are the same thing, at least for the purposes of this discussion. Any reference to a ReferenceType object does not create a copy of the object but just stores a reference/pointer to the original space in memory where the object is. This is not true of ValueType objects which are mainly just the basic types (Integer, Decimal, Date) and structures.

Now let me make sure I have the object heirarchy straight.

You have an Order object, Item object, DateInfo object, and a Location object. The Order contains a collection of Item objects. The Item object contains a collection of DateInfo objects. The DateInfo object contains a collection of Location objects.

Order
-ItemCollection
--Item
---DateInfoCollection
----DateInfo
-----LocationCollection
------Location

Can you show me some pseudo code of what you are trying to accomplish or how you need to use it? It seems like any conversion or figuring should be done from within the Item object if it has the data needed. Or cascading the instance via a Parent type of property that the children can reach.

You have the heiarchy exactly right. Let me give you some simple pseudo code illustrating what I am trying to accomplish.

VB Code:

Class Item
'itemdates object
objDates as ItemDates
'the items conversion rate
ConvRate as double
public property ConversionRate() as double
....
end class
''''''''''''''''''''''''''''''''''''''
Class ItemDates
'collection of ItemDate objects
colDates as collection
....
end class
'''''''''''''''''''''''''''''''
Class ItemDate
'ItemLocations object
objItemLocations as itemlocations
.....
end class
''''''''''''''''''''''''''''''''''''''
Class ItemLocations
'collection of Itemlocation objects
colLocations as collection
....
end class
'''''''''''''''''''''''''''''''
Class ItemLocation
'that locations quantity
Quantity as double
public property Quantity as double
'I need acces here to the item's conversion 
'rate to properly return any quantity of given item.
 
'currently this object has its own conversionRate variable that 
'is updated every time the item that contains it's conversionRate is 
'updated so that it will always reflect the item's current rate.
.....
end class

So that is how the objects are setup. I was thinking about restructuring the objects with use of inheritance, this happens to be an application that is being ported over from VB 6.0, using the Item as the base object and then adding date/location information as I inherit up the heiarchy. Not so sure how it would work with collections but I am pretty sure it can be designed.

Quick point about the valueType/refrenceType issue, if refrences are made the way we were discussing, passing parent refrences, wouldn't that involve boxing which inturn involves allocating memory for the object? Thanks Edneeis!

To be honest I don't understand boxing but no new memory is allocated when a reference is passed because you are really just passing a reference to the original memory location.

I still am not clear on how the Quantity and ConversionRate thing works. Actually can you give pseudo code on that?

Something like:

VB Code:

Dim qty as Integer=MyOrder.Items.Quantity
Dim rate as Decimal=MyOrder.Items.GetConversionRate()

Ok basically only the item object has a conversion rate. So it would be more like(in the location object) :

VB Code:

Dim rate as Double=MyOrder.Items(MyItem).GetConversionRate()

The conversion rate designates how the user want to convert the quantity, for example. Right now I have 100 screws in my inventory, but the conv. rate is %10 (.10) because 10 screws make up a package and I only sell packages of screws. If my packages begin to be sold as 20 screws per package I would need to change my conversion rate so that the new quantity would display properly. Every quantity for every item is displayed like so:

VB Code:

Public readonly property GetQuantity() as double
  return quantity * conversionRate
end property

So as you can see, while an item has one conversion rate that applies to all of its quantities, It can have different objects with their own quantities. so:

VB Code:

Dim qty as Integer=MyOrder.Items.Quantity

is not true because the quantity of a given location has nothing to do with the item itself. That quantity is specific to the location object that is contained in the item, and represents the amount of that item being sold from a certain location. When I want to display given quantity, however, I do need to know the item's conversion rate so it displays in the proper way. e.g. if I have 100 screws in the quantity variable at this location I need the conversionRate of .10 to display the correct quantity of 10.

*Pheew* I hope that helped!

Since the Quantity is married to the Conversion rate I would require that you pass in an Item or Conversion rate to evaluate it against.

VB Code:

Dim qty as double=Location.GetQuantity(MyOrder.Item(1))

That is how I would do it or you link the parent/child relationship via the collection or items so that they always can reach the Item if it owns the Location.

VB Code:

'in the locations collection
Public Function Add(item As Location) As Integer
    item.Parent=Me
    return MyBase.Add(item)
End Function
 
'link back to the collection's parent
Public Sub New(parent As Item)
    Me.Parent=parent
End Sub

The first way is more free and would allow you to get Quantities without forming a complete structure of objects. The second way is the opposite and forces the heirarchy of the objects - which may or may not be a good thing depending on what you want.

With the 1st way you could do things more 'on the fly' like this if needed:

VB Code:

Dim it As New Item
it.ConversionRate=.1
Dim loc1 As New Location
loc1.Quantity=10
Dim loc2 As New Location
loc2.Quantity=20
Msgbox(loc1.GetQuantity(it).ToString())
Msgbox(loc2.GetQuantity(it).ToString())

Notice how there is no ownership but the function can still operate properly. You could just as easily mix and match the item part as well.

Now you may want or need for the full structure to be enforced in which case something like the 2nd way may be better:

VB Code:

Dim it As New Item
it.ConversionRate=.1
Dim loc As New Location
loc.Quantity=10
it.Locations.Add(loc)
loc = New Location
loc.Quantity=20
it.Locations.Add(loc)
Msgbox(it.Locations(0).GetQuantity.ToString())
Msgbox(it.Locations(1).GetQuantity.ToString())

Sorry it took me a while to get back to you, I hope it helps.

Don't worry about, no rush =P We are just taking our time trying to decide how to redesign our app for .net once we start moving it from 6.0. The first idea of passing the parameter would be the normal way to go but in our case we want things automated in the objects, so when a person calls the getQuantity function in the location the object already knows what to do. After all the correct structure is already there, it just has to find a way to get to it. The second example is more or less what we do now, passing the structure down the line.

We have actually been experimenting with something new and I am pretty confident it will work great! We are going to try to keep the entire top-layer class in one XMLDocument and get rid of all of it's private variables. A delegate will be pointing towards the active item's xml and all of the objects it contains will just have a variable telling it which part of the item's xml heirarchy it is. That way it also has access to all the properties of the item itself, such as the conversion rate, plus it has all of it's information by processing it's structure contained in the item XML! I think it is a great idea and we are testing it out now. What do you think? And thanks for all your help again =)

I don't understand the benefit of the XML thing but as long as it works its good. Remember that constantly reading an xml file will be slower than accessing a private member. I personally would stick with the more conventional manner of doing things but I'm sure whatever you choose will work out.

That is the one drawback and it wil def. create some lag but just think of having an object already in xml. saving it to the database, transfering it via the web, making a dtd.. so many doors open up. Hopefully the benefits will outweigh the costs. Thanks again!

Well any serializable object can be transferred back and forth to/from XML in about 2 lines of code.