Quick question - is the fields index of an entity case sensitive?

e.g. is myEntitiy.Fields["fieldname"] the same as myEntitiy.Fields["FIELDNAME"]?

Yes. It uses a hashtable. The value used is the field name as specified in the LLBLGen Pro designer. (or myEntity.Fields[index].Name )

Bugger! I was hoping you would say no

It's not a problem at the moment but i just know that it will be a problem eventually. At some points in my app i have to access the fields by name based on values elsewhere in the app. I don't neccessarily have control over the "elsewhere" as the values could be set by an external app. I can pretty much guarantee that 99% of the time the values will be correct, but...

Are the fields added to the hashtable somewhere that i can change it, say for example so they're all added in uppercase? Will that cause problems elsewhere?

netclectic wrote:

Bugger! I was hoping you would say no It's not a problem at the moment but i just know that it will be a problem eventually. At some points in my app i have to access the fields by name based on values elsewhere in the app. I don't neccessarily have control over the "elsewhere" as the values could be set by an external app. I can pretty much guarantee that 99% of the time the values will be correct, but...

Are the fields added to the hashtable somewhere that i can change it, say for example so they're all added in uppercase? Will that cause problems elsewhere?

I'm afraid not.

It's an internal object in the Fields object. The name indexer is just there for conveniance.

Hi,

is that still valid in LLBLGen 2.0.07?

I mean: is a myEntity.Fields["fieldname"] still the same as myEntity.Fields["FIELDNAME"] or myEntity.Fields["fieldName"]?

I'm currently trying to create a sortfilter for which I have the sort field as a string value only:

string myField = "cus_LastName";
customer_Entity() customer = new customer_Entity();
IEntityField sortFld = customer.Fields[myField];
ISortExpression sorter = new SortExpression(new SortClause(sortFld, SortOperator.Ascending));
customer_Collection customers = new customer_Collection();
customers.GetMulti(null,0,sorter);

This code fails on the last line, because "cus_LastName" wasn' t found. However, if I set myField="Cus_Lastname" (so, starting with a capital C), it works.

Unfortunately all my database fields start with a lowercase, and LLBLGen always seems to set the first letter in UpperCase. Is there no way to generate without touching entitynames, fieldnames etc. at all?

Thanks for any help!

Use the following LLBLGen Pro project properties:

1- EnforcePascalCasingAlways When set to true, the setting MakeElementNamePascalCasing is always enforced. When set to false, the setting MakeElementNamePascalCasing is enforced only when names for new elements are created. Default is true. A new project inherits this value from the preferences.

2- MakeElementNamePascalCasing When set to true, all names of new entities, entity fields, typed views etc. will be properly PasCal cased. This means that each character in the name is lowercased, except the first character after each word boundary ('_' or ' ') and the first character. All spaces are always removed. When set to false, the name is left untouched, except for the first character, which will always be UpperCase. A new project inherits this value from the preferences.

Refer to Project Properties -> Name construction specific settings section under "Designer -> Preferences and Project properties" in the LLBLGen Pro manual.

Hello Walaa,

thanks (again) for your help. And sorry to mention that I already figured otu about these two settings. But unfortunately - and as you write - what ever I do: the first character will always be UpperCase. That is exactly my problem, because all my names are starting with a character in LowerCase.

Hope there is a workaround? Or any other way to get reference to a IEntityField?

Thanks for more ideas! Ingmar

I found the following thread, which was discussing the same issue: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=1750

So no chance...I guess I have to rename all my fields... Thanks anyways, Walaa

It's often better to use the fieldindex enums. So instead of: IEntityField sortFld = customer.Fields[myField];

do

IEntityField sortFld = customer.Fields[(int)CustomerFieldIndex.LastName];

because this is compile time checked and will give you a compile error when the name isn't known instead of an error at runtime.

Thanks for your suggestion, Otis.

But how shall that work if I have the corresponding field name as <string> only? E.g. as a result of the standard grids GridViewSortEventArgs e (e.SortExpression is of type string).

That's indeed a problem, then you have to use the string. You could do some value lookup with System.Enum and its static methods though.

The thing is that there could be 2 fields which differ in casing only, and this could be valid code for C# for example, so we allow it, which means that the fieldname has to be case sensitive as it doesn't know in which language it is used.

Oh yes, right, understood.

But it would help if the generator would provide a feature for creating names by really not touching them at all. Not even the first character. But I guess there might be more important features, so, it's just a tip.

Anyway thanks again for your answer!

The first character will always be upper case as it has to follow the MS guidelines for properties.

How the rest of the field looks like is configurable.