Rob Relyea - XAMLified

You’ll never believe what I found in a bar tonight…

A USB key, with the following note taped to it:

This is a copy of the DX interop sample I’d like to share with the world, and I’d love your help.  It consists of a VS10 solution with 4 projects:

• SurfaceQueueLib is a copy of the source-only sample here: http://code.msdn.microsoft.com/D3D9ExDXGISharedSurf
• CodePack_DirectX is a copy of the source-only codepack from here: http://code.msdn.microsoft.com/WindowsAPICodePack with two tiny modifications

The other two projects are the fun bits:

• SurfaceQueueInteropHelper (which probably needs a better name):  this is a mixed-mode C++ assembly that provides APIs to managed your D3DImage, resizing, surface lost/regained and rendering callbacks.
• WpfD2DSample: Normal C# application that uses SurfaceQueueInteropHelper and managed D2D (via CodePack) to draw a simulated scatterplot, providing pan/zoom/LOD, as well as (logical) hit testing of the D2D content and WPF overlays (which is made much easier with surface interop (vs. HWND interop)).  The piece de resistance would be to have a demo button that shows all of this working on the surface of a sphere or similar, but I haven't done that. :)

I think there's a lot more benefit to a .sln that you can unzip and run compared to a set of instructions like "Unzip this, then download the code pack, then make the following two changes, then import it into your sln, then...", etc.

Help me Obi-Wan, you are my only hope.

I have no idea what this all means, but I posted the solution .zip file here: http://robrelyea.com/demos/WPFDirect2DSample/WPFandDirect2DSample.zip

[Update: you need DirectX 9 SDK installed to use this sample.]

You like?

Interesting project from MVP Simon Ferquel now on CodePlex at http://WPFMetaEffects.codeplex.com.

WPF Meta-Effects makes it easier for shader effect developers to develop and maintain shader code. You'll no longer have to write any HLSL, instead of that, you'll write typesafe, compile-time verified and intellisense capable C# code, and the runtime translates it for you !

Perhaps Walt Ritscher should take a look at this?

During WPF’s first version (v3, of course) we considered building a porting tool to enable WinForms developers to easily migrate to WPF. We didn’t build that migration tool because:

• We thought that the UI paradigm changes didn’t deserve a simple port, and believed people shouldn’t just port their battleship grey apps to WPF, but they should rethink and upgrade their user experience.
• We were aware of the VB6 –> WinForms converter and had the impression that it cost a bunch, but didn’t provide great customer value.
• Tooling inside of Visual Studio for WPF was very early in development, compared to the very complete set of design services for Windows Forms.
• Our platform had many holes that WinForms developers would find lacking, with DataGrid, perhaps the biggest hole.

I was reminded of that first reason when I read “Extreme Makeover, Phone Edition: Comcast’s xfinity”…an example of a what a UI rethink for a new platform can do.

A couple of the other reasons have now changed:

• Visual Studio 2010’s WPF & Silverlight Designer experience is much improved, approaching WinForms productivity.
• DataGrid’s were shipped by several 3rd parties + eventually by our team as part of the WPF Toolkit for WPF 3.5sp1 and included in the box with WPF 4.

Interestingly, a MVP is working on a WinForms to WPF/Silverlight/WP7 Converter today. It may be a helpful tool, but it is an interesting question about what role it should play in your apps move to new UI platforms.

What do you think of the “port” vs “rethink” debate? What have you ended up doing with WPF/Silverlight/etc…

I just read Tim Anderson’s “Keeping track of Microsoft financials” where he boils down Microsoft financial performance to a simple spreadsheet and summarizes based on that. I like that approach. Focus on the results.

My key metric, overall, has always been: while we grow revenue -are we growing profit at a higher rate than we grow revenue? Is our business getting more efficient? Are we getting value from our investments/improvements? So I would just add 2 columns for % Change and a total row, like this:

Segment	Revenue	Change	% Change	Profit	Change	%Change
Client (Windows + Live)	4,415	967	28%	3,061	788	35%
Server and Tools	3,575	84	2%	1,255	31	3%
Online	566	59	12%	-713	-302	??
Business (Office)	4,243	-265	-6%	2,622	-134	-5%
Entertainment and devices	1,665	36	2%	165	206	??
	14,464	881	6%	6,390	589	10%

Quarter ending March 31st 2010 vs quarter ending March 31st 2009, $millions

Tim’s summary was: “Windows 7 booming, Office a bit slow prior to the release of the 2010 version, Online still draining money. Xbox doing OK. In other words, nothing much of interest.”

Now I notice that he used to use % changed, but the 2 question marks in the right column probably pushed him to just publish the change amount this year. E&D is out of the red now, and Online is deeper in it.

Hopefully, these next few quarters will fire on more cylinders with some coming releases…

For the real results and a conference call with analysts see http://micrsoft.com/msft

WOLVES Update

I’m very excited about the set of software we’re in the middle of releasing which I call “WOLVES”, which should only help our customers, and our shareholders.

• Windows 7
• Office 2010
• Live “Wave 4”
• Visual Studio 2010
• Expression Suite 4
• Silverlight 4

[There are other things that we’ve recently shipped or are about to ship, but this is the stuff I live in…]

We got a customer question about a change in behavior between WPF 4’s Release Candidate and WPF 4’s final version (RTM).

We discovered late in WPF4 a change in behavior since WPF 3.x that affected StaticResource lookup. In v3.x, we would always determine what a StaticResource resolved to (which exact value in which resource dictionary should be the answer to the {StaticResource} execution) during parse time.

We discovered in WPF 4 Beta1 until WPF 4 RC, we would determine the result more dynamically…which means differently.

We worked hard near the tail end of WPF 4 to put things back in a compatible place. For those people who did a bunch of coding on top of WPF 4 during WPF 4’s development, you may have been allowed to structure your XAML in certain ways that shouldn’t have worked.

Here is a write up from Brian (the XAML dev who spearheaded the fix) that may be helpful, if this bit you:

Forward Reference:

<ResourceDictionary>
     <Foo  x:Key=”AAA”  MyProperty=”{StaticResource BBB}” />
     <Bar  x:Key=”BBB” />
</ResourceDictionary>

RULE

StaticResource BBB cannot (should not) resolve forward to the x:Key=”BBB” entry.

Reason this is the right behavior

Forward references don’t work in XAML loaded as Text because StaticResources are executed when they are found and the key “BBB” is not present yet.

Why there is a problem

In the Compiled case the dictionary is read in as a big binary blob with a table of content so without counter measures the StaticResource would resolve to forward keys and we have an incompatibility with text and 3.5.

Reaching across Merged Dictionaries.

<ResourceDictionary>
   <ResourceDictionary.MergedDictionaries>
       <ResourceDictionary Source=”Xaml_1.xaml” />
       <ResourceDictionary Source=”Xaml_2.xaml”/>
   </ResourceDictionary.MergedDictionaries>
</ResourceDictionary>

RULE

StaticResource’s in Xaml_2.xaml cannot (should not) resolve to x:Key’s found in Xaml_1.xaml.

Reason this is the right behavior

Each “Source” is a separate XAML file load and the outer Resource Dictionary is not on the parse stack and thus the keys in the other Dictionaries are not visible to the StaticResource lookup.

Why there is a problem

In the Compiled case entries in Resource Dictionaries are read and loaded later and the when they are loaded the context can be “more loaded” and the keys are visible.   But this would be impossible to recreate reliability in all situations and would never work in Text load.

Injecting resources after Loading XAML.

RULE

Modifications to the Resource Dictionary made after InitializeComponent() should not affect StaticResource lookups.

Reason this is the right behavior.

In a text load all Static Resource lookup are at executed as they are found.  So following the text model (like 3.5) all Static Resource lookup will be finished by the time InitializeComponent() returns.   And changing values in application code should have no affect.

Why there is a problem

In the compiled case Resource Dictionaries are lazily evaluated when referenced (for performance).  And thus changes to the Dictionary (and parent dictionaries) can change the result of Static Resources lookup.   This is incompatible with Text loading and also very dependent on exactly when the lazily evaluation takes place.

The Fix to WPF

The solution to this problem as is so often the case was "more code”.  The evaluation of entries referred to by StaticResources are still lazily deferred, but the locating and binding to the location of the entries is done eagerly and at load time.  And if any of the entries are overwritten by application code, a copy is made to preserve the value the StaticResource should receive when it is eventually evaluated.   There is separate code to handle inline templates (templates defined outside of resource dictionaries), but the same principles apply.

.NET Framework Migration Issues that might be hit moving from 3.5sp1 to 4.0 are located:  http://msdn.microsoft.com/en-us/library/ee941656.aspx

A WPF link will take you to: http://msdn.microsoft.com/en-us/library/ee941656.aspx#windows_presentation_foundation_wpf

Our goal in WPF 4 (and .NET 4) was to limit breaking changes to only approved changes. Of course, we’ll discover some after we ship.

We want to ensure we accurately list all the issues that you hit for WPF 4, so this list grows to be more and more complete. Please let us know of any issues that aren’t accurately represented.

-WPF Team

I coded this last step a bit over a month ago, and I’ve just not had time to share it out. Yesterday, I reviewed the deltas from the Jan. 30th version I posted. They are summarized below.

The major work I added was the ability to show Silverlight 4 projects in XamlPad, in addition to WPF 4.

Several open issues as well, but I can clean up more next time, right?

http://robrelyea.com/demos/xamlPadSample links to source code download and the other XamlPadSample posts.

Changes in 2010-04-19 Version

Pad Project

MainWindow.xaml

• Set Window.AllowDrop to true

MainWindow.xaml.cs

• Added DragDrop event support to open files via DragDrop

XamlPadHelpers Project

AssemblyData.cs

• Don't attempt Assembly.LoadFile() if the file doesn't exist. This would happen if you used a XAML file from a project that hasn't been built.

ProjectData.cs

• Added an AssemblyResolve event handler, to better load assemblies. Look in loaded assemblies, if match, use that one.
• GetFileInfoFromRelativePath - support absolute paths in relativePath parameter
• Add empty else clause in case hintPath is ever null or empty.

View.cs

• Change property Type of type Type to be TypeFullName of type String.

XamlDocument.cs

• TODO - Why is xamlPadConfig ever null in FindOrCreateProject

XamlEngine.cs

• Added TransformXamlDocumentToRuntimeReadyString() - Does XAML to XAML filtering (removes events, x:Class, etc..)
• Changed LoadXamlDocument to create its own XamlObjectWriter to pass into XamlEngine.Transform
• Changed LoadXamlDocumentWithAppResources to create its own XamlObjectWriter to pass into XamlEngine.Transform
• Renamed LoadObjectsForDesign to Transform()
• stopped creating XamlObjectWriter, instead rely on call to create XamlObjectWriter or XamlXmlWriter and pass it in.
• xml:Base - if Silverlight project, only let one through
• Return null, require caller to harvest result out of XamlObjectWriter, etc…
• Changed WriteResourceProxyPreamble, WriteMemberValue, and WriteResourceProxyPostamble to use XamlWriter, instead of only XamlObjectWriter.

XamlPad.xaml

• Using non-attached *ScrollbarVisibility instead of attached versions (no effective change in behavior)

XamlPad.xaml.cs

• OnPropertyChanged() - In the silverlight project case, use SilverlightView to display content
• Note - which silverlight DLLs can be loaded is a bit of a hack now.
• TODO: use the SilverlightSchemaContext from XamlToolKit
• Loading themes\generic.xaml for default datatemplate for an object per referenced blog post

SilverlightView Project

• Silverlight 4 project which gets requests to load XamlString from host.

I’m happy to see Davide Senatore is publishing a WF2XAML converter! If you are interested in converting a WinForms (including Windows Mobile app < v7) to Silverlight, Windows Phone, or WPF – this looks very interesting!

• Latest blog post from Davide (about v.6 beta)
• Pointer to project web page

This week, on my rowing team, we are trying to come up with the final lineup for a Men’s 4+ for the Opening Day 2010 race. The top three seats are already chosen, 4 of us are competing for the 4th seat. In rowing, coaches often use “seat racing” to determine lineups. They basically have 2 boats with person A + other people in one boat and person B + other people in the other boat.

The coach races both boats for a 2 minute (or whatever) race and sees which boat wins and by how much. He then swaps person A and person B, reraces, and then compares the results.

Earlier this week we seat raced during practice. The racing wasn’t conclusive yet. We need one more practice of seat racing to finalize the boat. This is my second spring season back on the water. It would be exciting to be able to race in the Opening Day race!

Me and Opening Day

My wife and I met on the rowing team at the University of Michigan. When we moved from Chicago to Seattle in May 1998, our temporary housing doorstep had a Sunday paper with an Opening Day race picture on the front page. We were lucky to move to a city that had such a focus on rowing! I hadn’t rowed at all in Chicago for our 5 years there, but there wasn’t much opportunity to do it.

Then, here in Seattle, a city with many rowing clubs, I waited 11 years to pick up an oar again…

Update: The Results

I didn't get in the boat...but I now have even more motivation for practices, training, etc...

This has to be the biggest week yet for XAML. Our V4 era work on System.Xaml.dll in .NET 4, a reengineered XAML implementation in WPF 4 (that uses System.Xaml), and a new XAML engine in Silverlight 4 both are released within days.  In addition, we get improved support natively in VS 2010.

We’re doing planning now for future releases, always a fun time…I hope to dream big and bet big! At the same time, I have several unrealized dreams that I want to be able to go back and finish up.

Between releases, teams shuffle around, tweak the orgs, shuffle buildings, reconnect with customers, understand the reactions you have to the new product, and then start it all again.

Anyway, hope you like the v4 wave!

This twitter conversation happened the other day between mstrobel and myself: (read top to bottom).

Interesting question and comments. I’m eager, also, to ensure that Silverlight & WP7 both use XAML to its fullest. I’m reading Mike’s comments as:

• He wants to use Mono/Monotouch + XAML for IPhone development.
• He wants fuller support of XAML on Silverlight, including WP7. I imagine his top request is for XamlWriter.Save() support in Silverlight, including on WP7.

Love to hear feedback around these ideas…

Where will System.Xaml.dll be available? How much will Silverlight XAML get better?

Now, I’ve gotten requests for System.Xaml.dll to have support for .NET 3.5, Silverlight, .NET CF, and Mono. Right now, .NET 4 is the only planned release of System.Xaml.dll, but we’ll listen to your scenarios and feedback. I’d imagine that Silverlight and Silverlight on WP7 will both get additional XAML support, based on feedback and customer scenarios, as those releases iterate.

I’m very happy with our progress in Silverlight 4 that I commented on with “Silverlight 4 XAML Parser Overhaul”, and that David Poll and Jeff Wilcox blogged on in more detail.

Keep feedback coming, like the feedback that you listed back on “Silverlight XAML Developer Experience Issues?”

Filling a temporary (?) gap, Clarity Consulting posted a Windows Phone 7 Panorama Control in “Building the Elusive Windows Phone Panorama Control”