Hi there

I just discovered that I cannot easily bind to my m:1 entities as they are being compiled with the [Browsable(false)] attribute. I've searched the forum a bit and it appears that Frans applied the attribute in order to simplify databinding. I'd rather have the freedom and manually hide the column in my grids, but I understand that this is nothing that can be easily reverted. (However, doesn't this make it very hard for everybody to create writeable grids if you can only work with the FKs that practically wipe out entity relations when being assigned through controls?)

However, this is going to be a major problem with WPF, where practically everything is about direct binding to objects. Here is only one of several issues I'm having right now: A _SignalEntity _with an m:1 relation to a _DataTypeEntity _- a pretty typical situation. In WPF, all you need is a simple binding expression, and you're glued up (e.g. to have a dropdown list that displays the data type for your signal. However, due to the Browsable flag, I'll have to apply a hack in either my entity (likely) or UI code.

I think we should be able to control the Browsable-attribute through the designer. The current solution is taking a lot of flexibility out of my hands, and it makes simple things very tedious.

Thanks for your consideration Philipp

I think Frans had answered the same question here: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11622

Jim wrote:

It would be helpful to me if I could suppress the generation of this attribute in the designer. Currently, I am reduced to manually commenting it out after each regeneration of the DAL. Any thoughts? Thanks Jim

Frans wrote:

It's not possible at the moment. We're considering it for v3. Till then, please make a copy of the entity template and remove the attributes, then create a templatebinding with that templatefile and the templateid for the entity classes you're using (either selfservicing or adapter) and place that templatebindings file above the general one on tab 2 of the generator config dialog. You'll then generate code with your custom template.

If time permits we'll add a small change to the designer in v2.6 for this to switch it on/off. V3 is too far away to make this feasable.

Otis wrote:

If time permits we'll add a small change to the designer in v2.6 for this to switch it on/off. V3 is too far away to make this feasable.

Would be great! I'll go with a browsable dummy property for now...

public DataTypeEntity BrowsableDataType
{
  get { return DataType; }
  set
  {
    DataType = value;
    OnPropertyChanged("BrowsableDataType");
  }
}

Another side note: I used a derived class to overwrite my property with a browsable one, but noticed that my UI didn't work properly. It turned out that setting the property on the base class does not fire a _PropertyChanged _event for the property, only for the numerical _UnitId _property which is automatically adjusted when assigning a _Unit _entity - is this a desired behaviour?

/// <summary>
/// A browsable convenience property that provides direct
/// access to the parent unit entity for UI controls
/// (the base class property is not browsable).
/// //TODO May become obsolete with LLBLGen 2.6
/// </summary>
[Browsable(true)]
public override UnitEntity Unit
{
  get { return base.Unit; }
  set
  {
    base.Unit = value;

    //the base class does not fire an event for this property!
    OnPropertyChanged("Unit");
  }
}

Refering to the last posts of the the following thread, this has been filed as a change request that maybe implemented in the next version: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11622

Walaa wrote:

Refering to the last posts of the the following thread, this has been filed as a change request that maybe implemented in the next version: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11622

btw: The proplem does not only affect fields, but also the IsDirty and IsNew flags. They are not only not browsable, but also don't fire PropertyChange events. It would have been very nice to display a status icon based on these values, but it looks like I'm going to have to overwrite everything from scratch because of these (artificial) limitations...

Cheers, Philipp

philipp wrote:

Walaa wrote:

Refering to the last posts of the the following thread, this has been filed as a change request that maybe implemented in the next version: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11622

btw: The proplem does not only affect fields, but also the IsDirty and IsNew flags. They are not only not browsable, but also don't fire PropertyChange events. It would have been very nice to display a status icon based on these values, but it looks like I'm going to have to overwrite everything from scratch because of these (artificial) limitations...

Cheers, Philipp

IsDirty and IsNew don't raise propertychanged events, though changing an entity does raise the EntityContentsChanged event. Changing a property will make the entity dirty. So: - set the initial state of your icon to the value if IsNew + IsDirty - when propertychanged is raised, alter the icon to the one which signals IsDirty=true.

Frans,

Otis wrote:

IsDirty and IsNew don't raise propertychanged events, though changing an entity does raise the EntityContentsChanged event. Changing a property will make the entity dirty. So: - set the initial state of your icon to the value if IsNew + IsDirty - when propertychanged is raised, alter the icon to the one which signals IsDirty=true.

I'd say it won't be that simple - once I'm going to save my entities, I won't get any PropertyChange events, will I? Or is there a method/property I could override and hook into an update? This would allow me to just provide an additional property and raise the property change events myself:

//change events for this read-only property are raised during XXX
public EditStatus Status
{
  get
  {
    if (IsNew) return EditStatus.New;
   else if (IsDirty) return EditStatus.Changed;
   else return EditStatus.Unchanged;
  }
}

Otherwise, I guess I had to introduce some kind of global event in order to make sure all data-related UIs will be refreshed if the user performs a save. It's not a catastrophe, but certainly far from elegant, compared to a simple binding on a property

Cheers, Philipp

once I'm going to save my entities, I won't get any PropertyChange events, will I?

You will get it when ever an entity field is changed, whether or not the entity is saved.

Walaa wrote:

once I'm going to save my entities, I won't get any PropertyChange events, will I?

You will get it when ever an entity field is changed, whether or not the entity is saved.

That's what I was saying - as saving a changed entity back does not change an entity field (only the non-browsable properties that do not fire events), there will be no event at all. This is why the suggested workaround does not work - my entities would still appear dirty on the UI once they were saved back to the DB...

The EntityBase class exposes an event called AfterSave which accoriding to the reference manual is fired each time this entity is persisted. Related entities can subscribe to this event to start housekeeping actions, like syncing internal FK fields with the PK fields of this entity

Would this help you?

Walaa,

Walaa wrote:

The EntityBase class exposes an event called AfterSave which accoriding to the reference manual is fired each time this entity is persisted. Related entities can subscribe to this event to start housekeeping actions, like syncing internal FK fields with the PK fields of this entity

Would this help you?

It will - thanks for the hint