Hi Rocky,
In Min/MaxValue rule's Execute methods,I think, following line might be changed because value is always null when first hit.
T value = (T)context.InputPropertyValues[PrimaryProperty]; <-- error saying object reference bla bla.
into
T value = (context.InputPropertyValues[PrimaryProperty] != null ? (T)context.InputPropertyValues[PrimaryProperty] : default(T));
or
T value = (context.InputPropertyValues[PrimaryProperty] != null ? (T)context.InputPropertyValues[PrimaryProperty] : (T)PrimaryProperty.DefaultValue);
so that default value of type or property bag would be compared. When I use default value other than zero in property declaration , (T)PrimaryProperty.DefaultValue looks work fine.
Thank you in advance.
HK.Lee
How is the value null? If T is a primitive type this should always have access to an actual value.
Hi Rocky,
All runs fine without problem in beta1 and beta2. Because of this, I stucked and debugged many times and finally I put every line to check null even in primitive type in my business rule. I don't know how that was happened. I feel as if I were possessed by devil. Another thread for viewmodelbase's IParent runs fine too so will close it. Dazzled morning to me and feel sorry to bother your time.
Thank you in advance.
HK.Lee
Is this going to make it into a production CSLA? It looks like it isn't there in 4.1. This sure comes in handy with nullable types.
From the thread it didn't sound like it was still an issue. If it is an issue I'll add it to the wish list (and I assume it is based on your follow-up).
Since I can and have made my own rule on this, it isn't a big issue, more of a nice to have to be able to use the standard rules for nullable types and nullable primitives.
Copyright (c) Marimer LLC