Any xaml heads here? | Tech Off

stevo_
Human after all

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?"

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.

stevo_
Human after all

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

stevo_
Human after all

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.

Sven Groot
My name has 9 letters. Coincidence? I think not...

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

stevo_
Human after all

In reply to Sven Groot

#Nov 20th, 2008 @ 5:58 AM

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.

Rob Relyea

In reply to stevo_

#Nov 20th, 2008 @ 6:47 AM

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

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to Rob Relyea

#Nov 20th, 2008 @ 7:02 AM

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.

stevo_
Human after all

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!

stevo_
Human after all

In reply to Sven Groot

#Nov 20th, 2008 @ 7:15 AM

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

Harlequin
http://twitter.com/TrueHarlequin

In reply to stevo_

#Nov 20th, 2008 @ 7:23 AM

If not, you'll need to use DependencyProperty I think....

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to Harlequin

#Nov 21st, 2008 @ 6:21 PM

I tried that too, made no difference.

stevo_
Human after all

In reply to Harlequin

#Nov 21st, 2008 @ 6:21 PM

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).

Harlequin
http://twitter.com/TrueHarlequin

In reply to stevo_

#Nov 22nd, 2008 @ 3:46 AM

No, it's silverlight as well. Did you try it as an attribute, with SomeInt="20"?

stevo_
Human after all

In reply to Harlequin

#Nov 22nd, 2008 @ 10:48 AM

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.

Harlequin
http://twitter.com/TrueHarlequin

In reply to stevo_

#Nov 22nd, 2008 @ 12:11 PM

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...

stevo_
Human after all

In reply to Harlequin

#Nov 24th, 2008 @ 8:31 AM

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

Harlequin
http://twitter.com/TrueHarlequin

In reply to stevo_

#Nov 24th, 2008 @ 11:12 AM

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...

stevo_
Human after all

In reply to Harlequin

#Nov 24th, 2008 @ 2:47 PM

My post wasn't a rant, but trying to describe the scenario to you as obvious as possible.. and don't bring age or maturity into this thanks.