<head> web conference: October 24-26, 2008

10.09.2008

Access WPF Storyboard in XAML from code-behind (C#)

At more than one time working with WPF I've wanted to create a generic Storyboard using Blend because it saves me time and gives me a nice time line type layout to create/tweak my Storyboard. What happens is when you save the Storyboard it's added to the Windows.Resources collection the XAML. In Silverlight you can access these Storyboard resources directly using their x:Name value. In WPF, however, you need to do it slightly differently.


  • First, You need to specify x:Key for each Storyboard

  • Storyboards must be found using TryFindResource:

    Storyboard myStoryboard = (Storyboard)TryFindResource("myStoryboard");

  • TryFindResource will only work if the Storyboard is in the Window.Resources section of the XAML and you're in the code-behind of that XAML

  • Once you have the reference to the Storyboard contained in a variable you can call the various Storyboard methods on it. To run it, use the Begin method:

    myStoryboard.Begin();



Here is a quick code snippet to help you out.



Here is the XAML:

Labels: , ,

9.19.2008

WPF Full screen accross multiple monitors

I've been working on a cool instillation project for Microsoft and one of the things I need to do is have my application go full screen across multiple monitors. By default, if you maximize your application window inside Windows it fills the Primary Screen or Active screen but it doesn't go across all monitors. You have to manually drag the application window across to have it show up on more than one monitor. What if you wanted to make a screen saver for multiple monitors? Doing some internet searching I pieced together this little solution. Here is a code snippet that maximizes your WPF app window across all monitors in multi-mon setups. It also adds a listener for the ESC key to close the window down. Hope this helps people find this solution faster in the future.



Then in your XAML make sure you don't have any values set so the code behind can do it's thing.

Labels: ,

12.21.2007

Silverlight is the ugly stepchild of WPF

Silverlight is the ugly stepchild of WPF (Windows Presentation Format). Nearly all of the things that are not yet implemented and/or I need/would like as tools for building Silverlight projects work in WPF in some way. WPF appears to have been designed to create the ultimate interactive kiosk. It allows developers to make visually pleasing interfaces for their applications easily. It appears to me that WPF is where Microsoft's focus lies, and Silverlight is them taking WPF technology and trying to force the square peg into the round hole of the web. Not that the hole will be round forever, but that's a different story. However, I think Microsoft has failed to provide some major features that are expected in well designed web experiences and RIAs these days.


  • More than Media - Rich Media Applications are not just media players. Silverlight, does a great job of being a cross-platform media player, but web developers have come to expect MUCH MORE, including Alpha Channel support and pre-compiled content. Silverlight isn't delivering these core elements, at least not in a useful way. And some of these still won't be included in the 2.0 release.

  • File size - Doing some tests, I took some XAML and created a basic, no interaction layout and the XAML file was Ten Times (10x) as large as the same layout in a SWF. 224k (Silverlight, xaml) vs 22k (flash, swf). Quick downloads and instantaneous user gratification is expected these days. If you're site is slow, or takes forever to download users just go elsewhere. You can't afford to have bloated files, especially if they have less functionality.

  • Slick Design at run-time - vector art is nice, but that's so 2004. The new design pallet is bitmap graphics and filters. You need to have gradient overlays with drop shadows, filter effects and pixel effects (especially blending modes) that can be manipluated at run-time. This falls back to the file size issue. Sure I can create all of these elements in another program, but then the user has to download them. If I can create them on the fly, then I don't need to pre-render them. Now I know you could do this in realtime using javascript and vector data, but the code to do that is big, and as a designer/developer, I'd rather just be able to call a filter function and be done.


Perhaps it's just a work-flow issue for me at this point. I can see how Silverlight has the potential to do many of the things I mention above. All of those things can be done easily in Flash. Right now, it takes me 3 times as long to do things using the Microsoft tools vs the Adobe tools. Granted I'm familiar with the Adobe tools, and I've put the time into learning them, but when Microsoft's marketing speech is, "we've integrated the work flow between designers and developers," I can't help thinking, "I'm a designer/developer and my work flow is more convoluted than ever using your tools."

I'm looking forward to Silverlight growing up and moving out of it's parents house. I don't want it to be the ugly stepchild anymore. Competition is good for the marketplace. If Silverlight can get some market share, it will push both Adobe and Microsoft to create better products, which is better for me.

Silverlight 2.0 should provide a lot of useful features, but until the ones I mentioned above are on par or better than Flash, Silverlight will remain inadequate and noncompetitive in the real world. The buzz will die down, just like it did with the Zune, and Vista...and what's left could be ugly. Integrated software and tools will only get Silverlight so far if the final delivery is inferior to it's competition. Adobe is working its butt off to integrate the crap out of Creative Suite. It's not there yet, but it's close. What's Microsoft doing to create a better overall experience for the user as compared to Flash?

Time will tell. Now I have to go and slap the ugly stepchild around a bit until it does what I want.

Labels: , , ,