Tech Off Thread

19 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Any xaml heads here?

Back to Forum: Tech Off
  • User profile image
    stevo_

    Given the poco class:

    public class TestClass
    {
      public int SomeInt { get; set; }
    }

    and the xaml:

    <TestClass xmlns="ref to clr namespace where TestClass is">
      <TestClass.SomeInt>20<TestClass.SomeInt>
    </TestClass>

    I get an exception:

    Unknown build error, 'Object reference not set to an instance of an object.'

    If I use the xaml:

    <TestClass xmlns="ref to clr namespace where TestClass is" SomeInt="20" />

    All is good..

    I wondered at first if this was some sort of conversion issue, but as far as I can tell - xaml should be doing primative type conversions itself.. whats even weirder is - this is currently compiled xaml to baml.. so I actually have the x xaml namespace, a class attribute and code behind.. but if I change it to loose xaml, I don't see any errors..

    Anybody done anything with xaml outside of wf wpf?

    It isn't a biggy, but I really aren't sure where to look given the error is basically "i'unno, something bad i guess?"

  • User profile image
    spivonious

    I think I remember reading that for simple types you can't do them like your first example.  That is reserved for collections, like Grid.RowDefinitions.

    I could also be remembering some crazy XAML dream, so take this with a grain of salt.

  • User profile image
    stevo_

    but wpf can do it Tongue Out and it works with loose xaml.

    remember that xaml is really distinguished from wpf.. it may be primary used by wpf, but its actually capable of working against pocos..

    But wpf can do this, try it out for int or bool properties for example, you'll see all is happy.. no errors

  • User profile image
    stevo_

    Anybody got any idea on where to go to ask questions about xaml? The only place I can think of hooking some interest is the msdn wpf forum - but it looked dead.

  • User profile image
    Sven Groot

    Could you post a compilable sample project that shows what you're doing exactly?

  • User profile image
    stevo_

    Sven Groot said:
    Could you post a compilable sample project that shows what you're doing exactly?
    Err, I can give you step by step if that helps..

    Start a new wpf app.. create a new user control

    Change the default xml namespace (xmlns) to the clr namespace of your project (ie, xmlns="clr-namespace:WpfApplication1")

    Remove the height and width properties, and delete the child grid..

    Change UserControl (root element) to TestObj (ensure you change the closing tag as well)..

    Now go into the code behind for that xaml and above the class add another:

    public class TestObj
    {
    }

    Change the code behind class to inherit from TestObj

    Everything should be happy (the wpf app won't run - but the designer and compilation will be happy)..

    Not add a property to TestObj.. sayyy:

    public bool IsXamlCool { get; set; }

    Go to the xaml and add IsXamlCool property add you'll get intellisense autocomplete, the designer will be happy and compiles etc..

    Then change the property to be

    <Testobj.IxXamlCool>True</Testobj.IxXamlCool>

    As a child element.. you should get an error:

    "Unknown build error, 'Object reference not set to an instance of an object.'"

    I'm trying to work out if this is a bug with xaml, or I need to specify some type conversions to do even primative conversions like bools.

  • User profile image
    Rob Relyea

    stevo_ said:
    Sven Groot said:
    *snip*
    Err, I can give you step by step if that helps..

    Start a new wpf app.. create a new user control

    Change the default xml namespace (xmlns) to the clr namespace of your project (ie, xmlns="clr-namespace:WpfApplication1")

    Remove the height and width properties, and delete the child grid..

    Change UserControl (root element) to TestObj (ensure you change the closing tag as well)..

    Now go into the code behind for that xaml and above the class add another:

    public class TestObj
    {
    }

    Change the code behind class to inherit from TestObj

    Everything should be happy (the wpf app won't run - but the designer and compilation will be happy)..

    Not add a property to TestObj.. sayyy:

    public bool IsXamlCool { get; set; }

    Go to the xaml and add IsXamlCool property add you'll get intellisense autocomplete, the designer will be happy and compiles etc..

    Then change the property to be

    <Testobj.IxXamlCool>True</Testobj.IxXamlCool>

    As a child element.. you should get an error:

    "Unknown build error, 'Object reference not set to an instance of an object.'"

    I'm trying to work out if this is a bug with xaml, or I need to specify some type conversions to do even primative conversions like bools.
    This sounds like PropertyElements inside the XAML MarkupCompiler may have a problem with types from mscorlib which have type converters?  Our markupcompiler and the normal runtime parser sometime have bugs that cause them to not work consistently.  We now have a bug filed on this issue and will address this issue in the future.  For now, you can likely either:
    1) use an attribute to represent this value
    2) you may be able to add a property level type converter to point to BoolConverter, etc......However, this doesn't scale very well.  And you can only do it on properties that you define.

    The reason for this bug is probably the fact that types in MsCorLib can't be marked with TypeConverterAttributes since that is a System.dll thing.  We have a hard coded list in the XAML stack of the list of types from mscorlib that have type converters.

    In .NET 4, the WPF parser is being rearchitected to run on top of System.Xaml.dll that will make it so that if an attribute form works, so will the property element form.  The XamlXmlReader component will represent both of those situations identically...so we should have better behavior.

    The WPF forum and relevelant posts on blog are great places to ask XAML questions.

    Thanks, Rob Relyea
    Architect, XAML/WPF Teams
    http://robrelyea.com/blog

  • User profile image
    Sven Groot

    Rob Relyea said:
    stevo_ said:
    *snip*
    This sounds like PropertyElements inside the XAML MarkupCompiler may have a problem with types from mscorlib which have type converters?  Our markupcompiler and the normal runtime parser sometime have bugs that cause them to not work consistently.  We now have a bug filed on this issue and will address this issue in the future.  For now, you can likely either:
    1) use an attribute to represent this value
    2) you may be able to add a property level type converter to point to BoolConverter, etc......However, this doesn't scale very well.  And you can only do it on properties that you define.

    The reason for this bug is probably the fact that types in MsCorLib can't be marked with TypeConverterAttributes since that is a System.dll thing.  We have a hard coded list in the XAML stack of the list of types from mscorlib that have type converters.

    In .NET 4, the WPF parser is being rearchitected to run on top of System.Xaml.dll that will make it so that if an attribute form works, so will the property element form.  The XamlXmlReader component will represent both of those situations identically...so we should have better behavior.

    The WPF forum and relevelant posts on blog are great places to ask XAML questions.

    Thanks, Rob Relyea
    Architect, XAML/WPF Teams
    http://robrelyea.com/blog

    I dug into this a little by attaching a second instance of VS to the first VS instance and running the build. Thanks to the .Net reference source I could get some idea of what was going on. It was encountering an error loading the assembly (obviously, since we're compiling that assembly it doesn't exist yet) and stores a null value, which the XamlParser tries to use as context somewhere and throws a NullReferenceException. It jumps around a lot because of the optimizations but I think that's what happens.

    In any case, after moving the type TestClass to another assembly, Stevo's example works fine. It appears to be a bug in the parser when using types from the assembly you're building as the root element of a XAML file.

  • User profile image
    stevo_

    Wow, I never expected to get such a response!

    Really appreciate that because I was feeling like I wouldn't find anybody who understands xaml well, let alone somebody on the xaml team!

    I'm really really happy to see that xaml is becoming more of a generic citizen in .NET because its really well executed..

    Your blog is just perfect, exactly what I was looking for!

    Thanks a lot!

  • User profile image
    stevo_

    Sven Groot said:
    Rob Relyea said:
    *snip*

    I dug into this a little by attaching a second instance of VS to the first VS instance and running the build. Thanks to the .Net reference source I could get some idea of what was going on. It was encountering an error loading the assembly (obviously, since we're compiling that assembly it doesn't exist yet) and stores a null value, which the XamlParser tries to use as context somewhere and throws a NullReferenceException. It jumps around a lot because of the optimizations but I think that's what happens.

    In any case, after moving the type TestClass to another assembly, Stevo's example works fine. It appears to be a bug in the parser when using types from the assembly you're building as the root element of a XAML file.

    Ah ha! I was wondering if that could be it, cheers sven!

  • User profile image
    Harlequin

    stevo_ said:
    Sven Groot said:
    *snip*
    Ah ha! I was wondering if that could be it, cheers sven!
    If not, you'll need to use DependencyProperty I think....

  • User profile image
    Sven Groot

    Harlequin said:
    stevo_ said:
    *snip*
    If not, you'll need to use DependencyProperty I think....
    I tried that too, made no difference.

  • User profile image
    stevo_

    Harlequin said:
    stevo_ said:
    *snip*
    If not, you'll need to use DependencyProperty I think....
    Thats a wpf system, not xaml.. (as far as I'm aware), the system for doing attached properties etc just happens to use dependency props, probably because the template binding markup extension is looking for them (templatebinding again being a wpf system).

  • User profile image
    Harlequin

    stevo_ said:
    Harlequin said:
    *snip*
    Thats a wpf system, not xaml.. (as far as I'm aware), the system for doing attached properties etc just happens to use dependency props, probably because the template binding markup extension is looking for them (templatebinding again being a wpf system).
    No, it's silverlight as well. Did you try it as an attribute, with SomeInt="20"?

  • User profile image
    stevo_

    Harlequin said:
    stevo_ said:
    *snip*
    No, it's silverlight as well. Did you try it as an attribute, with SomeInt="20"?
    uh thats just being pedantic.. technically WF, WPF and silverlight all use a (the) dependency system, I think theres probably some talk about unification of the dependency system (maybe as part of component model), I'm not sure.. but one things for sure is that the dependency system is just an object layer, nothing to do with xaml..

    xaml really is all about representing object graphs in markup.. it doesn't force any inheritance or specific classes on you.. Binding, TemplateBinding etc are just markup extensions, and attached properties / events are static getter and setters on classes.

  • User profile image
    Harlequin

    stevo_ said:
    Harlequin said:
    *snip*
    uh thats just being pedantic.. technically WF, WPF and silverlight all use a (the) dependency system, I think theres probably some talk about unification of the dependency system (maybe as part of component model), I'm not sure.. but one things for sure is that the dependency system is just an object layer, nothing to do with xaml..

    xaml really is all about representing object graphs in markup.. it doesn't force any inheritance or specific classes on you.. Binding, TemplateBinding etc are just markup extensions, and attached properties / events are static getter and setters on classes.

    public static readonly DependencyProperty SomeIntProperty = DependencyProperty.Register("SomeInt", typeof(int), typeof(YourControl), new PropertyMetadata(new PropertyChangedCallback(onIntChanged)));

    So you can't use anything like this? Or do you still get errors...

  • User profile image
    stevo_

    Harlequin said:
    stevo_ said:
    *snip*

    public static readonly DependencyProperty SomeIntProperty = DependencyProperty.Register("SomeInt", typeof(int), typeof(YourControl), new PropertyMetadata(new PropertyChangedCallback(onIntChanged)));

    So you can't use anything like this? Or do you still get errors...

    Sigh.. forget it anyway because not only has my question been answered by sven, but I can't seem to express the point that a dependency property isn't a xaml construct.. nor is the dependency system.

    the dependency system just happens to be built with xaml heavily in mind.. I think the problem with xaml is that MS has never properly explained it to people.. in fact- when wpf came out.. this is how xaml came across:

    heres wpf, we have this cute markup (we call it xaml), but we're not saying xaml is the way 'ew xml right?!', this is all we had time for..

    uh, thats nice - but xaml is actually a very good expressive language and I think since then theres been a struggle to find something thats equally expressive.. json is nice for little things but falls apart when you want to do attached properties and tidy namespaces.

    if you read the prior post by a ms xaml employee you'll find links regarding xaml becoming a proper citizen in .net 4 (technically I think it works on 3.5 as well)..

    Actually that would probably make my original point more clear.. xaml is becoming: System.Xaml.dll

  • User profile image
    Harlequin

    stevo_ said:
    Harlequin said:
    *snip*

    Sigh.. forget it anyway because not only has my question been answered by sven, but I can't seem to express the point that a dependency property isn't a xaml construct.. nor is the dependency system.

    the dependency system just happens to be built with xaml heavily in mind.. I think the problem with xaml is that MS has never properly explained it to people.. in fact- when wpf came out.. this is how xaml came across:

    heres wpf, we have this cute markup (we call it xaml), but we're not saying xaml is the way 'ew xml right?!', this is all we had time for..

    uh, thats nice - but xaml is actually a very good expressive language and I think since then theres been a struggle to find something thats equally expressive.. json is nice for little things but falls apart when you want to do attached properties and tidy namespaces.

    if you read the prior post by a ms xaml employee you'll find links regarding xaml becoming a proper citizen in .net 4 (technically I think it works on 3.5 as well)..

    Actually that would probably make my original point more clear.. xaml is becoming: System.Xaml.dll

    Nice conversation.

    An adult would have said something like this:
    "I see where you're coming from, but here's the problem..."

    Instead of going off on a rant...

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.