This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I want to expose certain properties as an enum rather than their underlying type. However, when using the designer the code generator doesn't preserve my getter/setter code. It resets it to working with the underlying type. Is it possible to preserve modificatons in the generated class? Thanks.
|
|
|
No, you can't preserve modifications in the generated class -- we regenerate the entire file whenever the model changes. What you need to do instead is put your custom code in a partial class declaration. Probably the best thing to do in your example is to set the enum property's Data Type to Int32 and its Generation property as None. This tells the designer not to generate any code for this property (but the property still participates in database synchronisation). Then create a partial class declararation and implement the property there as an enum: partial class Customer { There's some extensibility work we're hoping to do as part of v3 which should allow the use of custom types in the designer, which will hopefully make this workaround unnecessary. |
|
|
Hadn't picked up on the Generate option. This is a straightforward solution. Thanks |
|
|
Hi Ivan, How would you go about this same sort og task if the property is a primary key on one table and a foreign key on the other, since the properties grid is not available as the columns involved are not shown in the entity ? Would you need to set the relationship Generate property to none and then add similar code as well as the relationship code in your partial class ? |
|
|
I think that setting the association Generation to None and implementing it by hand using an enum type would work. I haven't tested it though so it is possible LightSpeed might be confused when it tried to match a foreign key value of enum type to a primary key value of integer type: I think the CLR would handle this for us but I could be wrong so do a quick test first if you want to do something of this kind. (Don't forget you'll need to hand code both ends of the association.) Having said that, I would have significant reservations about a design in which a foreign key was expressed as an enum. This would mean that your code is not only coupled to your schema, which is to be expected, but to the contents of your database! If you decide you want to add a new value to the reference table, you would have to add a new enum value and recompile your code. This somewhat defeats the point of using a reference table to externalise the info in the first place. I'm not saying this is unprecedented or that such a design is always wrong -- just that modelling a FK as an enum rather than a plain integer value is something one should probably not do as a matter of routine, even for "it will never change" reference tables. If the dependency on the FK value is so great that it really does affect the code -- e.g. because the objects behave differently depending on the value -- then using single table inheritance, subclasses discriminated on the FK value and virtual methods may be better than modelling the association as an enum and writing switch statements on the enum value. It will still leave a dependency of the code on the database contents, but the dependency will be more explicit and the resulting code better structured. Just some food for thought anyway... |
|
|
It is a reference table, and all I wanted was to check if the Id selected was a specific number in one validation. The screen is a data import form and I am in the process of creating a business object to bind to the screen. I can then put the validation of the screen in the object and not have it in the UI code (where it currently is).You select an ImportType (sales,products,Stock on hand) and a couple of dates and then it goes off and does that function. If the download type is 'Sales' and the date range includes the current date, then it shouldn't be allowed until the end of the close of business. It would be better as you say to have a subclass of ImportType that is SalesImportType and check that rather than the ImportTypeID. |
|
|
I found that I had to set the Generation property to FieldOnly in order for the field definition to be created. Using None resulted in nothing at all being generated in the class. Other than that your suggestion worked fine. Thanks |
|