1.0/1.1/1.5/2.0 upgrade and exception freezing UI

dean posted on Thursday, July 27, 2006

Warning - long story ahead:

I am working on upgrading a fairly large project from 1.0 to 2.0 (both csla and .net).

I have csla 1.51 running against the 2.0 framework now with minor changes to csla.

I have my project upgraded to visual studio 8.0 and running. (more changes but not too bad).

So now I want to work some of my code so it will run in csla 1.51 now and run in csla 2.0. In particular if I can rewrite my property set/get methods so they would run under either csla 1.5 or 2.0 then I can start making those changes without breaking my code.

So I created a business base wrapper program to "map" some of the 2.0 functionality into 1.51. For instance I duplicated the authorization rules from 2.0 and placed it in my wrapper class. I also created a PropertyHasChanged method which just calls BrokenRules.CheckRules and MarkDirty. Then when I change to 2.0 I just need to modify my wrapper class to pass the call thtu to CSLA 2.0.

For instance - old 1.x set code in property method:

if value <> mName then
     mName = value
    markdirty
    brokenrules.checkrules("Name")
endif

will now be
CanWriteProperty("Name",True)     
if value <> mName then
   mName = value
  PropertyHasChanged("Name")
endif

Now the problem - when the CanWriteProperty throws an exception the UI is stuck in that field. This is the behaviour that you got in the .net 1.0/1.1 with the csla 1.x. I was using the old form just reopened in visual studio 8.0.and recompiled.

I created a new form and used bindingsource and errorprovider and got the same behaviour. So it seems like something in csla 2.0 is preventing this behaviour.  Now if I were using csla2.0 with the read/write authorization extender then I wouldn't be able to edit the field in the first place. Is that how csla2.0 is preventing this?

What is it about csla 2.0/net2.0 that makes throwing the exception not freeze the ui in the field that threw the exception?

Dean