I have run into this error message again, and this time cannot find the root of it.  I have spent countless hours trying to track it down, and now need a little bit of guidance if possible.

I have gotten this before, and it has always been a case of two inherited BOs having the same cutom property and having to move that custom property up to the base BO.  Or it has been a case of wrongly accessing the base BO property or inherited BO property at a level it shouldn't be.  Well, I can't see that's the case with my current situation.

I have it narrowed down to the following recreation:
- There are two BOs, BO2 which inherits from the base BO1.
- I have form1 which only houses a BO2 instance.
- I have from2 which only houses a grid that connects to a BBS which uses BO1 as its source.
- If I open form1, then open form2, the from loads and the grid populates but as soon as I go off that form or do anything else, I get the "object does not match target type" error.

Now, I have searched for any commonly named properties. I have actually commented out every custom property at the base level (BO1) and still get the problem. I only have two custom properties on BO2, which are only accessed through BO2. 

So my question is basically this:  is there any other circumstance in which this error may occur that hasn't already been covered in this ticket?  I've lost a few days on this error and now just have no idea of where to go with it.  Please offer any help you can, it will be much appreciated.  Thanks!!

That was exactly what I was trying to relay but I apparently did not get the point across.  In all of the examples that I gave you I used BO2 and BO2, but the same thing comes into play if the BaseBO ever references this field outside of a strong-typed property and then through a strong-typed property on any downstream call.  So you ultimately got the problem fixed, but it was just in a different object that my examples were stating.

As for this being resolved in 1.6.6, I was referrring to the template having this logic within it.  But the exact same problem would occur if you setup the same scenario.  We could re-evaluate every custom property, on every BO, on every reference...but this would drastically impact performance (in a negative way) as the custom properties only need to be evaluated once.  The problem comes (and this is standard .NET) when inheritance comes into play.  Because through reflection, we have an inherited BO that has a custom property (i.e. MyField) which gets evaluated properly.  But if the BO in which it is inherited ever references this field even through a CurrentRow reference, the BO will have an issue the moment the second BO is brought up as it will try to evaluate that custom property incorrectly (or rather .NET will through reflection).  So by placing the custom property on the lowest common denominator BO that will ever access that property, it will resolve the problem.

I have resolved this issue, but wanted to post my explanation for future reference.  Either this is a different issue than what you explained or I didnt fully understand what you were telling me the issue was.  I think I most likely didnt understand it correctly.  Either way, I'm not sure why the upgrade did not resolve it.

Basically I have BaseBO with ChildBO1 and ChildBO2 both inheriting from BaseBO.  ChildBO1 and ChildBO2 both have custom properties named the same thing, and accessing the same field in the data table.  This is creating the issue.  So if I have a custom property in BOTH child BOs like this :

Public ReadOnly Property MyFieldName() as String
  Get
    Return Me.CurrentRow("MyFieldName")
  End Get
End Property

It should really be moved up to the BaseBO as a property there.  I changed it to prevent error if the query doesnt return this custom field:

Public ReadOnly Property MyFieldName() as String
  Get
    If Me.CurrentDataTable.Columns.Contains("MyFieldName") Then
      Return Me.CurrentRow("MyFieldName")
    Else 
      Return ""
    End If
  End Get
End Property

So moving the custom property declaration the child BOs had in common to the base level corrected the issue and allowed me to access it at the child level without error.  However, when I did the upgrade and changed my reports to use custom BBS objects I created, the issue remained.  I thought this was addressed in 1.6.6? 

I went ahead and did the upgrade, but have not been able to correct the issue.  I created a Custom Binding Source for each of the BOs that were inheriting from the same base and being used as a report data source.  I then changed the report to use those binding sources as the data sources.  I am still getting the same error.  Any ideas?   I am going to try to reproduce this in a small project as well...

No, that is not really what I am saying.

In the above example let's assume that BO2 inherits BO1.  If I reference a field in the BO1 like shown and then the inherited BO referneces the same field name through a strong-typed property, it would produce the reflection issue.  The same problem would occur if the roles were reversed as well.  So in this case, if the strong-typed property were moved from the BO2 to BO1 it would resolve the error because BO2 inherits from BO1 and each BO will re-evaluate the MyField property, thus eliminating the reflection contention.

I'm really not sure I understand what you said.  Are you saying that if I create a property MyField in my inherited BO which is returning Me.CurrentRow.Item("MyField") that it could be causing the problem?  I am doing this, but I guess I don't know if that's what you are saying is causing the problem.  If so, wouldn't moving those properties up to the Base BO defeat the purpose of inheriting anyway?

If you have the same field that gets used in the child and then you have a strong-typed property on the inherited class you could have this happen.  For example, if I use a MyBo.CurrentRow,Item("MyField") and then on the inherited BO I have a strong-typed property for "MyField" it would cause this.  In this case you would want to move the strong-typed property up the food-chain to the main BO.  This would happen even if you are pulling these fields from a BBS (grid) or a ListView on the parent BO.  So check this....but the good news it should be one or the other.

I actually already have this logic in all of my inherited BOs.  Is it possible that there is something else I need to do?

Yes, the logic is the same. Just place this code in all of the inherited BOs :

This will override the descriptors evaluation property and then each inherited BO will ensure to re-evaluate itself preventing the error.  The new Custom BBS was created and designed specifically for this purpose (creating reporting objects and/or a single object based model), so you will definitely want to look at this when you load 1.6.6.

Great!  Thanks for the help....glad there is a fix. 

I do have a question though...is there a workaround at all if I don't upgrade to 1.6.6?  We are on the verge of doing a release in the next couple of weeks and are always leary of doing an upgrade of our 3rd party controls late in a release cycle.  We had planned to do the 1.6.6 upgrade at the beginning of the next release cycle so it could be adequately tested with the rest of the software.  Any ideas?