Hello,

I'm curious if there's a way to ignore/disable to generation of properties that I'm enhancing in a partial class? I want LLBLGen to still think the property is there just not generate the property for it.

For instance, LLBLGen auto generates a "LineItemEntity" object, I would like to enhance certain properties like "LineTotal" in a separate partial class. Currently, every time I regenerate my project I have to go and remove/comment out the properties in the newly generated file.

Problem is I'm rarely making changes to the enhanced files, but having to regerate the entire thing causes these problems. Is there a way to exclude regenerating certain files (but still have them as part of the project)?

Am I doing this completely wrong? Is there an easier way? Can someone point me in the right direction... the more and more I enhance the more of a PIA this becomes.

Using LLBLGen Pro v 2.6 Final, with Self Service templates.

Thanks!

If the entity has a LineTotal field and you want to keep it, but at the same time you want to extend it, why don't you create another property to hold the custom code e.g. LineTotalEx.

And the leave the original as is.

Well, I was avoiding that because wrapping it requires a duplicate property and throw my own property changed events. But I guess it will be less work in the long run anyways.

I'll use that method for the time being unless there's a better way.

Would it be hard/possible to customize the Entity Template to check for the existence of a custom property? I.e "DoNotGenerate" = "Id, Name, blah" or something similar?

Thanks for the assistance Walaa.

So in other words, you want the fields to be there, but you don't want the getter/setters for the fields to be generated? At the moment that's not possible, or you've to update the template with an <[If ]> statement which checks on the presence of a custom proprty name/value pair you defined on the field in the designer for example. That's kind of awkward to do, I admit.

In v3 we have a much more flexible system with settings we can define outside the designer, which are then settable inside the designer and which values we can use in the generated code. I'll add a request for a setting to switch off property generation for fields, so you can define that in the designer with a simple checkbox.

Otis wrote:

So in other words, you want the fields to be there, but you don't want the getter/setters for the fields to be generated? At the moment that's not possible, or you've to update the template with an <[If ]> statement which checks on the presence of a custom proprty name/value pair you defined on the field in the designer for example. That's kind of awkward to do, I admit.

In v3 we have a much more flexible system with settings we can define outside the designer, which are then settable inside the designer and which values we can use in the generated code. I'll add a request for a setting to switch off property generation for fields, so you can define that in the designer with a simple checkbox.

Yes, that's precisely what I would like to do... omit the generation of the getter/setters in the future (because I've already copied the original generated properties to a new partial class... and plan to extend those)

I'm really looking forward to v3, hopefully that you get the chance to implement that feature, it definitely would come in handy for me. If not, wrapper properties would be more manageable if you could change the visibility of the properties. Will version 3 allow for control over the visibility of the properties (public/protected/private)?

I.e. Define properties you plan on extending as protected and make the extended wrapper property public so that it's the only one property (the one people should be using) is exposed instead of 2, which makes it more confusing.

Either way, I think I'll just press on with Walaa's recommendation until v3 comes out. Thanks again.

Acad wrote:

Otis wrote:

So in other words, you want the fields to be there, but you don't want the getter/setters for the fields to be generated? At the moment that's not possible, or you've to update the template with an <[If ]> statement which checks on the presence of a custom proprty name/value pair you defined on the field in the designer for example. That's kind of awkward to do, I admit.

In v3 we have a much more flexible system with settings we can define outside the designer, which are then settable inside the designer and which values we can use in the generated code. I'll add a request for a setting to switch off property generation for fields, so you can define that in the designer with a simple checkbox.

Yes, that's precisely what I would like to do... omit the generation of the getter/setters in the future (because I've already copied the original generated properties to a new partial class... and plan to extend those)

This would mean 'private' getters/setters and you add the public ones e.g. through a different property or through methods oriented towards the domain for example.

I'm really looking forward to v3, hopefully that you get the chance to implement that feature, it definitely would come in handy for me. If not, wrapper properties would be more manageable if you could change the visibility of the properties. Will version 3 allow for control over the visibility of the properties (public/protected/private)?

The feature is really easy to add actually, and as it was already planned for the other frameworks we will support it's not hard to add this to llblgen pro's own framework