Microsoft Surface: What WPF Can Do For You

Today Microsoft announced the Surface, a new line of consumer products that turn "an ordinary tabletop into a vibrant, dynamic surface that provides effortless interaction with all forms of digital content through natural gestures, touch and physical objects. Beginning at the end of this year, consumers will be able to interact with Surface in hotels, retail establishments, restaurants and public entertainment venues." If the videos on the Surface website seem impressive, you haven't even scratched the surface yet. Using the real product is way cooler!

The Surface team has thus far been operating under the radar. I'm proud to say that the device runs a variant of Windows Vista and uses Windows Presentation Foundation (WPF) for its user experience. It shows how WPF can be a game changer when you exploit its power. It is understandable that the first generation of the product - shipping in the second half of 2007 - is out of reach of the average consumer, and is focused on businesses. I expect that in a couple iterations, component prices, usage scenarios and its economic network will work their way to the mainstream. We've seen that story before. These are good tidings for designers and developers; as Rob points out, this is a "nice device to leverage some of your WPF programming skills on!". This is a great time to pick up and hone those WPF, Silverlight and Expression tools skills.

Congratulations to our friends in the Surface team on the public unveiling of a fantastic product.

Email this | Bookmark this

View Source - Giving It Back with Silverlight

Much of my HTML, Javascript and CSS learning came by way of the View Source context menu option in Netscape Navigator and Internet Explorer with some tinkering on (the old) Geocities. My experience in that domain is hardly unique. And I had the opportunity to learn from the best; to sit on the shoulder of giants, as it were. I'd posit that the acceptance, popularity and ubiquity of the universal web is in large part due to that "openness" and the ethic of sharing. By keeping XAML in Silverlight a mere step away from your piqued curiosity, we're actively trying to make it easier to learn from the best.

Ernie Booth takes away what little remnants of pain existed on the newbie programmer's path to Silverlight nirvana with his excellent plug-in for Lutz Roeder's Reflector. Check out Ernie's post entitled View Source Reflector tool for .NET Silverlight sites. A must-have tool for the Silverlight developer.

Needless to say, should you care about protecting your IP, the tool doesn't circumvent any existing safeguards you have in place.

Email this | Bookmark this

We Popfly High, No Lie, You Know It

With what it states as "another piece in [Microsoft's] company-wide outreach in helping non-professional developers build everything from Xbox games to Robotics to custom Web applications using Windows Home Server", Microsoft today announced a new service called Popfly.It comprises a set of online visual tools so non-programmers can create web experiences, and a social aspect involving a community watering hole where people and view, share, remix and rate content. And did I mention Popfly was built using Silverlight? Popfly is currently accepting limited participants for its private alpha.

Personally speaking, Soma's and John Montgomery's talk about extending tools like Visual Studio to the Live world, is starting to make sense. Of course, this is just a step in that direction. John was kind enough to give us on the Silverlight team a sneak peek at Popfly at a Friday Beer Bash some weeks ago. As a fan of UNIX Pipes programming paradigm, I was immediately fascinated by some aspects of the Popfly Creator. We'd have loved to have shown this off circa Mix 07, but John and team rightly were looking at Maker Faire as the correct avenue to showcase this.

See one such Popfly creation in action here.

Email this | Bookmark this

Namescopes in Silverlight

When you start naming things, you quickly realize that you need a method to disambiguate or resolve conflicts between names. When your sister cried out "Mom! Pete flushed the goldfish down the toilet!", your mom knew the "Pete" your sis was referring to was you, not the kid down the street. That's because she used an implicit name scope to infer.

What is a name scope?
Nick Kramer describes a name scope or namescope thusly:

"In almost all programming languages, names are not globally unique, they are unique only relative to other names in the same name scope. In C++ and C#, a name scope is roughly what goes between curly braces -- { }. And in C++ and C#, namescopes nest -- if the compiler can't find the name in the nearest namescope { }, it will look in the containing namescope.

Xaml names have many of the same issues. In <Button Name="foo">, foo is not unique to the whole program, there could be other xaml files with the same name. And you can instantiate that xaml file multiple times (e.g., multiple windows). "

Nick goes on to explain the role namescopes play in WPF. They kinda play a similar role in Silverlight.

Okay so we now know that a namescope is a logical grouping of named elements. Further, the "root" or ownership of a namescope is tied to a specific element and all of its named children fall into that namescope unless a child defines another namescope. This element is considered having the ownership of the namescope.

When do I care?
A namescope is typically created when the root visual is set. Well, in Silverlight there's a couple ways you, the app developer, can create elements in a separate namescope. One way is through a createFromXaml call in Javascript where you set the last parameter to true. The other is when you instantiate a Silverlight 1.1 Alpha control (see the SDK). In the latter case, the ControlBase class constructor makes a call to InitializeFromXaml in System.Windows.Controls.Control - which in a way is the managed equivalent of making a createFromXaml(xaml, createNamescope) call. You can use that approach for your custom controls.

Update: And oh, you also care when you do a FindName(). That method only walks the tree in the namescope of the element on which FindName was called. For instance, of you do rootCanvas.FindName("someElementName") you're searching for "someElementName" in the namescope of the rootCanvas element. Another element with the same name but different namescope is invisible at this time.

What types of namescopes exist?

The namescope created with the root visual is called the default namescope. When you call createFromXaml and tell it to create a namescope this is called a private namescope. If you call createFromXaml and do not create a namescope a temporary namescope is created

All elements content created in the visual tree will reside inside the namescope. Names defined in the namescope will not conflict with other names outside of the namescope.

Default namescope
A default namescope is automatically created when the root visual is created. The default namescope can be replaced by resetting the main visual tree.

Private namescope
A private namescope is the permanent name scoping that is created. A private namescope has the restrictions mentioned earlier in that it cannot be dissolved – it is always associated with the element that owns the private namescope. Named/un-named elements can be added/remove from the private namescope though.

Temporary Namescope
A temporary namescope is created any time you call createFromXaml and have an element tree fragment not associated with the main tree. A temporary namescope is different from a private namescope in that when you add the element tree fragment to another tree the temporary namescope is dissolved. This "addition" can be by using a collection's Add method or by setting a property such as a Rectangle's Fill.

Email this | Bookmark this

A Layout System and Containers for Silverlight 1.1 Alpha

Dave Relyea's first blog post showcases some work he'd been recently doing to build a layout system, several layout containers and some layout-aware controls -- all in user code. Ooh, but that's not all. Dave cranked up a pretty cool TextBox control as well. See Silverlight 1.1 Alpha Layout System and Controls Framework.

You can use this until the Silverlight 1.1 platform natively supports layout and editing (which is... soon).

Email this | Bookmark this

New To Programming?

Microsoft's Beginner Developer learning center has great resources for beginner programmers intending to learn web and desktop programming basics. There's also a Kids Corner.

Email this | Bookmark this

Silverlight UI Controls

Update [Apr 2009]: The post below is now obsolete. There is now a great ecosystem of UI controls for Silverlight. You can start with the Silverlight Toolkit, a Microsoft provided collection of Silverlight controls, components and utilities made available for your development with a permissive license (MSPL). Besides, there are excellent controls from ComponentOne, Telerik, Infragistics etc. There's also some good documentation on Silverlight Controls on MSDN.

-----

If you've played with Microsoft Silverlight 1.0 Beta or 1.1 Alpha bits, you've no doubt noticed that while there's Canvas, TextBlock and other such controls, there is no Button or ListBox or even layout elements like StackPanel or Grid. Rest assured, your UI development needs are always on our mind.

If you download the Silverlight 1.1 Alpha SDK, you'll see a UI controls package in there. You didn't think we'd leave you in the lurch, did you? Although it is very easy to whip up a Button control with XAML and some code in Silverlight, that detracts from your app building. To address this, we've released a modest set of controls in the Silverlight UI Controls package. These include:

• Button
• ScrollBar
• ScrollViewer
• Slider
• ListBox

Also included are a couple primitives like RepeatButton, Thumb and GripThumb.

All of the controls in that package are managed code controls i.e. they rely on Silverlight 1.1 Alpha and the CLR and Silverlight framework in it.

These controls currently sport the Silverlight "Dawn" look and feel. We're releasing source code for these controls so you can modify and customize them as appropriate. There is a readme file with additional information and the code is peppered with comments, all which the agile diehards are free to ignore, 'cause the code is the documentation. The control behavior is in C# code-behind files, while the control templates, i.e. the visual aspects governing look and feel, are in XAML markup files. Another example of separating UI from behavior, as architecture astronauts have been telling us since the dawn of time.

Controls such as ScrollBar, ScrollViewer, ListBox and Slider are composed of other controls. We picked this mix because it accentuates the diversity of the control set and allows you - the designer or developer - to look at the source code and understand the Silverlight framework, the inter-dependencies between controls, and not to mention, the quirks in the control set arising from some features being absent in the 1.1 Alpha.

Please use these controls in your applications targeting Silverlight 1.1 Alpha. In fact, it should be pretty simple to take the XAML pieces, tie in some JavaScript and have all of this run on 1.0 Beta. But I'll leave that to the community.

As always, direct comments and bug reports on the UI controls to the Silverlight Forums. If you have questions about the control roadmap or other considerations made while developing this set, drop me a line here.

Email this | Bookmark this