Our current classes have enumerated properties that we change to integers when storing. The LLBLGen classes generated these as integers. Is there a way that these fields can be generated to use the enumerated types, so we dont have to cast the enums when we set the fields?

enum PriorityType { Low, Normal, High }
class.Priority = (int)PriorityType.Normal;
would like
class.Priority = PriorityType.Normal;

If not, what I would like to see is that on certain field types like Int or Char the ability to create a list of valid values in the designer with the Enumerated Name.

In the customer section of 1.0.2005.1 and 3rd Party there is a Enum Task Performer. Take a look at this and see if it would do what you need.

Description: This Taskperformer allows the user to generate a enum code file that is based on the contents of lookup tables in the database.

We do not store our enum types in a Lookup Table, they do not change and if they did we have to build the project again anyway. I would like to just setup a set of enums in the Designer somehow and set the .Net type of the property to that Type.

I am v2 and I have not been able to get the TaskPerformer to generate the code. The Performer also does not appear to change the Type of the property, so I would still need to cast it.

*This seems to give no benefit because you would have to regenerate the code if that table changed?

Hi

The following article might be of help. Its an alternative and personally I feel a perhaps simpler method of addressing the problem that you have.

http://www.codeproject.com/useritems/DotNetEnumsNextLevel.asp

Hope it help, but feel free to come back if it is not appropiate.

Maybe you could look at the type converter mechanism, which you can use from inside the designer. That would require that you build your own converter inheriting from

System.ComponentModel.TypeConverter

Another solution maybe to add a property from your enum type in your entity class within the one of the custom user code regions (to prevent overriding on next generation) and to build a custom projector to the same class which hydrate your custom property. (

SD.LLBLGen.Pro.ORMSupportClasses.DataProjectorToCustomClass<T>

)

The first solution maybe easier; in either case, you might have to give a look at the SupportClasses source code for a precise direction.

Thanks for the information. Currently there is not time to implemented these changes. I will need to revisit this in the future.

Maybe this could be addressed in an update somehow, else I will have to revisit this later.