LLBLGenPro 3.1 Final February 7th, 2011 LLBLGenPro Runtime Framework

L.S.,

I'm using LLBLGenPro 3.1 Final February 7th, 2011, the LLBLGenPro Runtime Framework.

I'm working with a mix of TDL and Lpt C# templates to generate parts of a WCF framework (VS2008, C#), based on/inspired by the examples provided. I have assigned custom properties to my entities, to be used in the code generation. My Questions described at the bottom of this message, some intro follows noe; In TDL in can use custom properties like:

<[Foreach CustomProperty Entity]> <[If StringValueEquals CustomPropertyName "GenerateService"]> <[If StringValueEquals CustomPropertyValue "Full"]> <# executeSomeOtherTemplate #> <[EndIf]> <[EndIf]> <[NextForeach]>

In some cases I had to write C# LPT templates which are called from my TDL templates; the beginning of these LPT templates looks like below with getting the current entity from a Hashtable:

<% // Create the WCF operation Project currentProject = _executingGenerator.ProjectDefinition; EntityDefinition currentEntity = ((Hashtable) _activeObject)["CurrentEntity"] as EntityDefinition; %> // Generated C# code for the <%=currentEntity.Name%>

That all works fine, my Question is: How can I access the CustomProperties of the entity at focus (currentEntity) in an LPT template (like i was able to do in my TDL templates), do you have any examples available?

Thanks

Jan

I thought there was a CustomProperties (hashtable) property inside the EntityDefinition. currentEntity.CustomProperties

I can't see this collection on my currentEntity (should be between CreateSourceLocationDataObject & DeserializeFromReader), how should I access these properties, do you have an example ?

I've tried something like this: CustomProperties currentCustomProperties = ((Hashtable) _activeObject)["CustomProperties"] as CustomProperties;

Your should be able to use

entity.OutputSettingValues.CustomProperties

Matt

Hi Matt,

thanks, that works within my LPT templates, for example:

Dictionary<string, string> customProperties = relatedEntity.OutputSettingValues.CustomProperties; string relatedDescription = customProperties["GenerateService"];

The above solves my originally reported problem in the LPT templates.

However, looking at the documentation for the Runtime Framework version: 3.1 (LLBLGen Pro Runtime Framework v3.1.chm), one can find in the section "Using the Generated Code", "Custom Properties" some examples like:

Dictionary<string, string> customProperties = myEntity.CustomPropertiesOfType; string GenerateService = customProperties["GenerateService"];

The error reported after compiling the generated code:

'SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.CustomPropertiesOfType' is inaccessible due to its protection level; The property or indexer 'SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.CustomPropertiesOfType' cannot be used in this context because the get accessor is inaccessible.

So I'm not able to use it in the generated code (which I'm not after right now), that section in the documentation seems to be incorrect/not working as presented, or am overlooking/wrongly assuming something here?

Anyway, thanks

Jan

Error in the docs.

Should have been: Dictionary<string, string> customProperties = ((IEntity2)myEntity).CustomPropertiesOfType;

as the property is now implemented explicitly through the interface, to lower the amount of exposed members directly on the entity class.

Thanks,

all problems solved; the code compiles and works:

Dictionary<string, string> customPropertiesType = ((IEntity2)myEntity).CustomPropertiesOfType; string generateService = customPropertiesType["GenerateService"]; bool isCodeList = customPropertiesType["GenerateService"] == "CodeList";

Another way to control code generation is perhaps with settings, in a .frameworksettings file. See the SDK docs about defining your own settings file which setting definitions are editable inside the designer, and the values are readable from an .lpt template, so you can control code generation from settings instead of custom properties.

Using custom properties at runtime is of course a different use case, and you then need custom properties