NullReferenceException

Jul 21, 2011 at 7:21 PM

Hi Throb,

I have updated this Issue  : http://obtics.codeplex.com/workitem/7639

Have you an idea ?

Regs,
Vincent

Coordinator
Jul 31, 2011 at 12:26 AM

Ok, checked in some code that should fix your problem.

Regs,

Thomas

Aug 1, 2011 at 9:24 AM

Thank you very much, but I have a regression (I have lots of NullReferenceException in GetValueFromItm.) from the version I used (http://obtics.codeplex.com/discussions/215764). And I approach a delivery so I can not afford to change all my code for now. So I'll put the fix in my version.

What is the reason not to use this trick (http://grahammurray.wordpress.com/2010/05/30/binding-to-anonymous-types-in-silverlight/) instead of Concrete () in Silverlight?

I would like to chat with you to better understand the code and help to improve Obtics.

Thanks.

Vincent

Coordinator
Aug 8, 2011 at 3:47 PM

Hi Vincent,

The null ref exceptions would be possible. Previously Obtics all the time implicitly checked for null values. It was necessairy because Obtics would break if such an exception was raised. If all is right this sort of exceptions shoudn't break the Obtics kernal anymore and since the implicit checks weren't helpfull for performance I removed them. Now programmer should check for null references (like in normal code) and/or handle the resulting Exceptions via new extension methods.

I think the trick you mention specifically deals with binding to anonymous types. Using anonymous types in transformed expressions leads to problems in partially trusted invironments. The trick would help but it would require the DEFINING assembly (not the obtics assembly) to give 'internals visible permission'.

The Concrete methods deal with another problem that is specific for Silverlight (and less so for WPF). Both systems look in the object hierarchy for a given property to bind to. In WPF you can specifically indicate that it should bind to a property on an interface but in Silverlight this is not possible. I don't want to expose the internals of Obtics (make all transformation object classes and hierarchies public) so the solution was to use an explicit and public patch object that would proxy an interface and pass it's properties through via concrete and public class properties. 

It could be an idea to expose the internal classes of obtics to the WPF or Silverlight assemblies so that they can bind to the internal properties. I need to experiment with that; thanks for the tip.. :-)

Grtz,

Thomas.