Hello,

we want to update LLBL Geg from Version 2.6 to 5.9. We have some self-written plugins, which I should update. Unfortunately, the original developer is no longer available and I am the new guy who is supposed to do it now.

Currently I am on a problem in which fields are searched for whose target name deviates from expectations.

In the old version this was implemented as follows (yes the fieldname is terible):

var fields = entity.Fields.ToList();
const string idTargetName = "_ID";
const string idFieldName = "_Id";
var idField = fields.FirstOrDefault(ef =>
                                        idTargetName.Equals(ef.TargetName)
                                        && !idFieldName.Equals(ef.FieldName));

In LLBL Gen 5.9 there are no TargetName and FieldName propertys of the FieldElement. I think I can use the Name property instead of FieldName but how cann ich access the TargetName?

regards relevart

Since v3 the 'target' is no longer inside the entity, but is separately in a mapping for the entity per database. there are a couple of tools which are helpful here:

• the project inspector plugin (Right click the project node in project explorer -> Plugins -> Project inspector). The project inspector gives you an object graph that's available to you in a plugin, so you can check which properties to read/enumerate.
• the set of .lpt templates we ship with the designer, as they access the same object model .
• the element search pane. It gives you a direct way to consume a project as a plugin would, so you could test it immediately. It also has basic intellisense for the first level so you can discover a bit of the methods available to you.

Of course also the reference manual is helpful: https://www.llblgen.com/Documentation/5.9/ReferenceManuals/Designer/html/70919A6F.htm

In your case you likely want to call the project.GetAllMappingsForGroupableModelElement() method, by passing in the entity instance. You'll get a list of GroupableModelElementMapping instances back, one for each target for the entity (so 1 per database in the project).

These mappings live in the Project.MappingData object, so you can examine their layout live in the project inspector plugin. In a groupablemodelelementmapping instance the objects you likely want to look at are the FieldMapping instances in the FieldMappings. The field can be a field in a valuetype, so it's not as straightforward as in v2.6, but it's easy to figure out (and if you don't use valuetype definitions in the entity model, you can just look at the MappedFieldInstance property (entity field) and the MappedTarget property (table field)

Thank you Otis,

this helped a lot.

By creating a new Plugin (to avoid all the other problematic code parts) I was able to follow your clues and solve the described problem.

Otis wrote:

• the element search pane. It gives you a direct way to consume a project as a plugin would, so you could test it immediately. It also has basic intellisense for the first level so you can discover a bit of the methods available to you.

Is this the Search pane at the top of the Llbl Project explorer?

Otis wrote:

Of course also the reference manual is helpful: https://www.llblgen.com/Documentation/5.9/ReferenceManuals/Designer/html/70919A6F.htm

Yes it is but I often have the problem, that a datatype was changed or renamed and in this cases it is not so easy for me to find the needed article. In my special case a List woud be helpful that tells me thinks like "EntityRelationType" has become "EntityRelationshipType" or that "EntityRelation" can be replaced with "IRelationshipEdge" (if this ist true) and where the "RelationStartName" property has gone .

But of cause this cases are much to specific to cover then in a general Document and so I have to research case by case.

I thank you again for helping me in this one and for the clues to make my researches more successfull, relevart

there's sadly not a list to compile for this, as we rewrote the entire thing in v3.0, so the object model is completely different from v2.

Another thing you might want to look into (but, it's likely not going to be easy, sorry) is the migration template to generate a v5 project from a v2 project in v2.6. It is a template that works on the v2 project file to export an xml file for v5+. The code is meant to produce XML but you could see relationships between v2 properties/classes and the v5 xml counterparts which are often named closely to the object model properties so you get an idea how things relate.

Hello,

Otis wrote:

Another thing you might want to look into (but, it's likely not going to be easy, sorry) is the migration template to generate a v5 project from a v2 project in v2.6. It is a template that works on the v2 project file to export an xml file for v5+. The code is meant to produce XML but you could see relationships between v2 properties/classes and the v5 xml counterparts which are often named closely to the object model properties so you get an idea how things relate.

This sounds like a good idea. I used the migration template to convert our template projectfiles. Just to be shure, we are talking about the proces defined in the file "v5ProjectFile.lpt"? It look likes many thigs will happen in that file.

Thank you again, relevart

yeah that one it's a complex beast that is merely written to get the process done so it's not a brilliant piece of engineering but gets the job done. It might allow you to search for things tho, so it's another helper for getting the info you might need