In my earlier post I walked through my favorite Cider beta2 features. 

You might have noticed that I focused on 'developer' features like laying out controls, wiring up events, and XAML editing. I skipped other 'designer' tasks (like styling, templating, animation, etc.) that you would need to create a stunning app .   
The reason I skipped them is because the features required for these tasks  are not in Cider v1;  you can definitely implement all of these tasks by just typing XAML in the XAML editor, but that is not the highly productive RAD approach you get out of Expression Blend,  so my reccomendation is that you use Blend for this. 

Here is what I consider the sweet spots for each tool (based on my experience, this is not the official opinions from either team ):

• Cider:   Layout,  Hooking Events and code-behind, XAML editing,  Debugging,  Deployment, version control integration from IDE.
   
• Expression Blend: Layout, templating ( both controls and data ),  Animations, Triggers, basic 3D Viewport manipulation ( camera, rotations, etc.), basic vector/path drawing (arguably better done in Expression Graphic design), and wysiwyg transformations..

So, to build an amazing wpf app with out compromising productivity and maximizing ease of you, you will have to use both tools..  If your immediate reaction was "argh, two tools!" I  reacted that way at first, but having done it for last few weeks, I got a little bit less irritated...  here are some of my personal takes/experiences/predictions  around this subject:

• There is no hidden agenda behind current state;  this is simply the result of "only so much time, must prioritize features " .. rest assured all our teams are looking to provide best integration and as many features as possible across each tool... so you should expect the 'sweet spots' for each tool will grow and the tools willl overlap more and more in future releases.  
• On more overlap, we should acknowledge that it is nice and definitely a goal to keep the tools optimized for roles; VS2008 will continue to optimize for developers, and Blend will continue to optimize and target designers.  
•  Another thing to highlight is that the teams have done all the leg work for seamless integration: they share projects, they share solutions, they share xaml files,  they share as much design-time extensibility as possible given they shipped at different times, etc.
• A non-technical argument is cost; this is out of my realm so no roadmap there but I do know that:
• Expression Blend is included in MSDN so a large number of developers will get it for free ( if you are a developer who does not subscribe to MSDN you should look into that, it can likely save you $$).  
• If you are a designer, then you should know there are free versions of Visual Studio (called Express) that you can use to complement Blend ( e.g. for debugging).

I am clearly not in marketing so likely a better way to show you the seamless integration between the tools is to walk through a brief screencast as I did in part 1.  Here is a 10 min screencast showing (briefly, not in full) how you can change a few templates and triggers in  the 'bare browser' we created in part 1.

We have walked through the cider features, we have discussed its integration with Blend and the sweet spots for each tool ...  to most users that is plenty, but there is a side to Cider that eventhough you might not see a lot is very important for the ecosystem and our long-term vision for Rapid development of WPF apps: the design-time extensibility.

By example, extensibility refers to:

• Providing hooks (or APIs) so you can check if your code is running inside the designer -- for example at design-time, you might not have access to data that your app expects.. or at design-time you might want your controls to not animate or play video as soon as they are loaded (when at run-time you might want that)..
• Support for licensing  ( so control vendors can sell you a control that makes your life easier)
• Support for custom property editors ( say you bought that control from a 3rd party), making it as easy as possible to set the right properties so the control is configured for run-time is obviously a goal of the tool vendor or framework vendor..

For this part, I don't have a screencast or  a write-up because Jim Nakashima recently posted his TechEd session on Designer Extensibility ....  Every thing you need (or more than I know) is covered there and I can't say it any better so let's give him the floor ..

Jim also posted his code samples for the session .

------

This closes the Cider series..  Let me know if I missed some thing that was important to you.    

A few customers developing in 1.0 have seldomly seen the 'unresponsive script' warning   in firefox...

They see it less often in IE,  but if you create a run-away thread it can be reproduced in IE and it shows it as "Stop running this Script" .. .. "your computer may become unresponsive" ... blah..

The error is not new, a simple search online for 'unresponsive script firefox' or for dom.max_script_run_time  yields plenty of posts and a few tips...  but since Silverlight is new, first thing that customers are wondering is whether this is caused by silverlight -people ask about the animation engine in particular-..  Every time a customer asked I wrote one or more very different tests to make sure it is not thrown with long running animations or a lot of drawing time in silverlight. My experiece so far has been that the warning was not triggered due to silverlight's time (animation or drawing);  the warning also does not repro with long-running .net code in Silverlight 1.1  so if you are running into it check into your script ... i think the warning is really referring to the script time..  

To get around the error,
1) The posts on the web suggest you change  the value for dom.max_script_run_time  ..  [which works for devs but is a little harder/impractical to get customers to agree to] or you can
2) Get down with your Javascript do some profiling and optimize it .. .

So far, I have been choosing the latter... basic profiling using firebug has yielded the needed places to tweak code and get over the warning; hopefully that will work for any one else running into it.. 

The other follow-up question I have been hearing is 'can this be enabled/disabled programmatically from my website or my script' ? I believe (with confidence, but not fact since it is firefox) the answer to that is No -- that would lead to an exploit-.   If there is so much work that the warning is stil firing after you have optimized your script then partition your code into several execution script blocks ( use window.setTimeout to schedule the blocks)..

 Hope this saves some one some research time...  :) 

Seema shares some of her lessons learned towards  minimizing CPU usage in silverlight .. 
http://blogs.msdn.com/seema/archive/2007/08/09/silverlight-a-few-thoughts-on-minimizing-cpu-usage.aspx

I can vouch first hand for her first two as big winners...   There are some extra tips in the RC docs: 
http://msdn2.microsoft.com/en-us/library/bb693295.aspx

One last tip: test perf on both Mac and windows (Xp plus Vista). there are slight variations..

 If you have better tips.. please leave comments :)

A belated follow-up to an earlier post about Cider...    Will try for a brief series that discusses:

1. What's new in Beta2 ... (  lotsa new features, check details below )
2. How to build a WPF app using Cider AND Blend ...  ( sweet spots for each tool,  brief demo of the workflow) ..
3. Cider extensibility and features for control hosting, design-time, etc..

The 'features' screencast is available from Channel 9. It is ~10 mins of features  + 10 mins building sample app.. 
Some of the new features in the screencast you should watch out for: 

• IDE/project stuff:
• Templates for WPF apps  (no more extensions)
• Remembers my preferences on how to always open a XAML file; if I choose Design Surface or XAML editor it remembers (per file-per-project)
• User control support
• Property windows, categories, etc.
• Wiring up events from the designer ... One click :) 
• Layout
• Grid support with adorners
• Panels ( StackPanel, DockPanel, etc.)
• Snaplines
• Guideline adorners for alignment
• Navigation
• Selection Sync  ( Designer, editor, property window are always in sync.. )
• Document Outline
• Visual Preview
• XAML Editor
• Reflection based intellisense ...  (yes, that means non-schema based)
• Intellisense for mapping  xml namespaces
• Sync selection from within the editor
• Better perf than previous build..
• Navigate to event handler

Please check the screencast,  and let me know if I missed some thing you like..  If there is some thing you don't like, provide feedback...

The new high definition live action videos for Halo3 are  available in Silverlight at http://halo3.msn.com/videoshd.aspx . 

My observations:

Am I the last one to find this really useful blog with lotsa good VS tips? 

Try your VS knowledge on it.. How many of the tips did you know??   I knew about 60% ... but did not know of some really juicy ones (like swapping words via Ctrl-Shift-T .. .

if you go there and you knew every single tip let me know...  that would be worthy of a prize --  like a T-shirt that said "I BSed jaime" ...

As usual I am late -- or did not intent to do it at all -- breaking news on silverlight and in this case the MLB deployment..  ( infoworld ,   zdnet)

Changed my mind to share my point of view on two questions I have heard a bit this week..  why did they use silverlight? and why are they delivering a small subset compared to the great vision they showed at MIX?

For context, I have had the pleasure of meeting the MLB team. I would describe them as:

• Very bright and talented people.
• Very passionate baseball fans; huge respect for the game and their content, and the fans (their customers).  

So why this Silverlight hoopla? I do NOT have the MLB answer; but my personal experience from hearing their asks on the platform is that the best media experience has been their highest priority; best quality video, optimized bandwidth, more data in the stream, etc..

To be candid - and shamelessly plug the Silverlight value prop- my initial theory about the why was 'they already embraced Windows Media (WMV) in their impressive Premium Video Player (known as Mosaic); if Silverlight can get them the best branded, interactive experience in the web and they can move from FLV they would likely save (transcoding) time and money as well as save on delivery costs". It might be still a good/fair guess.. but so far just a guess ..

Around why you are seeing a subset of the vision presented at MIX?  patience ;)
They serve  a lot of content 24x7-  testing a new player is not an easy feat. If Flash and silverlight co-exist fine on their website today,  there really is no need to 'rip and replace' in a rush; it should be done where it makes impact or as new features are added (e.g. mail to a friend this time around).   It might not excite the journalists or geeks looking for technology stories using the words 'drop' or 'killer' in the announcement, but  who cares?? This baseball fan seemed happy with the new player and his ability to see WMV from his mac. 
 
That is my 2c on those topics--emphasis on MY, I don't speak for MLB but you can try to read MLB's why from their keynote demo at visitmix.com; while setting expectations, a reminder that the mobile bits were real in the demo, but there is no immediate commitment from MLB to a mobile app in silverligh since Microsoft has not announced timelines for silverlight on mobile..

My belated take overall: congrats to the MLB and SIlverlight team for this first (MLB) deployment; I hope we get to see more later..