Discussions

see http://michaelshim.com/blog/2009/12/10/use-xamlreader-load-for-wpf-xaml-not-xamlservices-load for some details.

It depends what you are trying to do with your XamlNode loop...

You could use the Wpf SchemaContext + your code (pass it to the constructor of the XamlXmlReader), and you'll get pass this binding problem.  But there are other things in XamlReader.Load() that won't happen. See the blog post for the list.

Thanks,
Rob Relyea, WPF Team
http://robrelyea.com/blog | http://twitter.com/rrelyea

markshiffer said:

Same problem here. Eagerly awaiting the next preview release for Blend.

Blend's Download site includes the Blend 4 Beta now, which is what you were waiting for (and more!).

Thanks, Rob Relyea

XAML UI & XAML Teams

http://robrelyea.com/blog

http://twitter.com/rrelyea

 

exoteric said:

Rob Relyea said:

*snip*

Thanks for the answer Rob. I'll go read how these type converters work.

 

The reason I care about this is that 1) the classes are supposed to be invariant, they're designed this way; 2) XAML is actually a great way to quickly debug your code by dumping out an object graph; I'm projecting binary files into an object graph and want to verify that the projection is not completely foobar; XAML is actually quite nice in this regard - it's also possible to toss out some data to some folks who can then possibly use XSLT, XLinq and whatnot to do further processing on the data - maybe injecting it into a SQL store and whatnot - without needing my code (although the code is freely available.)

 

I guess my reason for disliking the settability requirement is because it forces me to abandon a declarative/functional style of programming. I want to maximize the compiler's (hypothetical) ability to perform optimizations without needing too much analysis and to have strong guarantees about how the data can be used ("reuse":projection over "use":mutation). This is somewhat a purist stance but it is actually reasonable to not want to have classes have the property of mutability. The WPF freezable properties is pretty nice but I prefer static guarantees whenever possible; I don't want any code to even try and attempt to modify the data; or more precisely, I don't want any codepath to have this possibility. I'll admit that these design principles are overkill for the hobby framework I'm building but I believe they are quite sound in general.

 

It's pretty cool that XAML can project (almost) any object graph to X(A)ML with just one line of code; it's an extremely quick and easy way to generate data, even if for prototyping or analysis purposes.

 

That being said, you could of course argue that my use-case is silly and I should simply use XLinq projection for this - it's just that this is a use-case XAML could (it appears) easily support with no downsides. I suppose the reasoning behind the design may also be to help developers in their class design so that they can read in the data again

 

I wonder if someone should build static analysis for this situation as well and just warn in this case; maybe the Load method should have a type-parameter as well to make it easier to tell, in case the cast doesn't happen right away. Maybe put a "XamlReady" attribute on the classes.

@exoteric-

I think I understand your scenarios for XAML:

1) Want immutable types.

• Hope that the immutability part can work with non-default constructors for you.

2) Want to write down most of the state of the object

• What rules would be ideal for you? Some R/O properties (like a parent pointer, get a bit tricky). We use DesignerSerializationVisibilityAttribute to Hide some properties that would normal be written. In your scenario, please review all R/O properties, and see what rules would work for you.
• If you look at http://robrelyea.com/demos/xamlpadsample and the way I write down Pad.config.xaml, you'll see that I'm using XAML for a similar purpose...and it is helpful during development/debugging. I'm also focusing on using that file for config settings, so I'm sticking to normal rules for which properties get written, as I am going to load it later.

Thanks, Rob

 

PerfectPhase said:

Coming soon in XAML-2009 non-default constructors....

 

<coll:List x:Key='list' x:TypeArguments='x:String' x:FactoryMethod='local:Factory.CreateStringList'>

    <x:Arguments>

        <x:String>Mickey,Donald</x:String>

    </x:Arguments>

</coll:List>

 

via: http://blogs.msdn.com/llobo/archive/2009/11/20/xaml-2009-features-factorymethod-arguments.aspx

 

You might want to have a look at the noode stream support in System.Xaml (see PDC2008 - TL36)  You can proberbly do what ever you like if you use XamlObjectReader and XamlXmlWriter rather than XamlServices.

@exoteric-

You can work with Non-Default Constructors

XamlServices.Save() in .Net 4 can write instances which need non-default constructors to be created. In order to tell the Save() routine (or really the XamlObjectReader under the covers) which constructor to use, you must have a TypeConverter or ValueSerializer that can return an InstanceDescriptor given the instance.

 

RoundTripping

Yes, XamlServices.Save() currently attempts to only ever write things that can be read. Would love to understand what properties you want to write, and why. Do you intend to try to read them later?

PerfectPhase mentions using XamlObjectReader and XamlXmlWriter and added the functionality you want.  XamlObjectReader has an Instance property, which should enable you to see the current object that the XOR is dealing with...perhaps you could inject additional XAML nodes via a XAML node loop.

 

Ways that WPF has dealt with default Constructors and immutability

In WPF, some types inherit from Freezable which enables a pattern of r/w properties until they Freeze() is called, then they throw if you try to set them.

 

Hope that helps. Look forward to more feedback/discussion.

 

Thanks,

Rob Relyea

XAML Team

http://robrelyea.com/blog

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

Mouse.OverrideCursor = Cursors.None;

to remove the override, I believe you set Mouse.OverrideCursor = null;

Hope these also help:
See this post from the WPF forum.

Here is a search query for all topics there with the word "Cursor" in it.
MSDN: FrameworkElement.Cursor
MSDN Sample: Changing the Cursor Type Sample

Thanks, Rob

Rob Relyea | Program Manager, WPF & Xaml Language Team
robrelyea.com | /blog | /wpf | /xaml

Glad to hear of your excitement.  As a developer, I have to agree that databinding is one of the nicer features of WPF...it is great to program to your data, and have the UI take care of itself.

A few links that focus on Data:
Data Binding Overview (MSDN)
WPF Hands on Labs (including one on databinding)

Enjoy!

By the way, WCF does work with WPF in .Net 3.0, however, when you want to run your WPF application as an XBAP (xaml browser application) that runs in the browser), it requires that all code can run in a partial-trust sandbox.  Much of WCF couldn't run under that environment in v3, however .Net 3.5 will have a WCF that can...

Thanks, Rob

Rob Relyea | Program Manager, WPF & Xaml Language Team
robrelyea.com | /blog | /wpf | /xaml

 

I'd imagine you'd want to find APIs to download and send email from AOL.  I'd start looking around here: http://dev.aol.com/apis.  I didn't see anything with my quick look...

Thanks, Rob

Rob Relyea | Program Manager, WPF & Xaml Language Team
robrelyea.com | /blog | /wpf | /xaml

http://msdn2.microsoft.com/en-us/library/system.windows.controls.control.mousedoubleclick.aspx points to an event defined on Control (and thus available on Button as well) that may help you.  Also note that ClickCount may help you.

Thanks, Rob

Rob Relyea | Program Manager, WPF & Xaml Language Team
robrelyea.com | /blog | /wpf | /xaml

Great to see!

Couple of issues I see:
1) why didn't we (Microsoft) just publish the Facebook app as a clickonce application, instead of embedding it in the sdk.

2) my rolodex window won't resize...anybody else seeing this?

3) if #2 is a bug in the app, #1 would make it easy to fix for everybody...

Thanks,
Rob

Rob Relyea | Program Manager, WPF & Xaml Language Team
robrelyea.com | /blog | /wpf | /xaml