03.05.08

Mix ‘08 Report

Posted in Silverlight, WPF at 4:21 pm by TalynOne

Mix is an annual event held by Microsoft to showcase and introduce their latest web and designer development technologies.

It’s being held right now (March 5-7) in Las Vegas.

I recommend watching the Key Note which has great demos showcasing IE 8 Beta 1, Silverlight 2 Beta 1, Silverlight for Windows Mobile and Nokia devices, and upcoming enhancements coming in a service release that builds on top of .NET 3.5/VS 2008.

Here’s some interesting news (updating as news comes in):

Internet Explorer 8 Beta 1

  • Video: First Look at IE8 Activities and WebSlices
  • Available for download now
  • It’s recommended that you don’t install this on any production machines. It’s best to try beta 1 on a test/virtual machine. You can get Virtual PC image of Windows XP SP2 with IE8 : HERE.
  • IE8 will overwrite IE7. The browser does have an IE7 mode (who knows how well this works, since this is a beta version). Uninstalling IE8 beta 1 should restore your previous (IE7) installation, though your browser settings/preferences may be reset.
  • Beta 1 doesn’t pass ACID2 Test. Though there is rumor that an internal build does pass it. mritche says that the reason IE8 doesn’t pass ACID2 is because it makes a cross-domain reference that the security model in IE8 doesn’t appear to allow right now.
  • Per-site ActiveX controlled via the UI, registry, or programmatically within the control itself.
  • Non-admin ActiveX on Vista so (1) you don’t need to elevate to install controls that don’t need it and (2) their scope is limited to that user rather than the whole system.
  • Loosely-coupled IE - this puts the main IE frame and tabs in separate processes so that if one tab crashes it doesn’t take down everything else. There’s a lot more asynchronous calling happening behind the scenes which should make IE8 feel ’snappier’ (caveat: when in IE8 mode performance was not that great for me, as you’d expect out of a beta, but I notice things are more responsive under IE7 emulation).
  • Automatic crash recovery so that if a tab crashes or hangs, it can be restarted without losing your work. For more serious failures, it’ll restore your set of tabs if the frame dies.
  • Check out/contribute to the Microsoft IEBlog.

Silverlight 2 Beta 1

Upcoming .NET Framework/Visual Studio 2008 Enhancements

  • Support for writing custom WPF shader effects, hardware accelerated through the GPU for low CPU utilization. Can can be applied to videos, images, buttons, etc..
  • Improved .NET Framework Setup for Client Applications (easily bootstrap a .NET framework install)
  • Faster cold start times. Depending on the size of the application, .NET applications are expected to realize a cold startup performance improvement of between 25-40%. Applications do not need to change any code, nor be recompiled, in order to take advantage of these improvements so the benefits are automatic.
  • Hardware accelerated WPF DropShadow and Blur bitmap effects (previously software rendered, APIs wil stay the same).
  • Substantially faster Visual and DrawingBrush performance.
  • Faster media and video performance.
  • New WriteableBitmap API (enables real-time bitmap updates from a software surface).
  • Container recycling and data virtualization support (for data scalability)
  • Planned (later this year) release of a number of new controls for WPF. Included in the list are DataGrid, Ribbon, and Calendar/DatePicker controls.
  • Servicing update of VS 2008 that includes a number of feature additions to its WPF designer. These include event tab support within the property grid for control events, toolbox support within source mode, and a variety of other common asks and improvements.
  • Detailed Info : HERE

Other links of interest:

  • Mix University - Get your learn on through videos and exercises covering Silverlight, WPF, ASP.NET AJAX, Gadgets, Expression, Internet Explorer Extensions, Media Center, RSS, Virtual Earth, and Windows CardSpace.

06.23.07

Future Plans for Silverlight

Posted in Silverlight, WPF at 3:03 pm by Cal

I would just like to emphasize one aspect of Alan’s report on the Silicon Valley Remix07 event. About half way down the report are three photos which both of us agree are near the top of the important news coming out of this meeting.? The slides depicted in the photos show what Microsoft’s plans are for the future development of Silverlight.

? As everyone who has tried to work with Silverlight knows, one of the initial barriers to success is the limited support for WPF controls and other WPF features.? These slides show how ambitious are Microsoft’s plans to include a much wider collection of features in the upcoming Version 1.1 release of Silverlight expected for later this year.? Notice, for example, how most of the important basic controls are scheduled for inclusion in the next version.?

? Anyone interested in where Silverlight will be going over the next year would do well to study these slides carefully.?

ReMIX07 in Silicon Valley - Silverlight is Hot

Posted in Silverlight, WPF at 2:46 pm by Cal

Alan Cobb

Reported by Alan Cobb

www.alancobb.com

I (Alan Cobb) and Cal Schrotenboer attended Microsoft’s ReMIX07 event in Mt. View, CA yesterday 2007-06-22. The talks I liked best were the keynote by Scott Guthrie (Microsoft General Manager of the development teams who build the CLR, WPF, Silverlight, ASP.NET and IIS, among others: http://weblogs.asp.net/scottgu) and the Silverlight technical drill-down by Tim Sneath (Microsoft WPF/Silverlight evangelist: http://blogs.msdn.com/tims/)

Scott Guthrie Demos His Chess App
Scott Guthrie demoed a chess application which included one mode which pitted .NET against Javascript. Since .NET excutes much faster than Javascript to the great pleasure of the audience it always wins each chess match.

Tim Sneath Explains Sivlerlight
Tim Sneath gave a very convincing explanation of the importance of Silverlight.

What evidence is there that Silverlight is “hot”? The original MIX07 last month in Las Vegas focused on the introduction of the Silverlight 1.1 alpha with its support for C# and .NET running in the client browser. That event sold out its 3000 seats several weeks in advance. Because of that sell-out and the enthusiastic response of the attendees, Microsoft decided on the fly to schedule additional ReMIX07 events to capitalize on the buzz. This ReMIX07 in Mt. View was one of those “overflow” events.

Tim Sneath’s slides showing the latest planned feature list for Silverlight was a technical substance highlight.? His slides compare the features for Silverlight 1.0, 1.1 and the full desktop version of WPF.

Silverlight Feature Plans - Controls

Silverlight Feature Plans - Layout

Silverlight Feature Plans - Other

Cal and I were elated when we had the chance to talk directly with Tim for an extended time in a small group after his presentation was done. On a personal level, I’m struck by how unpretentious and personally “likeable” both Tim and Scott seem.

Tim Sneath Explains Sivlerlight to Cal
Tim Sneath explains Silverlight to Cal

06.17.07

XBAP Greeting Card by Alan Cobb

Posted in WPF, WPF Animations, XBAP at 3:27 pm by Cal

Alan Cobb

www.alancobb.com

Alan is a friend of mine from Sacramento who is taking my Spring 2007 WPF class. I knew before Alan took this class that he was a talented developer but I had to raise my eyebrows when I noticed that he consistently scored 100% of all of the tests. I’ve been teaching for quite a while and I can assure you that that doesn’t happen very often.

I asked Alan if instead of the regular lab assignments he would mind working on a Greeting Card project which I could then incorporate into one of my MSDN webcasts (coming up on June 21st). The format which Alan chose was an XBAP application. He decided for the first project to create a baby announcement. After digging through my collection of 70,000 digital photos I selected a baby picture which I took last summer of the daughter of a couple of my friends from the Netherlands.

Alan’s Greeting Card illustrates quite a few WPF features including several different animations and audio. For a complete list of features illustrated, see the Documentation page.

06.16.07

Is WPF Really Resolution Independent?

Posted in WPF at 9:20 pm by Cal

One of the main claimed benefits of WPF is “resolution independence”. Often this benefit is described in relatively vague terms leading people to believe that it means that the same WPF window will display on any monitor at the same size regardless of the resolution at which that monitor is set.
Screen Resolution Setting
For example, one might imagine that if a user originally sets his monitor to a resolution of 1280 x 960 and later changes it to 640 x 480, a WPF window which was originally sized at 4″ x 4″ at the higher resolution should still display at that same size even after the monitor’s resolution has been changed. Unfortunately, a simple experiment will prove that this interpretation of “resolution independence” is not correct.

Another potential interpretation of this term is that a WPF window will display at the same size regardless of the monitor DPI setting. Right click Desktop, Properties, Settings, Advanced. On this property page you will see a combo box which is typically set to “Normal size(96 DPI)”.
DPI Settings
Other options (at least under Windows XP) are “Large size (120 DPI)” and “Custom setting…”. One might reasonably hypothesize that since resolution independence evidently does not refer to the actual resolution at which the monitor is set (1200 x 960 vs. 640 x 480), that perhaps what is meant that a WPF window will display at the same size regardless of what DPI setting this property is set too. Again, unfortunately, another simple experiment will prove that this interpretation of “resolution independence” is equally invalid.

As it turns out, Microsoft was not really lying about the resolution independence of WPF. It is just that the explanation of what is meant by this term is a bit more complicated. The following experiments do indeed show that WPF is actually resolution independent.

We’ll do our verification by running a WPF test app on two systems with LCD displays that have different physical pixel sizes. The test app simply draws a 4 inch line whose length we will verify by putting a physical ruler beside it on the screen. The two test systems are as follows:

System 1: Desktop LCD monitor:
Screen width x height in pixels: 1600 x 1200
Screen width x height in inches: 17.0 x 12.75.
Therefore it has 1600 / 17.0 = 94 physical pixels per inch (physical DPI) horizontally and 1200 / 12.75 = 94 physical DPI vertically.

System 2: Laptop with LCD screen:
Screen width x height in pixels: 1400 x 1050
Screen width x height in inches: 12.0 x 9.0.
Therefore it has 1400 / 12.0 = 117 physical DPI horizontally and 1050 / 9.0 = 117 physical DPI vertically.

The key here is that the desktop monitor’s pixels are 25% larger than the laptop’s. (117 / 94 = 1.25)

Before doing the tests we need to review some terminology. While a classic Win32 app uses coordinates with units of “physical pixels”, a WPF app uses coordinates which are expressed in “device independent units” (DIUs we’ll call them here). One WPF DIU is defined as 1/96 of an inch. This definition of units allows WPF coordinates to be specified in inches rather than physical pixels. So a third possible interpretation of the term “resolution independence” might be that the same WPF application would display at the same size on two different monitors set to the same resoultion (1024 x 768 for example), regardless of the size of their physical pixels. Under this theory a dialog box that is 4 inches wide on System 1’s 94 physical DPI LCD should still be 4 inches wide on System 2’s denser 117 physical DPI LCD.

Unfortunately, the initial results of my experimentation seem to be at odds with this hypothesis. The following photos show that a line which is 384 DIUs wide actually displays at 4.08″ wide on my desktop monitor and at 3.28″ wide on my laptop monitor. Neither monitor achieves the desired result of displaying a 384 DIU long line at 384/96 = 4.00″.

Comparison of Two Monitors at 96 DPI

The correct explanation, however, lies in a careful analysis of the interaction between two important display properties settings. The first is the screen resolution setting (eg. 1024 x 768) and the second is the “Advanced / DPI setting”. (See images above.) Both of them act as “scale factors” that let individual users force everything on their monitor to be displayed either bigger (for easier reading) or smaller (for more desktop real estate).

We can eliminate the first scale factor from our tests by requiring that the “screen resolution” be set to the “native resolution” of the system’s LCD display. Since System 1 has a physical resolution of 1600×1200 pixels we must assure that its screen resolution has been set to the same 1600 x 1200 pixels. In the case of System 2, the corresponding setting is 1400 x 1050.

The second scale factor, the “DPI setting”, is what we will vary in our tests. WPF doesn’t independently know what your monitor’s actual physical DPI value is. Instead WPF uses the current setting of this second scale factor the “DPI setting”. If the “DPI setting” does not match the true physical DPI, then WPF’s “resolution independence” will appear to break — although it really doesn’t.

Now let’s examine our full test results. We’ll begin with the 94 physical DPI desktop LCD.

Test Photos of Desktop LCD

For the first test we’ll use Windows default “DPI setting” of “Normal size (96 DPI)”, which is what most people use. The photo shows the line which we expect to be 4 inches actually measures 4.08 inches, which is 2% off. Why? Because our LCD only has a physical DPI of 94, but the “DPI setting” scale factor is telling WPF to act as if we have a 96 physical DPI display (also 2% off from the real 94 physical DPI).

Next let’s try tweaking the “DPI setting” to make everything larger and easier to read. For that we’ll change it to “Large size (120 DPI)”. Now the line we might have expected to be exactly 4 inches long actually measures 5.10 inches. Again the explanation is that we are “lying” to WPF about our monitor’s DPI. WPF acts as if it is running on a 120 DPI screen when in reality the physical DPI is actually only 94. The distortion ratios still match exactly: 120/94=1.28 and 5.10/4.00=1.28. Both are 28% off.

Finally we will try the rule suggested earlier. We’ll make a custom “DPI setting” of 94 DPI so that it matches the 94 physical DPI of this LCD. At last success! Now the photo of the ruler against the screen shows we are rendering a “4 inch” line that truly is exactly 4 inches long.

Having successfully explained all the test discrepancies for the 94 physical DPI desktop LCD, now let’s switch to the laptop LCD which has a physical DPI of 117 to see if the same experiment with this monitor will give us the same result.

Test Photos of Laptop LCD

For the first test we’ll again use Windows default “DPI setting” of “Normal size (96 DPI)”. This time the photo shows the line that we expect to be 4 inches actually measures only 3.28 inches, which is 18% smaller. Why? Because our LCD has a physical DPI of 117, but the “DPI setting” scale factor is telling WPF to act as if we have a 96 physical DPI display. Again the distortion ratios match exactly: 3.28/4.00=0.82 and 96/117=0.82. Both are 100-82=18% off.

For the final test we will again try the rule suggested earlier. We’ll make a custom “DPI setting” of 117 so that it matches the 117 physical DPI of the laptop’s LCD. Again the rule works! Now the photo shows our app is rendering a “4 inch” line that truly is 4 inches long.

In conclusion, we’ve seen that WPF really is resolution independent as long as Windows display properties scale factor settings are properly taken into account. What WPF Resolution Independence really means that two monitors set to their native resolution and which are accurately reporting their DPI settings to WPF will display the same WPF window at the exact same size. Under those conditions a monitor with 96 physical pixels per inch will display any WPF window at the same size as a monitor which has 192 physical pixels per inch. The only difference between the two is that the latter monitor will look much sharper than the former.

06.02.07

Giving your WPF Application Docking Capabilities

Posted in WPF at 5:35 pm by Cal

CIS-019M (Spring 2007) Blogging Assignment

Contributor: Alek Davis

Alek Davis
Alek’s Blog

Docking different elements in a WPF application can quite easily be accomplished using a WPF DockPanel container. However, it is much more complicated to give your application the capability of letting users dock various floatable windows at different locations around your application.? As developers we are all familiar with this latter type of capability as provided by Visual Studio.?

WPF Application Docking Capabilities Screenshot

A member of The Code Project community recently posted a sample project illustrating how to implement docking windows in a WPF application. This sample project is called WPF Docking Library and can be found at the Code Project. This sample does not rely on Win32 interop and implements all of its functionality using WPF. It consists of two projects: a library which implements these docking features and a separate WPF application which demonstrates how this library can be used. Both projects are written in C#.

The docking library in the DockingLibary project consists of several classes, the most important of which is DockManager. DockManager is a custom (user) control responsible for arranging docking windows over which it has been given control. You can define a DockManager control in the application window either using XAML or programmatically. For example, you can embed DockManager in a DockPanel in the application window’s XAML file (notice that you must first reference the DockingLibrary namespace)

<Window
? ? ? ? ? ? ? x:Class=”DockingDemo.MainWindow”
? ? ? ? ? ? ? xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation“? ? ? ? ? ? xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”
? ? ? ? ? ? ? Title=”DockingDemo” Height=”500″ Width=”500″
? ? ? ? ? ? ? ? xmlns:custom=”clr-namespace:DockingLibrary;assembly=DockingLibrary” …>
<DockPanel>
<Menu DockPanel.Dock=”Top”>
…
</Menu>
<custom:DockManager Name =”DockManager”/>
</DockPanel>
</Window>
Once you create a DockManager object, you can add dockable windows to it by calling the DockManager’s AddContent method. AddContent takes two parameters: the window object and? a dock anchor location (either Dock.Left, Dock.Top, Dock.Right, or Dock.Bottom). AddContent can dock any type of control derived from System.Windows.Window as well as objects derived from the DockingLibrary’s ManagedContent class (ManagedContent is a simple wrapper class that contains a Window object), such as:
// dockManager is a DockManager object.
// TreeViewWindow is derived from Window.
TreeViewWindow explorerWindow = new TreeViewWindow();
…
dockManager.AddContent(explorerWindow, Dock.Right);
Note that only those windows (or other types of objects which are derived from the DockingLibrary’s ManagedContent class) which have been added to the DockManager’s Content property can then be manipulated by a user of the application.?

DockManager implements docking with the help of the Pane class which is used to represent a dockable window. A Pane object holds one or more ManagedContent objects and can be docked to any of the four sides of the parent DockManager. In addition to Panes, DockManager can dock a DocumentsPane-derived object holding tabbed document windows (these windows cannot be docked outside of the DocumentsPane). To add a? new document window, DockManager uses the AddDocumentContent method, for example:
// docManager is a DockManager object.
// DocumentWindow is derived from Window.
DocumentWindow doc = new DocumentWindow();
…
dockManager.AddDocumentContent(doc);

DocManager maintains its window layout with the help of an algorithm that manages the relationships between docked windows. This algorithm arranges the windows as a logical tree, where each node contains a group of two Panes or a Pane and a child group separated by a vertical or a horizontal splitter. To arrange the windows, DockManager uses the DockingGrid class (also implemented in the Docking Library), which creates a WPF grid for each group using either two columns or two rows, depending on the split orientation.

The DockingDemo project (included with the Source Code) uses the WPF Docking Library to arrange four sample dockable windows. These dockable windows can be rearranged by the user using standard drag-and-drop. When dragging a window, the application displays anchors pointing to the areas where this window can be dropped.

The Docking Library is not extremely complicated to use, but I believe that it would be much easier to understand if it contained more extensive comments. Also, I noticed that Visual Studio cannot display any window which holds a DockManager control in the VS designer (it complains about not being able to locate the DockingLibrary assembly). This seems like a limitation of Visual Studio that hopefully will be addressed in a subsequent Orca release.? Fortunately, this is a design time issue which does not cause any run-time errors. Please note too that this sample project can be viewed and run without difficulty in the release version of Expression Blend (1.0).

Please note that as of the date that this review was written, the WPF Docking Library Project is essentially in beta form and is not yet recommended for production projects.? On May 21, the author stated that he was working on a more powerful and stable version.
?

05.05.07

Displaying Generated Files

Posted in WPF at 1:11 am by Cal

When you create a WPF project in Visual Studio which includes at least one XAML file, Visual Studio will generate a .cs (or .vb) file to, amongst other things, create a Main() method and call InitializeComponent().? To review the content of these generated files, select Show All Files on the Project menu.? The generated files will be located under the obj node.?

Generated files always contain a warning that it does not make sense to edit them because each time that the project is built, they are re-generated from the other source code (ie. the corresponding XAML file) and any user modifications will simply be overwritten.? If a change is necessary, you must make the change in the XAML file in order for it to be effective.?

If you leave these generated files open in Visual Studio, you will receive one of those annoying popups each time that you modify one of the? source files asking you if you? would like to reload the generated file or keep your current (outdated) version.? ?

03.31.07

Building a Simple WPF Animation

Posted in WPF, WPF Animations at 6:19 am by Cal

This project illustrates a very simple WPF animation. The source code for this project is available here . If you prefer just the executable file itself, it is available here .

Cal With Glow

This project is a WPF Windows application (not an XBAP or WPF/E). I used Expression Blend to build it since animation in Blend is a much simpler task than it is in Visual Studio. The first thing which I did was to rename Window1 to MainWindow since using default names is only acceptable in a throw away project. Other minor housekeeping tasks included adding a custom icon to both the project and the MainWindow. In both cases, all that is required is to set the Icon property to the relative path of the icon file. (images/iconfile.ico)

Of course, the icon file should be added to the project. Be sure to set the Build Action of any image file to Resource — NOT Embedded Resource. A good way to remember that is to “avoid the ER” since you probably wouldn’t enjoy it there anyway. The Embedded Resource setting is used for Windows Forms projects and will not work with WPF images.

Resource Build Action

This animation uses two photographs taken at the Chernobyl nuclear reactor in the Ukraine (about 90 miles north of Kiev). Actually, both photographs are just the same photograph, one of which has been dressed up in Photoshop to include the glow effect. Any image file that you want to use in a WPF application should be explicitly added to your project. This can be done in either Blend or Visual Studio. It is generally best to create a new folder named “images” and then place all the image files that you need into that folder. To later reference any such files all you need to do is to include the folder name in the path (eg. images/filename.jpg).

Adding Images to the Images Folder

When you place two elements in a WPF Grid and you do not specify any rows or columns, both elements simply sit on top of each other in the same cell. Knowing this, I positioned my photographs so that the one without the glow sits directly in front of the one with the glow. Whichever element is added later will have the highest Z-Order.

Two Elements in the Same Grid Cell

Using the Animation Workspace in Blend I set a keyframe at time 02. At the beginning of the timeline, the opacity of the front photograph starts out at 100%. This means that when the application begins to run, the front photo is fully opaque. At the 2 second mark (the first keyframe), I set the opacity of the front photo to 0%. At this point, the front photo is entirely translucent and a user will see only the rear photo — the one with the glow. Then I created a second keyframe at time 00:00:04 (4 seconds). where I set the opacity of the first photo back to 100%. Animations of this sort scale in a linear fashion, meaning that at the 1 second point as well as the 3 second point, the opacity of the front photo will be 50%.

Animation Keyframe

WPF animations are not affected by CPU speed. A faster CPU will mean a smoother animation not a shorter animation.

Next I set AutoReverse to True and RepeatBehavior to Forever. This makes the glow fade back out and then reappear indefinitely until the user closes the application. Technically, I didn’t have to set AutoReverse to True since the animation as I built it already performs a complete cycle from 100% opaque to 100% transparent and back to 100% opaque again. If I had stopped the animation when the front photo was fully transparent, the AutoReverse setting would have been required in order to return the front photo to opaque.

Automation Properties

To allow the photo without the glow to appear briefly before the glow starts to phase in, I set the BeginTime property of the animation to 2 seconds (00:00:02). The BeginTime property is used to delay the commencement of an animation for a specified period of time. (2 seconds in my case as shown in the illustration above)

The triggering event is the loading of the MainWindow.
Trigger on Window Load

So as you can see, the steps required to create this animation are actually very simple. Not including the time needed to fly to the Ukraine to take this photo or the time needed to fix it up in Photoshop, buiding this animation can easily be accomplished in under half an hour.