Hi Lhotka!
Could you please have a look at this issue ?
http://community.infragistics.com/forums/p/42178/233660.aspx#233660
rgd,
EE.
What version of CSLA are you using?
v3.8.2 ... what would be the functionality of CSLA that the Ultragrid would be using to re-paint the field *without* the need of hoovering over the area with the mouse?
rgd,
EE
I don't know what they are expecting. CSLA raises the PropertyChanged event, as required by standard data binding, and at the collection level the BindingList<T> collection raises the ListChanged event - that's standard .NET behavior.
My recommendation any time people encounter an issue with a third party datagrid control is to try the same thing with the Microsoft datagrid control. You can think of the Microsoft datagrid control as the reference control - that's the core standard to which CSLA is coded, because it is the official Microsoft control.
If you can replicate the problem with the Microsoft control then it is probably an issue with your code or maybe with CSLA. If you can't replicate the issue with the Microsoft datagrid, then the problem is probably with the third party control.
Hi !
I've also noticed this with out-of-the-box Microsoft controls, so it's NOT related to this UltraGrid I think ...
What I noticed on 2 cases which I have is that if the validation rule is called from the:
protected override void OnChildChanged(Csla.Core.ChildChangedEventArgs e)
It's like it's "behind" ... e.g. I have too hoover over the item to get it to appear in the Grid, but in a regular [label] control from Microsoft this is ALSO happening !
Let me give you a real simple example:
I have this rule:
protected override void OnChildChanged(Csla.Core.ChildChangedEventArgs e)
{
if (e.ChildObject is SteeringCommittee)
{
this.ValidationRules.CheckRules("ErrorLabel");
}
base.OnChildChanged(e); //I've also tried putting this line at the top of the this function, doesn't matter
}
protected bool AddBusinessValidationRules()
{
ValidationRules.AddRule<Project>(SteeringCommiteesCount<Project>, "ErrorLabel");
return true;
}
private static bool SteeringCommiteesCount<T>(T target, Csla.Validation.RuleArgs e) where T : Project
{
if( target.SteeringCommittees.Count == 0 )
{
e.Description = "There needs to be at least one member in steering committee";
return false;
}
return true; // It enters this! But still the ErrorProvider remains on the label
}
Now the errorLabel appears spot on, in a simple Label control ( which is bound to this "ErrorLabel" string inside Project class ).
Then I insert a steeringCommittee ( and the rule runs and returns TRUE, but the errorProvider still remains on the simple label on the form !
- But the minute I change some OTHER property on the form, the ErrorLabel disappears **WITHOUT** running through this rule again ( and that's correct ... it should not enter the rule again, because I'm changing SOME other property ( any other property ) )
This is really weird ... and I've narrowed it down to this ...
When I'm running Validation rules through this, I get weird behaviours:
protected override void OnChildChanged(Csla.Core.ChildChangedEventArgs e)
{
....
}
Please help !
Regards,
EE
p.s. this is the simple "ErrorLabel" property on the Project's class:
private static readonly PropertyInfo<System.String> _errorLabelProperty = RegisterProperty<System.String>(p => p.ErrorLabel, string.Empty, null);
public System.String ErrorLabel
{
get { return GetProperty(_errorLabelProperty); }
private set { SetProperty(_errorLabelProperty, value); }
}
Yeah, that's a bug in your code then.
The ChildChanged event is raised in response to a PropertyChanged event. So it happens too late in the process to do what you want.
The easy fix is for you to call OnPropertyChanged() after you call CheckRules() to force another PropertyChanged event to be raised.
The correct fix is to use dependent properties so the CSLA rules engine invokes the rules for you - assuming this is all in one object - if the object handling ChildChanged is different from the one where the original change occurred, then your only answer is to call OnPropertyChanged() yourself.
Thanx Lhotka !
This fixed the problem:
protected override void OnChildChanged(Csla.Core.ChildChangedEventArgs e)
{
if (e.ChildObject is SteeringCommittee)
{
this.ValidationRules.CheckRules("ErrorLabel");
OnPropertyChanged("ErrorLabel");
}
base.OnChildChanged(e);
}
BUT of course I want to do it the correct way ... you say with dependent properties.
How would you do that ? ( I know how to use dependent properties )
- Which properties would you connect as dependant ?
Would you add this property ( which is a EditableChildList ) to be dependent on the "ErrorLabel" control ?
This managed property is inside the Project class ( which also has the managed property for ErrorList ):
//AssociatedOneToMany
private static readonly PropertyInfo< SteeringCommitteeList > _steeringCommitteesProperty = RegisterProperty<SteeringCommitteeList>(p => p.SteeringCommittees, Csla.RelationshipTypes.Child);
public SteeringCommitteeList SteeringCommittees
{
get
{
if(!FieldManager.FieldExists(_steeringCommitteesProperty))
{
if(IsNew || !RecoveryPlanner.Business.SteeringCommitteeList.Exists(new RecoveryPlanner.Business.SteeringCommitteeCriteria {ProjectId = ProjectID}))
LoadProperty(_steeringCommitteesProperty, RecoveryPlanner.Business.SteeringCommitteeList.NewList());
else
LoadProperty(_steeringCommitteesProperty, RecoveryPlanner.Business.SteeringCommitteeList.GetByProjectId(ProjectID));
}
return GetProperty(_steeringCommitteesProperty);
}
}
This does NOT fix the problem:
//Properties all dependant on each other:
ValidationRules.AddDependentProperty(_errorLabelProperty, _steeringCommitteesProperty, true);
Infragistics have replied ... can you please look at the reply from them ?
http://community.infragistics.com/forums/p/42178/233797.aspx#233797
Sure, but their reply just confirms what you already know from our discussion 
Copyright (c) Marimer LLC