Greetings!

I there a way to easily bind parent table attribute to listbox or datagrid?

for example listbox.datasource = entitycoll; listbox.valuemeber = "entityID"; listbox.displaymember = "parententity.attr";

thanks for any help,

gof Zagreb, Croatia

No, you have to add a custom property mapped onto that field for that. This can be not that efficient, so typed lists are more efficient for this purpose. With the upcoming updates (now in beta), you can solve the disadvantage of getting query per child object with prefetch paths.

Otis wrote:

No, you have to add a custom property mapped onto that field for that. This can be not that efficient, so typed lists are more efficient for this purpose. With the upcoming updates (now in beta), you can solve the disadvantage of getting query per child object with prefetch paths.

I tried something with custom properties but with no results. If I define custom property for an entity and manualy set the custom property (for example: attribute from parent entity) how do I bind that property?

In for example OrderEntity (in the two-class scenario), add a property CustomerName which returns this.Customer.CompanyName. That's it. you then bind to CustomerName, as that's the property in Order.

Otis wrote:

In for example OrderEntity (in the two-class scenario), add a property CustomerName which returns this.Customer.CompanyName. That's it. you then bind to CustomerName, as that's the property in Order.

You mean add a readonly property to OrderEntity.cs in Custom User Code? I suppose it would survive a regenerate

Hm, if I understand correctly this has nothing to do with Custom properties tab in LLBLGen Pro or?

gof wrote:

Otis wrote:

In for example OrderEntity (in the two-class scenario), add a property CustomerName which returns this.Customer.CompanyName. That's it. you then bind to CustomerName, as that's the property in Order.

You mean add a readonly property to OrderEntity.cs in Custom User Code? I suppose it would survive a regenerate

yes, that's why there is the two-class scenario Add the property to the derived class 'OrderEntity' and the OrderEntityBase.cs is overwritten, not the derived class. (Use the Full/Safe config). You can also add a custom include template to add the code to the entity, which is even more safe.

Hm, if I understand correctly this has nothing to do with Custom properties tab in LLBLGen Pro or?

No, Custom Properties are name-value pairs you can use for code generation purposes or at runtime to for example read the text for a label which has to be positioned next to a field of an entity in a form.

Otis wrote:

gof wrote:

Otis wrote:

In for example OrderEntity (in the two-class scenario), add a property CustomerName which returns this.Customer.CompanyName. That's it. you then bind to CustomerName, as that's the property in Order.

You mean add a readonly property to OrderEntity.cs in Custom User Code? I suppose it would survive a regenerate

yes, that's why there is the two-class scenario Add the property to the derived class 'OrderEntity' and the OrderEntityBase.cs is overwritten, not the derived class. (Use the Full/Safe config). You can also add a custom include template to add the code to the entity, which is even more safe.

Hm, if I understand correctly this has nothing to do with Custom properties tab in LLBLGen Pro or?

No, Custom Properties are name-value pairs you can use for code generation purposes or at runtime to for example read the text for a label which has to be positioned next to a field of an entity in a form.

OK. I was confused for a while, but now I get it thanks

Hi, the new version you are speaking of is v2.0.0.0, I suppose? Then I've got a question. I'm using v2 and i wanted to bind a listbox in the described way:

listbox.datasource = entitycoll; listbox.valuemeber = "entityID"; listbox.displaymember = "parententity.attr";

First i tried lazy loading and a prefetch path, which should work by using the syntax above, if I understand your posts correctly. But display member expects a string, how could it perform lazy loading?

I found a solution in adding a "field mapped on related fields" in the designer, so I don't have a problem I just want to understand and know if i missed a cutting edge feature

Hi,

Binding members such as DisplayMember and ValueMamber have to be properties from the base class, which prevents using "ParentEntity.attr" or any Property's Property. If you want to bind such members, you can either create a dedicated property in your base class that does provide the access, or handle the binding event in a custom method where you feed the controls with the specific properties in code behind.