provider.GetFieldInfo(entityName, entityFieldName)

If the entityFieldName is a field mapped on related field, this throws an exception.

System.ArgumentException was unhandled
  Message="The field 'State' isn't known in the element 'InvoiceEntity'\r\nParameter name: elementFieldName"
  Source="SD.LLBLGen.Pro.ORMSupportClasses.NET20"
  ParamName="elementFieldName"

I want to filter a EntityView2 on the value of a mapped field, but need this to build the predicate expression.

You should do: new FieldCompareValuePredicate(new EntityProperty(entityFieldName), null, ...)

You should do: new FieldCompareValuePredicate(new EntityProperty(entityFieldName), null, ...)

How does it know which entity it belongs to?

My code

EntityProperty entityProperty = new EntityProperty(dc.Caption);
IPredicate pred = null;
switch(entityProperty.DataType.Name) {
                case "String":
                  pred = new FieldLikePredicate(entityProperty, null, dc.FilterText);
...         

creates different predicates depending on the type of the field.

The entityProperty doesn't seem to know what type it is at this point. i.e. it's datatype is null.

How does it know which entity it belongs to?

I think it does not, this is determined in the EntityView Please check the Documentation manual "EntityView and EntityView2 classes -> Filtering and sorting on any property in an entity"

It uses reflection to grab a propertydescriptor of the property it represents, then reads the value of that property and uses that value in the predicate interpretation.

If you would pass an EntityField2 object, the predicate would use the field's value in the predicate interpretation.

So you could use this EntityProperty class also to simply filter on fields of an entity (or for example only new entities by filtering IsNew)

It uses reflection to grab a propertydescriptor of the property it represents, then reads the value of that property and uses that value in the predicate interpretation.

If you would pass an EntityField2 object, the predicate would use the field's value in the predicate interpretation.

My point is that

new EntityProperty(entityFieldName)

doesn't provide any information about the field name thats been generated.

if the mapped field was returned from the EntityFieldFactory call

new EntityFieldFactory("EntityName","EntityFieldName")

, I could determine more about the field such as it's datatype which can control the type of predicate expression I need to build to filter on a field.

i.e. like doesn't make sense on int's, = false only makes sense on bools, etc.

With the call

new EntityProperty(entityFieldName)

, I don't see any binding to the entity itself, so that if I have properties on 2 different types of entities that have the same name this call returns the same object for each, doesn't it.

arschr wrote:

It uses reflection to grab a propertydescriptor of the property it represents, then reads the value of that property and uses that value in the predicate interpretation.

If you would pass an EntityField2 object, the predicate would use the field's value in the predicate interpretation.

My point is that

new EntityProperty(entityFieldName)

doesn't provide any information about the field name thats been generated.

if the mapped field was returned from the EntityFieldFactory call

new EntityFieldFactory("EntityName","EntityFieldName")

, I could determine more about the field such as it's datatype which can control the type of predicate expression I need to build to filter on a field.

i.e. like doesn't make sense on int's, = false only makes sense on bools, etc.

Ok, though it was my understanding that the value to compare with was specified in a textbox?

Anyway, the interpretation of a predicate is done as follows: The entity is passed to the predicate expression to interpret. It should return true or false. If you create a FieldCompareValuePredicate using new EntityProperty or using a field, it doesn't matter, the object used (field or entityproperty) gets the entity and returns the value represented by that object (field or entityproperty). That value is then compared with the value specified, using a string compare, as dataview does too, in the case of Equal. All other operators use a general comparer object which compares the values based on the operator specified.

Thus, IMHO, you can just specify the value you want to compare with and the property you want to compare and that's it.

With the call

new EntityProperty(entityFieldName)

, I don't see any binding to the entity itself, so that if I have properties on 2 different types of entities that have the same name this call returns the same object for each, doesn't it.

That's ok, as the entityproperty gets the entity passed in and returns the value for the property it represents (if present, otherwise null). In-memory filtering is about: you have a filter and you apply it to an entity. So the interpretation logic works with a given entity and it doesn't need binding to an entity, it will resolve the values at runtime.

Obviously, using a Customer.CompanyName field on an orderentity won't result in a value.

Ok, though it was my understanding that the value to compare with was specified in a textbox?

It is. I'm looking for additional information (like the columns data type) to help me understand what the text represents. i.e. is "false" a string or a bool, is "2006-05-21" a datetime or a string, is "205" a number or a string etc.

Thus, IMHO, you can just specify the value you want to compare with and the property you want to compare and that's it.

I think I need to know more in order to decide what kind of compare to do. like, =, between, <= etc.

If the text value is 2.35 and the column type is a decimal, I can do an =, if it is a float I have to do a between; If the column is a datetime and the value is "2/15/2006" I have to ignore the time part of the datetime and do an = or do a between a range, and so on.

That's ok, as the entityproperty gets the entity passed in and returns the value for the property it represents (if present, otherwise null). In-memory filtering is about: you have a filter and you apply it to an entity. So the interpretation logic works with a given entity and it doesn't need binding to an entity, it will resolve the values at runtime.

Same comment as above. I guess, I can try to build my own mapping of entity+fieldname to a object that hold's meta-data about it.

The filtering of the view is just an example of needing to know more (at runtime) about the entity or the entity fields. maybe extended proprties are a possibility.

I see your point. Though what about this: entityType is the Type of the entity to filter. For example the type of the first instance in the current entityview.

PropertyDescriptorCollection properties= TypeDescriptor.GetProperties(entityType);

Then, you just do: PropertyDescriptor descriptor = properties[propertyName];

and then you can determine the type, by using descriptor.PropertyType