Add the ability to define an integer filed as an Enum.

For example on the project I am working on I have several status fields with several values.

Checked In Checked Out Pending Deleted

I don't want to create another table with a relationship for just these values. In the desiner you woudl have an option to generate integer fields as enums.

thoughts?

Bert

I would agree with this. This would also help the MySQL implementation of SET and ENUM datatypes, though would be handled very differently in other database drivers.

Why don't you use enums in your client layer and cast them to int for storing into the fields? The problem with your suggestion is that if a new value is added, the code has to be re-generated.

the code has to be re-generated

Good point. I tend to work isolated and I re-gen whenever I want. I forget that some people have to play well with others...

Otis wrote:

Why don't you use enums in your client layer and cast them to int for storing into the fields? The problem with your suggestion is that if a new value is added, the code has to be re-generated.

hehe o yeah I forget you are a C# guy

I code in both, most of the dotnetnuke stuff I do in VB. In VB the intellisense picks up the enums where C# does not

if I go to set a property value in VB that is an enum type the intellisnes will pop up the enum right away, for some resons it doesnt for C#.

As far as re-generating the code you could always edit the class file, when the code is re-generated you could set it up so the file is not overwritten.

It is an intellisense thing for me, I spell bad and I have a bad memory sometimes, I am always like what the heck is that enum again....

Bert

Bert: ok I see your point, indeed in C# you have no benefit but in VB.NET you have.

So in other words, the designer should offer an option to specify if an int32 field should be an enum and then you should be able to specify the different values for that enum? Ok, I'll add it to the todo list

Otis wrote:

So in other words, the designer should offer an option to specify if an int32 field should be an enum and then you should be able to specify the different values for that enum? Ok, I'll add it to the todo list

yes. Maybe add a new node to the tree on the left. "GeneratedEnums" When you add a new one you could define values. From here you could also assign them to multiple int32 columns.

On the Fields mapped on DB fileds form you could have a checkbox that is enabled for Int32 fieds. When set to true you could select the available Enums from a drop down list

Again not a high priority but a nice to have.

Bert

I'll do this probably when I also implement the converter logic for types (i.e. oracle char(1) field is boolean) which should work with assemblies written by the developer which are reflected and used in the designer as sources for types.

Another cool thing you coudl do once this is in the project file Is have the code gerenter add Boolean properties for each Enum Value.

Lets say your database field was called ACCESSLEVEL

And your enum was as follows

 Public Enum Access
     Edit= 1
     ReadOnly= 2
     Admin= 4
End Enum

If you defined the enum in the desgner when generating the code you would have one field mapped on the database column ACCESSLEVEL. But you would also have

HasEdit

 IF ACCESSLEVEL AND Access.Edit Then
    Return True
ELSE
    Return False
End IF

HasReadOnly

 IF ACCESSLEVEL AND Access.ReadOnlyThen
    Return True
ELSE
    Return False
End IF

HasAdmin

 IF ACCESSLEVEL AND Access.AdminThen
    Return True
ELSE
    Return False
End IF

MAybe in the designer add a checkbox called enum is a flagged enum? Just an idea bert

 IF ACCESSLEVEL AND Access.Edit Then
Return True
ELSE
Return False
End IF

is the same as:

Return (ACCESSLEVEL AND Access.Edit)

The thing I don't want is that the designer has an editor for silly lists to enter. That's too cumbersome, as the code has to be generated every time an entry is added. It's also unnecessary, as the only information the designer needs to know is that a given int32 field is an enum and of type .... .

So it would be better that the designer simply can import types from assemblies and fields can be set to those types. These types should be implemented in a separate assembly, preferably. The advantage of that is that you can just add a new entry to that type in that assembly, recompile that assembly and you're done.

Otis wrote:

 IF ACCESSLEVEL AND Access.Edit Then
Return True
ELSE
Return False
End IF

is the same as:

Return (ACCESSLEVEL AND Access.Edit)

o yeah, that is my wordy VB coming out

[quotenick="Otis"]

The thing I don't want is that the designer has an editor for silly lists to enter. That's too cumbersome, as the code has to be generated every time an entry is added. It's also unnecessary, as the only information the designer needs to know is that a given int32 field is an enum and of type .... .

true... I was just getting all excited....tehy love to use bitwise stuff in the database at my work...I was getting all excited

bert