CSLA .NET discussion

Re: CslaActionExtender - useful enough vs. even more useful

Tiago Freitas Leal — Mon, 14 May 2012 21:54:06 GMT

Hi all,

The attached code solves the issue

on initialize, only buttons with DisableWhenUseless or DisableWhenClean options should be forced to enabled state

This is important if you use CslaActionExtenderTsb (for ToolStripButton) since you can have navigation buttons that are enabled by other UI events. Of course you can also have navigation buttons that are plain buttons, so the fix applies to both classes.

Regards

Re: CslaActionExtender - useful enough vs. even more useful

Tiago Freitas Leal — Wed, 09 May 2012 23:12:03 GMT

JonnyBee:

Hi,

You may also want to look into BusinessRules.GetAllBrokenRules().

This static method will return a list of all broken rules in <bo> and all child/grandchild objects and may be presented as a list or a tree view.

I did have a look and found it not very straightforward to use. So I left this issue to later on.

On the mean time I found that this controls force all buttons to enabled. This isn't a good idea because I might need to "bind" the enabled state to a BO or Ui state. Another feature to add...

<edit>

It's fixed.

</edit>

Re: CslaActionExtender - useful enough vs. even more useful

JonnyBee — Tue, 08 May 2012 19:34:47 GMT

Hi,

You may also want to look into BusinessRules.GetAllBrokenRules().

This static method will return a list of all broken rules in <bo> and all child/grandchild objects and may be presented as a list or a tree view.

Re: CslaActionExtender - useful enough vs. even more useful

Tiago Freitas Leal — Mon, 07 May 2012 22:27:53 GMT

Hi Jonny,

This works perfectly. I enclose V4 with the corrected code for IButtonControl (button and LinkLabel) and for ToolStripButton. Thanks.

This isn't closed as the broken rules (and validation) message box is far from ready:

only lists the broken rules for the root object and its properties (child objects broken rules are missing)
should list the friendly name of the property (as it's localizable) instead of the property name

The later depends on GetPropertyFriendlyName proposal on http://forums.lhotka.net/forums/p/3424/52654.aspx#52654

Regards

Re: CslaActionExtender - useful enough vs. even more useful

cwinkelmann — Mon, 07 May 2012 20:07:07 GMT

@JonnyBee: That worked perfectly.

I added both ways to the demo project and I'll continue developing it. I hope to add functionality to it as a demo of lots of CSLA functionality, so I'll eventually propose adding it to the CSLAContrib project.

Re: CslaActionExtender - useful enough vs. even more useful

JonnyBee — Sun, 06 May 2012 05:36:25 GMT

@Tiago:

First I'd refactor so that the ActionExtender has AddEventHoks and RemoveEventHooks methods:

    public void ResetActionBehaviors(ISavable objectToBind)
    {
      InitializeControls(true);
 
      BindingSource rootSource = _dataSource as BindingSource;
 
      if (rootSource != null)
      {
        AddEventHooks(objectToBind);
      }
      
      _bindingSourceTree = BindingSourceHelper.InitializeBindingSourceTree(_container, rootSource);
      _bindingSourceTree.Bind(objectToBind);
 
    }
 
    private void AddEventHooks(ISavable objectToBind)
    {
      // make sure to not attach many times
      RemoveEventHooks(objectToBind);
 
      INotifyPropertyChanged propChangedObjParent = objectToBind as INotifyPropertyChanged;
      if (propChangedObjParent != null)
      {
        propChangedObjParent.PropertyChanged += propChangedObj_PropertyChanged;
      }
 
      INotifyChildChanged propChangedObjChild = objectToBind as INotifyChildChanged;
      if (propChangedObjChild != null)
      {
        propChangedObjChild.ChildChanged += propChangedObj_ChildChanged;
      }
    }
 
    private void RemoveEventHooks(ISavable objectToBind)
    {
      INotifyPropertyChanged propChangedObjParent = objectToBind as INotifyPropertyChanged;
      if (propChangedObjParent != null)
      {
        propChangedObjParent.PropertyChanged -= propChangedObj_PropertyChanged;
      }
 
      INotifyChildChanged propChangedObjChild = objectToBind as INotifyChildChanged;
      if (propChangedObjChild != null)
      {
        propChangedObjChild.ChildChanged -= propChangedObj_ChildChanged;
      }
    }

And then change the save code to make sure to attach events:

                        try
                        {
 
                          RemoveEventHooks(savableObject);
                          savableObject = savableObject.Save() as Csla.Core.ISavable;
 
                          OnObjectSaved(new CslaActionEventArgs(props.CommandName));
 
                          switch (props.PostSaveAction)
                          {
                            case PostSaveActionType.None:
 
                              if (source != null && props.RebindAfterSave)
                              {                        
                                _bindingSourceTree.Bind(savableObject);
                                 AddEventHooks(savableObject);
                              }
                              break;
 
                            case PostSaveActionType.AndClose:
 
                              CloseForm();
                              break;
 
                            case PostSaveActionType.AndNew:
 
                              OnSetForNew(new CslaActionEventArgs(props.CommandName));
                              AddEventHooks(savableObject);
                              break;
                          }
                        }
                        catch (Exception ex)
                        {
                          _bindingSourceTree.Bind(savableObject); //Issue ID:  426
                          AddEventHooks(savableObject);
                          OnErrorEncountered(new ErrorEncounteredEventArgs(props.CommandName, new ObjectSaveException(ex)));
                          raiseClicked = false;
                        }

Re: CslaActionExtender - useful enough vs. even more useful

JonnyBee — Sun, 06 May 2012 05:07:03 GMT

@cwinkelmann

I looked at your code and the problem is most likely your code and how you attach to the events. You should not do this in the constructor.

Alt 1: Do not attach to the events - simply override OnChildChanged event like this in EditableRoot.cs. This relies on CSLA to use the AddXYEventHook methods to hook into events properly and your code just override the method OnChildChanged (that in turn triggers the ChildChanged event).

    protected override void OnChildChanged(Csla.Core.ChildChangedEventArgs e)
    {
      base.OnChildChanged(e);
      Calculate();
    }

Alt 2:Override the proper methods to Add/Remove event hooks like this:

    private EditableRoot()
    { 
        /* Force use of Object Factory methods */
    }

    protected override void OnRemoveEventHooks(Csla.Core.IBusinessObject child)
    {
      base.OnRemoveEventHooks(child);
      this.ChildChanged -= EditableRoot_ChildChanged;
    }
 
    protected override void OnAddEventHooks(Csla.Core.IBusinessObject child)
    {
      base.OnAddEventHooks(child);
      this.ChildChanged += EditableRoot_ChildChanged;
    }

    private void EditableRoot_ChildChanged(object sender, Csla.Core.ChildChangedEventArgs e)
    {
      Calculate();
    }

The OnXYEventHooks method is also used by CSLA to attach itself to the events on the child objects.

Re: CslaActionExtender - useful enough vs. even more useful

Tiago Freitas Leal — Sun, 06 May 2012 02:24:55 GMT

Hi all,

No progress on this front. After several hours of debug, I just couldn't find the soltuion for the "button is always disabled after a save" issue.

Re: CslaActionExtender - useful enough vs. even more useful

cwinkelmann — Tue, 01 May 2012 18:59:03 GMT

That is exactly the same result I have on a Demo project. I was wondering if I was not performing the save operations correctly and that would cause some odd behavior with the child/parent change notification, but I thought everything I did was run of the mill type stuff.

So I am toying with the root, child, grandchild pattern and after having saved the root, which triggers the Child_Update on child and grandchild, then the child changed events don't seem to fire when I modify the child or grandchild BO. I'm not sure if there is a problem with the clone process that it is not creating the same even handler subscriptions or if there is a problem somewhere else. I'm not entirely sure it is a problem with ActionExtender as my root object is not listening to child changed events after having saved once...

I've attached a proof of concept hoping that will help anyone who wants to try Tiago's latest version of the ActionExtender.

Re: CslaActionExtender - useful enough vs. even more useful

Tiago Freitas Leal — Mon, 30 Apr 2012 01:21:53 GMT

Hi all,

Found another issue that was present on Miguel's code and that I kept in the changed code.

1) Set DisableWhenClean (or the new DisableWhenUseless) property to True on buttons:

Save
Save/New
Save/Close
Cancel

2) Load a form => buttons are disabled (OK)

3) Change something => buttons are enabled (OK)

4) Save the form => buttons are disabled (OK)

5) Again, change something => buttons are disabled (NOK)

Note - DisableWhenUseless means the button is disabled when no action is available for it (Save for the save action family and Undo for the cancel action family).

Re: CslaActionExtender - useful enough vs. even more useful

Tiago Freitas Leal — Mon, 16 Apr 2012 21:53:54 GMT

Hi Rocky,

The code I post is always public domain. If I need to sign a contributor agreement in order for Csla to use the code above, just tell me where the dotted line is.

RockfordLhotka:

I have at least one volunteer who's in the process of signing a contributor agreement, and who has indicated interest in working on some of the Windows Forms items in bugtracker, so there may be some changes that'll come in 4.5.

Re: CslaActionExtender - useful enough vs. even more useful

RockfordLhotka — Mon, 16 Apr 2012 19:34:39 GMT

Nothing has changed in Csla.Windows (Windows Forms support) for a very long time. This hasn't been a priority - our limited dev resources have been busy just keeping up with all the new technologies...

I have at least one volunteer who's in the process of signing a contributor agreement, and who has indicated interest in working on some of the Windows Forms items in bugtracker, so there may be some changes that'll come in 4.5.

Re: CslaActionExtender - useful enough vs. even more useful

cwinkelmann — Mon, 16 Apr 2012 19:16:37 GMT

What is the status of CslaActionExtender in Csla 4.3.10? So at this point all known bugs should be solved with this v3 set of files for 4.3.10?

I didn't find any open bugs listed here: http://www.lhotka.net/cslabugs/search.aspx

but I may not be using the search function correctly.

Re: CslaActionExtender - useful enough vs. even more useful

Tiago Freitas Leal — Sun, 15 Apr 2012 22:37:49 GMT

JonnyBee:

Hi Tiago,

This code is not "bulletproof":

(...)

And there's a few other know bugs to - check in bugtracker.

Found 4 open issues. There are 3 bugs

http://www.lhotka.net/cslabugs/edit_bug.aspx?id=426

http://www.lhotka.net/cslabugs/edit_bug.aspx?id=700

http://www.lhotka.net/cslabugs/edit_bug.aspx?id=843

and 1 enhancement (an earlier version of this one)

http://www.lhotka.net/cslabugs/edit_bug.aspx?id=650

Attached is the updated files with solution for issues 426 and 843. Issue 700 duplicates 426. Anyway I tested the sample and it passed.

Notice that 3 new Csla resources are needed but those lines are commented and hard coded strings are used instead.

Re: CslaActionExtender - useful enough vs. even more useful

JonnyBee — Sun, 15 Apr 2012 20:25:45 GMT

Hi Tiago,

This code is not "bulletproof":

              case CslaFormAction.Validate:

                if (savableObject is Csla.Core.BusinessBase)
                {
                  Csla.Core.BusinessBase businessObject = savableObject as Csla.Core.BusinessBase;
                  if (businessObject.BrokenRulesCollection.Count > 0)
                    MessageBox.Show(businessObject.BrokenRulesCollection.ToString(), Resources.Error, MessageBoxButtons.OK, MessageBoxIcon.Error);
                  else
                      MessageBox.Show(ObjectIsValidMessage, Resources.Information, MessageBoxButtons.OK, MessageBoxIcon.Information);
                }

                break;

There's nothing that prevents anyone from using a BusinessBase object that has children so the code should check for <bo>.IsValid

Another known bug is the OnClick

¨                 if (objectValid)
                  {
                    CslaActionCancelEventArgs savingArgs = new CslaActionCancelEventArgs(
                      false, props.CommandName);
                    OnObjectSaving(savingArgs);

                    if (!savingArgs.Cancel) // this line was !args.Cancel

And there's a few other know bugs to - check in bugtracker.